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

cross compilation
by Shyam Saini June 6, 2016

June 6, 2016

Hi all, I'm trying to figure out optimized code for some network drivers. I'm replacing certain APIs in the code and compare code for each API. To choose best optimized code, i need to first compile them and then disassemble the compiled code, where a change in single line would make a significant difference in the performance. So, my question is how to compile* x86 based network drivers on x86_64 Ubuntu machine*. Currently I'm running Ubuntu 14.04. Please help me out Thanks

2 2

Re: Building modules: missing scripts/basic/Makefile
by Steven Laabs June 6, 2016

June 6, 2016

> Hi Steven, please verify the headers are correctly installed by running: > dpkg -s linux-headers-$(uname -r) . > > If they are not properly installed please run: > apt-get install kernel-headers-$(uname -r) > > You should be able to build :) > > Good luck - Aruna Hi Aruna, I ran dpkg -s linux-headers-$(uname -r) and the status indicated it was all installed ok. Just to be sure I reinstalled it as well as the dependencies (linux-headers-3.16.0-4-common and linux-kbuild-3.16). Reinstalling them seems to have not made any difference as my Makefile is still looking for a Makefile that does not seem to exist (which ultimately should be located in /usr/src/linux-kbuild-3.16/scripts/basic/).

2 1

Re: Building modules: missing scripts/basic/Makefile
by Steven Laabs June 6, 2016

June 6, 2016

>Hi Steven, > >On Mon, Jun 6, 2016 at 12:14 AM, Steven Laabs <swlaabs(a)gmail.com> wrote: >> Hi, >> >> I'm trying to build my first kernel module but when running the makefile, make tries to use a file at /usr/src/linux-headers-3.16.0-4-common/scripts/basic/Makefile which gives me the "No such file or directory" error. I've looked into the folder it is referencing and it does not have any Makefile, the only file in that location is the fixdep executable. The scripts folder itself is linked to ../../lib/linux-kbuild-3.16/scripts. >> >> The Makefile I am using (located in a folder in my home directory): >> >> obj-m = hello.o >> KDIR ?= /lib/modules/$(shell uname -r)/build >> >> all: >> make -C $(KDIR) M=$(PWD) modules >> >> clean: >> make -C $(KDIR) M=$(PWD) clean >> >> I'm not quite sure where to look for this Makefile as I believe I have all of the proper headers installed, and I am running everything with the proper permission level. >> >> Any ideas on what I may be missing here? >> >> Thanks, >> Steven >> > >You should use "+=" and not "=" >-- obj-m = hello.o >++ obj-m += hello.o Thanks for pointing that out, I've made that correction. Still missing the Makefile as previously mentioned unfortunately so I am unable to build.

2 1

inline functions
by Muni Sekhar June 6, 2016

June 6, 2016

Hi, I tested with the below mentioned code("inline.c") to understand about inline functions. I explicitly instructed gcc to translate inline.c to inline.s. Next I removed the inline keyword from inline.c and re-created the inline.s file, but I don’t see any difference in the assembly code. Is it correct behavior? Could you guys point few good examples to understand the concept of inline? #include <stdio.h> static inline int MAX(int x, int y) { return x > y ? x : y; } static void test1(void); int main(void) { test1(); return 0; } static void test1(void) { printf("MAX(2,6) = %d\n",MAX(2,6)); } -- Thanks, Sekhar

2 2

Building modules: missing scripts/basic/Makefile
by Steven Laabs June 6, 2016

June 6, 2016

Hi, I'm trying to build my first kernel module but when running the makefile, make tries to use a file at /usr/src/linux-headers-3.16.0-4-common/scripts/basic/Makefile which gives me the "No such file or directory" error. I've looked into the folder it is referencing and it does not have any Makefile, the only file in that location is the fixdep executable. The scripts folder itself is linked to ../../lib/linux-kbuild-3.16/scripts. The Makefile I am using (located in a folder in my home directory): obj-m = hello.o KDIR ?= /lib/modules/$(shell uname -r)/build all: make -C $(KDIR) M=$(PWD) modules clean: make -C $(KDIR) M=$(PWD) clean I'm not quite sure where to look for this Makefile as I believe I have all of the proper headers installed, and I am running everything with the proper permission level. Any ideas on what I may be missing here? Thanks, Steven

2 1

udev & modalias files
by Muni Sekhar June 4, 2016

June 4, 2016

Hi, I see lot of modalias files under /sys directory. For e.g: # cat /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/modalias pci:v00001556d00005555sv00004000sd00000000bc08sc05i01 I would like to know which part of the kernel module creates sysfs modalias file? How does udev load modules dynamically when a new device is added? Where should I look for default udev rules? -- Thanks, Sekhar

3 3

Trying to debug interrupt flood after unbind
by Rob Groner June 2, 2016

June 2, 2016

I am trying to load a driver for an Exar serial chip, but that chip is gobbled up by the 8250 driver on boot. So, I use the "unbind" command in /sys/bus/pci/drivers/serial to remove the device from the clutches of 8250. Based on cobbled together google searches, I use the following to unbind it (assuming the address in /sys/bus/pci/drivers/serial is 0000:04:00.0. sudo echo -n "0000:04:00.0" | tee ./unbind The address disappears from that dir when I do this command, so I'm assuming it works. I then go and install the Exar-provided driver. Within about 3 seconds, I then get a system notification that the IRQ used by the Exar driver has been disabled. I can also go look at /proc/interrupts and see a huge amount of interrupts happening on that IRQ. There's a crash message in the log: [ 167.938861] irq 17: nobody cared (try booting with the "irqpoll" option) [ 167.938868] CPU: 0 PID: 801 Comm: Xorg Tainted: G O 3.16.6-2-desktop #1 [ 167.938871] Hardware name: RTD Embedded Technologies, Inc CMA34CR/CMA34CR, BIOS v3.72.51.0009-1.1.85582 02/09/2015 09:39:58 [ 167.938873] ffff880148672cc4 ffffffff8161ab03 ffff880148672c00 ffffffff810b8acd [ 167.938877] ffff880148672c00 0000000000000011 0000000000000000 ffffffff810b9011 [ 167.938880] 0000000000000000 0000000000000000 0000000000000011 0000000000000000 [ 167.938883] Call Trace: [ 167.938899] [<ffffffff8100519e>] dump_trace+0x8e/0x350 [ 167.938905] [<ffffffff81005506>] show_stack_log_lvl+0xa6/0x190 [ 167.938909] [<ffffffff81006c01>] show_stack+0x21/0x50 [ 167.938914] [<ffffffff8161ab03>] dump_stack+0x49/0x6a [ 167.938922] [<ffffffff810b8acd>] __report_bad_irq+0x2d/0xc0 [ 167.938928] [<ffffffff810b9011>] note_interrupt+0x241/0x290 [ 167.938935] [<ffffffff810b67f1>] handle_irq_event_percpu+0xa1/0x1d0 [ 167.938940] [<ffffffff810b695e>] handle_irq_event+0x3e/0x60 [ 167.938945] [<ffffffff810b9b58>] handle_fasteoi_irq+0x88/0x160 [ 167.938949] [<ffffffff810050fd>] handle_irq+0x1d/0x30 [ 167.938955] [<ffffffff81624549>] do_IRQ+0x49/0xe0 [ 167.938959] [<ffffffff816224ad>] common_interrupt+0x6d/0x6d [ 167.938967] [<ffffffff81620dce>] _raw_spin_unlock_irqrestore+0xe/0x30 [ 167.938974] [<ffffffff815c3f05>] unix_poll+0x25/0xb0 [ 167.938980] [<ffffffff81513fa9>] sock_poll+0x49/0x110 [ 167.938986] [<ffffffff811caf40>] do_select+0x390/0x7a0 [ 167.938991] [<ffffffff811cb4e4>] core_sys_select+0x194/0x2b0 [ 167.938995] [<ffffffff811cb6aa>] SyS_select+0xaa/0xf0 [ 167.938999] [<ffffffff8162182d>] system_call_fastpath+0x1a/0x1f [ 167.939015] [<00007f7563abda43>] 0x7f7563abda42 [ 167.939016] handlers: [ 167.939020] [<ffffffffa0549110>] serialxr_interrupt [xr17v35x] [ 167.939023] Disabling IRQ #17 So, as near as I can tell, when the Exar driver is inserted, an interrupt flood occurs, and the Exar driver (the only interrupt handler on that IRQ) does not respond to any of them. I put in some debug code and verified that the Exar interrupt handler is called... but the handler just returns with an IRQ_NONE value. I've tried: 1) Multiple CPUs from different families (Core i7, Core 2 Duo, AMD G-Series) and it occurs with all of them. 2) Kernels 3.16 and 4.2 and it occurs with both of them. 3) Disabling ModemManager and it still happens. 4) Contacting Exar about this. They could not reproduce the problem. 5) openSUSE 13.2 and Fedora 20. It happened with openSUSE, but NOT with Fedora 20. 6) The reference Exar implementation vs. our implementation, and it occurs with both of them. Do you have any suggestions on how I can discover what is sending all of those interrupts? Are there kernel tools specifically for that? Thank you. Rob Groner

4 4

How to enable IIO driver in 3.18 kernel
by Munagala Naresh June 2, 2016

June 2, 2016

HI team, We are integrating one sensor driver in to LE platform. After adding sensor driver, it is creating device @ /sys/bus/iio/devices/iio:device0,1,2. Sensor driver makes use of IIO subsystem framework. We are not seeing iio device creation @ */dev/iio:device0*,1,2 I have enabled below configuration in the defconfing along with sensor configuration. CONFIG_IIO=y CONFIG_IIO_BUFFER=y CONFIG_IIO_BUFFER_CB=y CONFIG_IIO_KFIFO_BUF=y CONFIG_IIO_TRIGGERED_BUFFER=y CONFIG_IIO_TRIGGER=y CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 I'm able to see kernel prints from"iio_device_register" function. Appreciate any pointers on this regard. Kernel version: 3.18 -- Regards Naresh Babu 09900139337

3 4

[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

Request for guidance
by Abhishek June 1, 2016

June 1, 2016

Hi All, I am an Embedded Software Engineer with 3+ years of experience. I am fascinated by kernel development and want to be a device driver developer. I have done following so far. #Studied LDD3. #Subscribed to eudyptula challenge and submitted solution for 4th task(waiting for next task). #Have compiled and installed kernel successfully on multiple boards. I want to start contributing to kernel so I looked into staging and found that I can not work on TODO unless I have required hardware to test patch (which unfortunately I don't have). Requesting you to guide me about how to start working on kernel/device drivers development. Thanks, Abhishek

3 2