linux-device-driver

OK, this is really weird to me. I've got a simulated CAN bus driver, it is a Linux Kernel module. Then I have a test application running in user space which accesses the driver via opening a file descriptor and sending ioctl() messages. Now the CAN bus driver is just something I've been adopting to run on the x86 platform (it was running on our embedded Coldfire system). On the embedded system it had to use request_mem_region() / ioremap() to get the memory I/O area accessible, I don't need to do this, but I want to keep as much of the code common as I can. Here are some useful defines:

Closed. This question is off-topic . It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed last month . What is the difference between arm-eabi, gnueabi and gnueabi-hf cross compilers. I am kind of finding it difficult to choose the compilers. Is there a native compiler for arm? I'm not completely sure: the eabi stands for the compilation of code which will run on bare metal arm core. the gnueabi stands for the compilation of code for linux For the gnueabi/gnueabi-hf part, I found an answer here . gcc-arm-linux

I am working on a monothreaded process applet which creates a proxy virtual device (more precisely a virtual Xbox 360 pad); I do manage to create it with the uinput interface, I set it up properly and it works just fine. In order to feed commands to this virtual device , I read events from another real interface (in this case a PS3 pad), and I open the real device file with these flags: fd = open("/dev/input/event22", O_RDONLY); // open the PS3 pad The main loop is something like (minus error checking): while(run) { input_event ev = {0}; read(fd, &ev, sizeof(struct input_event)); // convert

At fairly high level in the Linux write() function, it filters out requests for writing 0 length buffers. Which makes sense. Who'd want to the OS wasting it's time drilling through layers only to determine there is no work to be done? Well ... me. It's related to this question ; and the discovery that the bit-banged I2C driver will give a potentially useful return code if the address (sent on the bus before data) will give an error if the handshaking is wrong. One could send dummy data after the address, but not with the device I'm using. (Perhaps I'll try a read ...). So the question is: What

Closed . This question is opinion-based . It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post . Closed 6 years ago . I have a code which detects GPIO interrupt in a kernel module. Now,I am looking for a mechanism to notify user space upon detecting gpio interrupt from kernel module. Any example / code snippet with certain advantages/disadvantages over different options? I would appreciate your response. Take a look at the GPIO keyboard driver ( drivers/input/keyboard/gpio_keys.c ). It is a

Thank you for looking at this post. I am trying to patch up a network block device driver. If you need to see the sources they are at http : / / code.ximeta.com. I noticed that lock_kernel() seems deprecated as of linux 2.6.37. I read "The new way of ioctl()" and found that device drivers now should perform a specific lock before operating. So I would like some advice replacing this if possible. I have found two sections in the current code that I think are related, in the block folder section. Source block->io.c ->ctrldev.c I put snippets from each for your consideration. io.c contains one

I am trying to setup a driver for an embedded PowerPC board, and the correct way to do this today is to use the OpenFirmware Device Tree datastructure (the .dtb file, compiled from a .dts file). Creating a tree is pretty easy, but how do I get my device driver to find its node and the data in it? I have not managed to find any good reference on this, and books like "Linux Device Drivers" are too much into x86 land to be of much help for device trees that mostly pertain to Power Architecture-based machines (arch powerpc in the Linux kernel terminology). There seems to be very little

I am in the process of writing a Linux Kernel Module (LKM) serving as a pseudo-driver - I am unable to figure out how to make IOCTL calls between the LKM ( wait.c ) and the user-level program ( user.c ). The magic number for the device driver is 0xBF - the LKM does not communicate with a physical block/char device, it is simply an exercise. From what I can tell, the IOCTL call to KERN_IOCTL_CREATE_EVENT is not formatted properly & the magic number is incorrect. The IOCTL call that I am attempting to use is: #include <sys/ioctl.h> #define KERN_IOCTL_CREATE_EVENT _IOWR(WAIT_DEVICE_MAGIC, 1, int)