linux-device-driver

问题 If a have a /dev device node and its major/minor numbers how do i know the kernel module name that exported this node? 回答1: Short answer : cd /sys/dev/char/major:minor/device/driver/ ls -al | grep module Each device is generally associated with a driver, and this is all what the "device model" is about. The sysfs filesystem contains a representation of this devices and their associated driver. Unfortuantely, it seems not all sysfs have a representation of the device nodes, so this applyd only

问题 I am reading about the Linux Device model which is built around buses,devices and drivers .I am able to understand a bit about how devices and driver matches happen but not clear about the role of buses here,how buses matches with device. One more doubt I have regarding where platform device gets it name from. "The platform bus,simply compares the name of each device against the name of each driver; if they are the same, the device matches the driver." Now I could n't really understand above

问题 I have a Linux device driver that interfaces to a device that, in theory, can perform DMA using 64-bit addresses. I'd like to test to see that this actually works. Is there a simple way that I can force a Linux machine not to use any memory below physical address 4G? It's OK if the kernel image is in low memory; I just want to be able to force a situation where I know all my dynamically allocated buffers, and any kernel or user buffers allocated for me are not addressable in 32 bits. This is

问题 From user-space we can use cpuset to actually isolate a specific core in our system and execute just one specific process to that core. I'm trying to do the same thing with a kernel module. So I want the module to get executed in an isolated core. In other words: How do I use cpuset 's from inside a kernel module? * Using linux/cpuset.h in my kernel module doesn't work. So, I have a module like this: #include <linux/module.h> #include <linux/cpuset.h> ... #ifdef CONFIG_CPUSETS printk(KERN

问题 When we use irq_set_chained_handler the irq line will not be disabled or not, when we are servicing the associated handler, as in case of request_irq. 回答1: It doesn't matter how the interrupt was setup. When any interrupt occurred, all interrupts (for this CPU) will be disabled during the interrupt handler. For example, on ARM architecture first place in C code where interrupt handling is found is asm_do_IRQ() function (defined in arch/arm/kernel/irq.c ). It's being called from assembler code

问题 Pertaining to the Linux kernel, do "Kernel" pages ever get swapped out ? Also, do User space pages ever get to reside in ZONE_NORMAL ? 回答1: No, kernel memory is unswappable. 回答2: Kernel pages are not swappable. But it can be freed. UserSpace Pages can reside in ZONE_NORMAL. Linux System Can be configured either to use HIGHMEM or not. If ZONE_HIGHMEM is configured , then the userspace processes will get its memory from the HIGHMEM else userspace processes will get memory from ZONE_NORMAL. 回答3:

问题 I want the software loop back to be tested using my application code for uart4 instance of omap-4460.I am using the default driver. How will I do it using ioctl?or any other way. Please find the driver code here omap-serial.c. Please share any reference code. 来源： https://stackoverflow.com/questions/23243494/loop-back-mode-enabling

问题 In the read function prototype, ssize_t read(struct file *filp, char __user *buff,size_t count, loff_t *offp); where does the parameter offp point to? What I understand from the below write function is that the parameter ppos points to the top of the data available in deviceBuffer[] , which is a global buffer in kernel space. Correct me if I am wrong. How does this apply to read function ? static ssize_t mcspi_write(struct file *filp, const char *buff, size_t length, loff_t *ppos) { int

问题 In the read function prototype, ssize_t read(struct file *filp, char __user *buff,size_t count, loff_t *offp); where does the parameter offp point to? What I understand from the below write function is that the parameter ppos points to the top of the data available in deviceBuffer[] , which is a global buffer in kernel space. Correct me if I am wrong. How does this apply to read function ? static ssize_t mcspi_write(struct file *filp, const char *buff, size_t length, loff_t *ppos) { int

问题 So if I understand things correctly, cat /proc/iomem lists the memory addresses that are mapped to this and that device register and similarily for ioports . If you pick up some book on Linux device drivers, it will state something about iomem being populated by the driver calling request_region() or something like that. But how does the device driver know where the hardware register is located at from the get-go? For example, rtc0 seems to occupy 0070:0071 for most people - how does Linux