linux-device-driver

问题 On my x86_64 board, there is i2c-bus coming out of a MFD device. There are devices on to this i2c-bus. I am able to detect these devices using i2cdetect program. # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -

问题 On my x86_64 board, there is i2c-bus coming out of a MFD device. There are devices on to this i2c-bus. I am able to detect these devices using i2cdetect program. # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -

问题 Now I need to get the status of the NIC(up or down) in the real time. That means I have to catch the kernel interrupt when the NIC up or down in a blocked loop. The first stupid method from mine is that check on the /sys/class/net/eth0/operstate or use ioctl to get the ifflag every 100ms in a loop. But 100ms is too long for the app to reroute the traffic and also polling kernel every 100ms is not good idea. Once I notice the inotify function that can monitor the files in a block mode. But

问题 I've started to learn Linux driver programs, but I'm finding it a little difficult. I've been studying the i2c driver, and I got quite confused regarding the entry-point of the driver program. Does the driver program start at the MOUDULE_INIT() macro? And I'd also like to know how I can know the process of how the driver program runs. I got the book, Linux Device Driver, but I'm still quite confused. Could you help me? Thanks a lot. I'll take the i2c driver as an example. There are just so

问题 Got some statistics information of our custom hardware to be displayed whenever user asks for using a command in the Linux user space. This implementation is currently uses PROC interface. We started adding more statistics information then we encountered a problem wherein the particular statistics command had to be executed twice for getting the entire data as PROC interface was restricted to 1 page. As mentioned above the data transfer between the kernel and the user space is not critical

问题 I have some question about Linux kernel and GPIOs. I know that in Linux everything is file so when I do something like echo 30 > /sys/class/gpio/export and echo 1 > /sys/class/gpio/gpio30/value what really happens? I mean how does sysfs handle that? Does it call system calls implemented in gpiolib? 回答1: The gpiolib registers the value attribute in this way: static const DEVICE_ATTR(value, 0644, gpio_value_show, gpio_value_store); It creates a device attribute named value , with permission 644

问题 The implementation of a function sum in “C” is as follows: int sum(int b[], int c) { int s,i; if (c<0) { printf("ERROR\n"); } s = 0; for(i=0; i<c; ++i) { s = s + b[i]; } return s; } I'd like to know, How much stack and heap in bytes is required by the function sum in X86 Linux platform? How to know this? Is invocation of the function from within an interrupt-handler likely to be problematic or successful? 回答1: To build upon what other users have already pointed out, I will try to address both

问题 I am attempting to write a linux driver for a printer. I have run USBSnoop on windows XP and obtained the log. In this log it sets wMaxPacketSize to 1026. After i set the interface i get the response of 75 bytes. If i set it to 64 (in the lsusb output) i obviously only get 64 bytes back. My issue is on a bulk transfer to/from the device i get timeouts. I think i have the same problem as here: http://libusb.6.n5.nabble.com/libusb-bulk-transfer-return-timeout-error-and-transferred-set-to-0

问题 This question was migrated from Unix & Linux Stack Exchange because it can be answered on Stack Overflow. Migrated 5 months ago . I'm porting the lirc_serial kernel module to work on our embedded board. We only need to implement the IR transmitter function. For only the transmitter, the custom driver need only control the RTS pin on /dev/ttyS0 , from within the module. On standard hardware, the driver loads: 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A NEW APPROACH I

问题 The venerated book Linux Driver Development says that The flags argument passed to spin_unlock_irqrestore must be the same variable passed to spin_lock_irqsave . You must also call spin_lock_irqsave and spin_unlock_irqrestore in the same function; otherwise your code may break on some architectures. Yet I can't find any such restriction required by the official documentation bundled with the kernel code itself. And I find driver code that violates this guidance. Obviously it isn't a good idea