April 2016 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

where is __percpu_seg initialized?
by 落痕 March 28, 2018

March 28, 2018

Hi all: I knew the kernel implement the per-cpu variable via __percpu_seg. For example on x86 architecture, it's defined as: #ifdef CONFIG_X86_64 #define __percpu_seg gs #define __percpu_mov_op movq #else #define __percpu_seg fs #define __percpu_mov_op movl #endif But I'm curious where __percpu_seg is initialized?? I fail to find the relative code. Thanks.

2 2

How to handle Hotplug with UIO userspace driver
by Mandeep Sandhu Sept. 28, 2017

Sept. 28, 2017

Hi All, We're working on a custom PCIe based hardware, which can be hotplugged into the system. We're using the UIO approach of having a minimal kernel driver which basically handles the interrupt and provides a mmap of the device memory to userspace and userspace driver which mmap's the provided memory and manages the device. We're using systemd and udev rules to spawn off a user process whenever the hardware is plugged into the system. Now my question is, how can we gracefully inform the userspace process if someone pulls out the hardware (sitting on a PCI slot). Even with full hotplug support, there can always be a case of "surprise removal", where someone yanks the board without going through the whole "attention button" routine. While the kernel driver has no problem with hot-removal, I see that if I "unregister" our UIO driver in response to the removal, then the mapping for the hardware's physical memory would become "invalid" (done by UIO on unregsiter). This could possibly cause the user-space process to crash due to illegal memory access. Is there a "standard" way to handle this scenario, i.e for hotpluggable hardware using UIO? Basically, we'd want to "unregister" the UIO device only after the userspace process is informed of the removal so that it could unmap/close the device and exit gracefully. We could try doing it using some systemd trick, where we put a dependency on one of the UIO created files (/dev/uioX), so that when the file is destroyed, systemd could kill/shutdown the process. Although, there's no guarantee that the userspace process won't try to access the mmaped space during that interval, so this isn't a reliable solution either. Any hints, thoughts? Thanks., -mandeep

3 7

What are need to makes humidifier?
by 윤영석 April 1, 2017

April 1, 2017

Hi, I want to make own humidifier. What sensor need when making humidifier?? humidity indicator (detecting humidity), ultrasonic waves maker?? Please shares your wisdom to me. Thanks. Best regards.

2 1

Mapping of Filename to allocated blocks
by Manoj Rao July 21, 2016

July 21, 2016

Hi All, I'm looking for a way to get a filename associated with a given physical block (ideally what I'd like is a mapping of filename <=> all the allocated blocks for this file). Is there a recommended way to do this already in kernel? if not, then where should I start looking to add changes? Help appreciated. Thanks.

3 3

[PATCH] misc devices: HC-SRO4 ultrasonic distance driver
by Johannes Thoma June 1, 2016

June 1, 2016

From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001 From: Johannes Thoma <johannes(a)johannesthoma.com> Date: Mon, 21 Mar 2016 22:11:01 +0100 Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO pins. The driver is controlled via sysfs and supports an (in theory) unlimited number of HC-SRO4 devices. Unlike user land solutions this driver produces precise results even when there is high load on the system. It uses a non-blocking interrupt triggered mechanism to record the length of the echo signal. This patch is against the raspberry pi kernel from https://github.com/raspberrypi/linux.git hash e481b5ceae6c94c7e60f8bb8591cbb362806246e Note that this patch isn't meant for lkml (yet) see: TODO's: .) Patch against mainline (or whatever kernel it belongs to) .) Use IIO layer instead of creating random sysfs entries. .) Fill in GPIO device as parent to device_create_with_groups(). .) Test it with two or more HC-SRO4 devices. .) Test it on other hardware than raspberry pi. .) Test it with kernel debugging enabled. Anyway, comments are highly appreciated. Signed-off-by: Johannes Thoma <johannes(a)johannesthoma.com> --- MAINTAINERS | 5 + drivers/misc/Kconfig | 11 ++ drivers/misc/Makefile | 1 + drivers/misc/hc-sro4.c | 360 +++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 377 insertions(+) create mode 100644 drivers/misc/hc-sro4.c diff --git a/MAINTAINERS b/MAINTAINERS index da3e4d8..f819d66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4910,6 +4910,11 @@ W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/ S: Maintained F: drivers/platform/x86/hdaps.c +HC-SRO4 ULTRASONIC DISTANCE SENSOR DRIVER +M: Johannes Thoma <johannes(a)johannesthoma.com> +S: Maintained +F: drivers/misc/hc-sro4.c + HDPVR USB VIDEO ENCODER DRIVER M: Hans Verkuil <hverkuil(a)xs4all.nl> L: linux-media(a)vger.kernel.org diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 4c499de..1be88ad 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -475,6 +475,17 @@ config BMP085_SPI To compile this driver as a module, choose M here: the module will be called bmp085-spi. +config SENSORS_HC_SRO4 + tristate "HC-SRO4 ultrasonic distance sensor on GPIO" + depends on GPIOLIB && SYSFS + help + Say Y here if you want to support the HC-SRO4 + ultrasonic distance sensor to be hooked on two runtime-configurable + GPIO pins. + + To compile this driver as a module, choose M here: the + module will be called hc-sro4. + config PCH_PHUB tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB" select GENERIC_NET_UTILS diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 1acff5b..9a8e508 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o obj-$(CONFIG_SENSORS_BH1780) += bh1780gli.o obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o +obj-$(CONFIG_SENSORS_HC_SRO4) += hc-sro4.o obj-$(CONFIG_SGI_IOC4) += ioc4.o obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o obj-$(CONFIG_KGDB_TESTS) += kgdbts.o diff --git a/drivers/misc/hc-sro4.c b/drivers/misc/hc-sro4.c new file mode 100644 index 0000000..9925b7e --- /dev/null +++ b/drivers/misc/hc-sro4.c @@ -0,0 +1,360 @@ +/* Precise measurements of time delta between sending a trigger signal + * to the HC-SRO4 distance sensor and receiving the echo signal from + * the sensor back. This has to be precise in the usecs range. We + * use trigger interrupts to measure the signal, so no busy wait :) + * + * This supports an (in theory) unlimited number of HC-SRO4 devices. + * To add a device, do a (as root): + * + * # echo 23 24 1000 > /sys/class/distance-sensor/configure + * + * (23 is the trigger GPIO, 24 is the echo GPIO and 1000 is a timeout in + * milliseconds) + * + * Then a directory appears with a file measure in it. To measure, do a + * + * # cat /sys/class/distance-sensor/distance_23_24/measure + * + * You'll receive the length of the echo signal in usecs. To convert (roughly) + * to centimeters multiply by 17150 and divide by 1e6. + * + * To deconfigure the device, do a + * + * # echo -23 24 > /sys/class/distance-sensor/configure + * + * (normally not needed). + * + * DO NOT attach your HC-SRO4's echo pin directly to the raspberry, since + * it runs with 5V while raspberry expects 3V on the GPIO inputs. + * + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/timekeeping.h> +#include <linux/gpio/consumer.h> +#include <linux/mutex.h> +#include <linux/device.h> +#include <linux/sysfs.h> +#include <linux/interrupt.h> +#include <linux/kdev_t.h> +#include <linux/list.h> +#include <linux/slab.h> +#include <linux/gpio/driver.h> +#include <linux/delay.h> +#include <linux/sched.h> + +struct hc_sro4 { + int gpio_trig; + int gpio_echo; + struct gpio_desc *trig_desc; + struct gpio_desc *echo_desc; + struct timeval time_triggered; + struct timeval time_echoed; + int echo_received; + int device_triggered; + struct mutex measurement_mutex; + wait_queue_head_t wait_for_echo; + unsigned long timeout; + struct list_head list; +}; + +static LIST_HEAD(hc_sro4_devices); +static DEFINE_MUTEX(devices_mutex); + +static struct hc_sro4 *create_hc_sro4(int trig, int echo, unsigned long timeout) + /* must be called with devices_mutex held */ +{ + struct hc_sro4 *new; + int err; + + new = kmalloc(sizeof(*new), GFP_KERNEL); + if (new == NULL) + return ERR_PTR(-ENOMEM); + + new->gpio_echo = echo; + new->gpio_trig = trig; + new->echo_desc = gpio_to_desc(echo); + if (new->echo_desc == NULL) { + kfree(new); + return ERR_PTR(-EINVAL); + } + new->trig_desc = gpio_to_desc(trig); + if (new->trig_desc == NULL) { + kfree(new); + return ERR_PTR(-EINVAL); + } + + err = gpiod_direction_input(new->echo_desc); + if (err < 0) { + kfree(new); + return ERR_PTR(err); + } + err = gpiod_direction_output(new->trig_desc, 0); + if (err < 0) { + kfree(new); + return ERR_PTR(err); + } + gpiod_set_value(new->trig_desc, 0); + + mutex_init(&new->measurement_mutex); + init_waitqueue_head(&new->wait_for_echo); + new->timeout = timeout; + + list_add_tail(&new->list, &hc_sro4_devices); + + return new; +} + +static irqreturn_t echo_received_irq(int irq, void *data) +{ + struct hc_sro4 *device = (struct hc_sro4 *) data; + int val; + struct timeval irq_tv; + + do_gettimeofday(&irq_tv); + + if (!device->device_triggered) + return IRQ_HANDLED; + if (device->echo_received) + return IRQ_HANDLED; + + val = gpiod_get_value(device->echo_desc); + if (val == 1) { + device->time_triggered = irq_tv; + } else { + device->time_echoed = irq_tv; + device->echo_received = 1; + wake_up_interruptible(&device->wait_for_echo); + } + + return IRQ_HANDLED; +} + +/* devices_mutex must be held by caller, so nobody deletes the device + * before we lock it. + */ + +static int do_measurement(struct hc_sro4 *device, + unsigned long long *usecs_elapsed) +{ + long timeout; + int irq; + int ret; + + if (!mutex_trylock(&device->measurement_mutex)) { + mutex_unlock(&devices_mutex); + return -EBUSY; + } + mutex_unlock(&devices_mutex); + + msleep(60); + /* wait 60 ms between measurements. + * now, a while true ; do cat measure ; done should work + */ + + irq = gpiod_to_irq(device->echo_desc); + if (irq < 0) + return -EIO; + + device->echo_received = 0; + device->device_triggered = 0; + + ret = request_any_context_irq(irq, echo_received_irq, + IRQF_SHARED | IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, + "hc_sro4", device); + + if (ret < 0) + goto out_mutex; + + gpiod_set_value(device->trig_desc, 1); + udelay(10); + device->device_triggered = 1; + gpiod_set_value(device->trig_desc, 0); + + ret = gpiochip_lock_as_irq(gpiod_to_chip(device->echo_desc), + device->gpio_echo); + if (ret < 0) + goto out_irq; + + timeout = wait_event_interruptible_timeout(device->wait_for_echo, + device->echo_received, device->timeout); + + if (timeout == 0) + ret = -ETIMEDOUT; + else if (timeout < 0) + ret = timeout; + else { + *usecs_elapsed = + (device->time_echoed.tv_sec - device->time_triggered.tv_sec) * 1000000 + + (device->time_echoed.tv_usec - device->time_triggered.tv_usec); + ret = 0; + } +out_irq: + free_irq(irq, device); +out_mutex: + mutex_unlock(&device->measurement_mutex); + + return ret; +} + +static ssize_t sysfs_do_measurement(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct hc_sro4 *sensor = dev_get_drvdata(dev); + unsigned long long usecs_elapsed; + int status; + + mutex_lock(&devices_mutex); + status = do_measurement(sensor, &usecs_elapsed); + + if (status < 0) + return status; + + return sprintf(buf, "%lld\n", usecs_elapsed); +} + +DEVICE_ATTR(measure, 0444, sysfs_do_measurement, NULL); + + +static struct attribute *sensor_attrs[] = { + &dev_attr_measure.attr, + NULL, +}; + +static const struct attribute_group sensor_group = { + .attrs = sensor_attrs +}; + +static const struct attribute_group *sensor_groups[] = { + &sensor_group, + NULL +}; + +static ssize_t sysfs_configure_store(struct class *class, + struct class_attribute *attr, + const char *buf, size_t len); + +static struct class_attribute hc_sro4_class_attrs[] = { + __ATTR(configure, 0200, NULL, sysfs_configure_store), + __ATTR_NULL, +}; + +static struct class hc_sro4_class = { + .name = "distance-sensor", + .owner = THIS_MODULE, + .class_attrs = hc_sro4_class_attrs +}; + + +static struct hc_sro4 *find_sensor(int trig, int echo) +{ + struct hc_sro4 *sensor; + + list_for_each_entry(sensor, &hc_sro4_devices, list) { + if (sensor->gpio_trig == trig && + sensor->gpio_echo == echo) + return sensor; + } + return NULL; +} + +static int match_device(struct device *dev, const void *data) +{ + return dev_get_drvdata(dev) == data; +} + +static int remove_sensor(struct hc_sro4 *rip_sensor) + /* must be called with devices_mutex held. */ +{ + struct device *dev; + + dev = class_find_device(&hc_sro4_class, NULL, rip_sensor, match_device); + if (dev == NULL) + return -ENODEV; + + mutex_lock(&rip_sensor->measurement_mutex); + /* wait until measurement has finished */ + list_del(&rip_sensor->list); + kfree(rip_sensor); /* ?? double free ?? */ + + device_unregister(dev); + put_device(dev); + + return 0; +} + +static ssize_t sysfs_configure_store(struct class *class, + struct class_attribute *attr, + const char *buf, size_t len) +{ + int add = buf[0] != '-'; + const char *s = buf; + int trig, echo, timeout; + struct hc_sro4 *new_sensor, *rip_sensor; + int err; + + if (buf[0] == '-' || buf[0] == '+') + s++; + + if (add) { + if (sscanf(s, "%d %d %d", &trig, &echo, &timeout) != 3) + return -EINVAL; + + mutex_lock(&devices_mutex); + if (find_sensor(trig, echo)) { + mutex_unlock(&devices_mutex); + return -EEXIST; + } + + new_sensor = create_hc_sro4(trig, echo, timeout); + mutex_unlock(&devices_mutex); + if (IS_ERR(new_sensor)) + return PTR_ERR(new_sensor); + + device_create_with_groups(class, NULL, MKDEV(0, 0), new_sensor, + sensor_groups, "distance_%d_%d", trig, echo); + } else { + if (sscanf(s, "%d %d", &trig, &echo) != 2) + return -EINVAL; + + mutex_lock(&devices_mutex); + rip_sensor = find_sensor(trig, echo); + if (rip_sensor == NULL) { + mutex_unlock(&devices_mutex); + return -ENODEV; + } + err = remove_sensor(rip_sensor); + mutex_unlock(&devices_mutex); + if (err < 0) + return err; + } + return len; +} + +static int __init init_hc_sro4(void) +{ + return class_register(&hc_sro4_class); +} + +static void exit_hc_sro4(void) +{ + struct hc_sro4 *rip_sensor, *tmp; + + mutex_lock(&devices_mutex); + list_for_each_entry_safe(rip_sensor, tmp, &hc_sro4_devices, list) { + remove_sensor(rip_sensor); /* ignore errors */ + } + mutex_unlock(&devices_mutex); + + class_unregister(&hc_sro4_class); +} + +module_init(init_hc_sro4); +module_exit(exit_hc_sro4); + +MODULE_AUTHOR("Johannes Thoma"); +MODULE_DESCRIPTION("Distance measurement for the HC-SRO4 ultrasonic distance sensor for the raspberry pi"); +MODULE_LICENSE("GPL"); + -- 1.9.1

5 8

anyone aware of a high availability setup that relies on fully redundant install?
by Robert P. J. Day May 12, 2016

May 12, 2016

i figure this is as good a place as any to ask ... is anyone here aware of anyone using a linux config and install that, for the purposes of reliability or high availability or whatever you want to call it, relies on a second, completely independent installation of linux on the same hard drive? i was having a discussion about the reliability of upgrading linux (any combination of kernel, basic rootfs and/or proprietary apps), and one approach that was suggested (not by me) was to have two entirely independent installations on the same hard drive so that, when one "upgraded" the system, the newer content was installed in the other partition and the system rebooted to that newer content, the rationale being that, if the upgraded system didn't work, one could revert back to the original install. the history of this particular approach lies in the fact that the original S/W running on the system in question was an embedded app programmed right on bare metal, so the entire app was basically a monolithic combination of boot loader, kernel and all the apps. in that case, i can certainly see how one wanted a reliable way to revert back to a known working system if the new S/W had flaws. but i don't think that logic holds with a linux installation. the major concern seems to be a fear that, if one upgrades the kernel even a little bit, user space apps might suddenly stop working because of some new incompatibility introduced by that upgrade. i'm well aware of gregkh's piece on kernel stable API nonsense: https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt so i'm not overly worried, but folks in the discussion coming from the embedded programming space are using their experiences from that space to argue that a fully redundant install is the safest approach just in case something goes wrong with an upgrade. not surprisingly, my position is that this is not something they need to worry about a whole lot but, for the sake of fairness, i thought i'd look around to see if any linux folks *are* using that approach. anyone? thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

6 9

Submitting patches to non-staging
by Pratyush Patel May 10, 2016

May 10, 2016

Hello all, I am new to Linux kernel development and am hoping to contribute to the Linux community. I recently read Robert Love's LKD book, and have gone through some of the documents and patch submitting guidelines on kernelnewbies.org. I will be pursuing my undergraduate thesis research in the field of real-time (operating) systems and as such, I expect to be closely involved with the timer and interrupt subsystems in Linux (as well as other areas, but to a lesser degree). I am also hoping to work with the hrtimer subsystem, and while going through the latest code (4.5-rc6) of the same, I found a very minor code-level change that could be incorporated (redundant #ifdef). Would such a change in a core kernel file be acceptable coming from a beginner? Or should I aim for the staging drivers first? I very much look forward to contributing my first patch! Thanks, Pratyush

5 8

i2c driver develpment with diolan DLN-2 / ACPI?
by Martin Kepplinger April 30, 2016

April 30, 2016

Hi roberta or anyone who uses a diolan i2c/spi bridge device, I try to do get the kernel driver for the connected chip loaded, but I'm having some trouble getting it right. Cables are connected to the device (i2c), and the (mainline) kernel driver for the diolan DLN-2 device is compiled and loaded on plugin. I don't use any of their (userspace) software. Now I get a new i2c bus and can manually instanciate my driver root@laptop:/sys/bus/i2c/devices/i2c-7# echo mma8452 0x1c > new_device and the driver loads. (Now for development, later maybe for merging) I added acpi support, I guess I'd need it, but ACPI_HANDLE(&client->dev) isn't true (during probe) hence we don't continue. I append my adding-acpi-patch below. How do you do it? Do *you* manually instantiate your i2c-driver during development with your diolan device or should it somehow even get loaded automatically? thanks so much for any help, martin --- a/drivers/iio/accel/mma8452.c +++ b/drivers/iio/accel/mma8452.c @@ -33,6 +33,7 @@ #include <linux/of_device.h> #include <linux/of_irq.h> #include <linux/pm_runtime.h> +#include <linux/acpi.h> #define MMA8452_STATUS 0x00 #define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0)) @@ -1434,6 +1435,19 @@ static const struct of_device_id mma8452_dt_ids[] = { }; MODULE_DEVICE_TABLE(of, mma8452_dt_ids); +static const char *mma8452_match_acpi_device(struct device *dev, int *data) +{ + const struct acpi_device_id *id; + + id = acpi_match_device(dev->driver->acpi_match_table, dev); + if (!id) + return NULL; + + *data = (int)id->driver_data; + + return dev_name(dev); +} + static int mma8452_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -1441,21 +1455,35 @@ static int mma8452_probe(struct i2c_client *client, struct iio_dev *indio_dev; int ret; const struct of_device_id *match; + const char *name = NULL; + int dev_id = 0; - match = of_match_device(mma8452_dt_ids, &client->dev); - if (!match) { - dev_err(&client->dev, "unknown device model\n"); - return -ENODEV; - } +pr_info("mma probe running!!\n"); indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data)); if (!indio_dev) return -ENOMEM; data = iio_priv(indio_dev); + i2c_set_clientdata(client, indio_dev); data->client = client; + + match = of_match_device(mma8452_dt_ids, &client->dev); + if (match) { + if (id) + name = id->name; + data->chip_info = match->data; + } else if (ACPI_HANDLE(&client->dev)) { + name = mma8452_match_acpi_device(&client->dev, &dev_id); + pr_info("mma acpi ok. found id %d\n", dev_id); + /* TODO chip_info setting*/ + data->chip_info = &mma_chip_info_table[dev_id]; + } else { + dev_err(&client->dev, "unknown device model\n"); + return -ENODEV; + } + mutex_init(&data->lock); - data->chip_info = match->data; ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I); if (ret < 0) @@ -1475,11 +1503,10 @@ static int mma8452_probe(struct i2c_client *client, } dev_info(&client->dev, "registering %s accelerometer; ID 0x%x\n", - match->compatible, data->chip_info->chip_id); + name, data->chip_info->chip_id); - i2c_set_clientdata(client, indio_dev); indio_dev->info = &mma8452_info; - indio_dev->name = id->name; + indio_dev->name = name; indio_dev->dev.parent = &client->dev; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->channels = data->chip_info->channels; @@ -1669,6 +1696,17 @@ static const struct dev_pm_ops mma8452_pm_ops = { mma8452_runtime_resume, NULL) }; +static const struct acpi_device_id mma8452_acpi_match[] = { + { "MMA8451", mma8451 }, + { "MMA8452", mma8452 }, + { "MMA8453", mma8453 }, + { "MMA8652", mma8652 }, + { "MMA8653", mma8653 }, + { "FXLS8471", fxls8471 }, + { }, +}; +MODULE_DEVICE_TABLE(acpi, mma8452_acpi_match); + static const struct i2c_device_id mma8452_id[] = { { "mma8451", mma8451 }, { "mma8452", mma8452 }, @@ -1684,6 +1722,7 @@ static struct i2c_driver mma8452_driver = { .driver = { .name = "mma8452", .of_match_table = of_match_ptr(mma8452_dt_ids), + .acpi_match_table = ACPI_PTR(mma8452_acpi_match), .pm = &mma8452_pm_ops, }, .probe = mma8452_probe, -- 2.1.4

2 4

unable to find function definition
by Nijam Haider April 28, 2016

April 28, 2016

i was going through the code leds-gpio.c. i found a function "platform_gpio_blink_set" declared under private data of "gpio_led_data",and was trying to get through this function. But hardly i can find any link to definition for the same anywhere. Regards Nijam

9 12

Re: strange dtc errors after adding sram node
by Stefan Wahren April 27, 2016

April 27, 2016

Hi Arnd, Am 25.04.2016 um 15:06 schrieb Arnd Bergmann: > On Monday 25 April 2016 08:04:53 Stefan Wahren wrote: >> >> i've found reason for these errors. I missed to adjust the affected dts >> files which refer to the ahb node. > > Makes sense. Maybe you can just remove the address and 'reg' property from > the ahb node? is this a proposal for a patch set? Does it apply to all top-level nodes like apb? > That should solve the dtc problem and make the contents > more like what we have elsewhere. Does it refer to a specific patch / discussion or something? Regards Stefan > > Arnd >

1 0