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 9 years ago.
Improve this question
I am a newbie learning how to write Linux device drivers for USB devices. I want to understand the dmesg ouput
[ 6870.420077] usb 2-5: new low-speed USB device number 43 using ohci_hcd
[ 6870.500057] hub 2-0:1.0: unable to enumerate USB device on port 5
[ 6871.444057] usb 2-5: new low-speed USB device number 44 using ohci_hcd
[ 6871.524065] hub 2-0:1.0: unable to enumerate USB device on port 5
[ 6872.468089] usb 2-5: new low-speed USB device number 45 using ohci_hcd
[ 6872.548065] hub 2-0:1.0: unable to enumerate USB device on port 5
Could you direct me to some reading material explaining how to decipher these kernel messages?
dmesg - print or control the kernel ring buffer.
when dmesg command is issued, kernel ring buffer messages will be printed. There is no specific format used I guess.
Mostly whenever a new driver(or kernel code) is written, that particular module name is print first and corresponding message will be printed for differentiating our messages.
for example,
printk(KERN_ALERT "JayModule: Module loaded successfully.. ");
will print JayModule: Module loaded successfully.. in kernel ring buffer.
I guess numeric values given within [] is time.
Related
i want to send and receive data from/to an arduino connected to a /dev/ttyUSB port (serial) from a kernel module. i have seen enough ways how to do it in userspace, but that's not my question.
it would really help to be able to access a tty by major and minor numbers (188, 0 for /dev/ttyUSB0) as i dont want to use file io in a kernel module
related but didnt answer my question:
How to write to a tty from kernel space with only major and minor device numbers available? (1 answer but uses userspace)
Access /dev/ttyACM0 from kernel (no answers yet)
How can I write to TTY from a kernel module? (1 answer but how to get the struct tty_struct from a serial port?)
Read and write to Arduino serial using a kernel module (1 answer but uses file io and alternative is too vague)
https://unix.stackexchange.com/questions/585573/how-does-serial-driver-get-attached-to-a-tty-port (no answers yet)
SappyInsane on linuxquestions had the same problem and gave me his solution which worked
https://www.linuxquestions.org/questions/linux-kernel-70/reading-from-arduino-serial-in-a-kernel-module-4175704822/
How does an OS maps USB device with its device driver? I understand that in the interface descriptor of client USB firmware if no class type has been selected for the device then developer has to provide its own device driver.
I am keen to know how OS maps the pluggged USB device with its device driver? Does descriptors in the USB client firmware contains the file name of the custom device driver? Please let me know.
As a hobby, I have done quite a bit of work with the USB hardware, and had these same questions when I first started.
An OS can map a USB device any way it wants. However, to be more precise toward your question, a USB device will, and must return a class and interface code. Granted, that class code can be 0xFF for user-defined, where the device now must require a unique driver.
In my opinion, this is where the USB shines. All USB devices that return a valid class code specified within the USB specification, will and must follow a specific sequence of events and will "work right out of the box" as indicated. However, this doesn't mean that it cannot have extra capabilities.
For example. A pointing device, such as a mouse, will probably always follow the boot protocol when first plugged in. This is the protocol used and specified in the USB specification so that any OS that follows this protocol can use this pointing device. This protocol specifies a simple three (or more) byte packet for pointer input.
Byte Description
0 Button(s)
1 X Displacement
2 Y Displacement
3 (Device Specific) (optional)
Any pointing device that follows the USB specification most likely has this protocol and will use this protocol until told otherwise. This is so any USB capable OS can use the pointing device.
Every USB device also has a vendor, device, and protocol definition. Once the OS has found this device, it can search through its drivers for a driver that can support this device. That driver, once loaded, can then tell the device to now use a different protocol. i.e.: Return a different Input Report.
Here is an example. Let's say that you have a fancy gaming mouse with three directions of displacement (X, Y and Z), and six buttons. As the OS is booting, it probably has no idea how to use that mouse. Therefore, the manufacturer creates the mouse to use the boot protocol shown above until the driver can be loaded. Once the driver is loaded, which knows how to use the three direction displacements and all six buttons, it can tell the mouse, through a Control packet, maybe the SET INTERFACE command as well, to now start sending a different report, now using the full capabilities of the mouse.
So, as along as the device is USB specification accurate, and has a class code not of user defined (0xFF), the device will be recognized, even if it is a minimal use and/or is to show a statement that a driver is needed.
As for giving a file name of a custom device driver, this is all up to the device manufacturer. However, usually this is not that case. Usually, the OS will retrieve the DEVICE DESCRIPTOR which contains the manufacturer, device, protocol, and other fields. It will then match any driver to those fields. If it does not find a compatible driver, it will ask for one.
For example, one of the pointing devices I used with my research has the following few bytes of the 18-byte Device Descriptor:
Offset Field Value
0 Length 0x12
1 Type 0x01
2 Release Num 0x0110
4 Device Class 0x00
5 Sub Class 0x00
6 Protocol 0x00
7 MaxPacketSz 0x08
8 VendorID 0x04FC
10 Product ID 0x0003
...
Notice that it specifies the Vendor and the Product. Using these two values, a compatible driver can be found.
Now, notice that the class code is zero. This is not an error and is a perfectly valid class code, and simply means that the interface descriptor is to be used instead.
So, hopefully with this information, and specifically, the Manufacturer and Product codes within the DEVICE DESCRIPTOR, you can now see how an OS can find the correct driver for any device.
I am trying to port drivers from old kernel to new one on ARM based platform. While porting one of the drivers I have noticed that request_irq fails on new kernel. Actually, what this driver have is a number of hard coded irq numbers, and it tries to request_irq for this HW lines. I started to search what is the reason of request_irq failure, - the reason is that the appropriate IRQ descriptor (irq_desc) have IRQ_NOREQUEST flag set.
I started to search where this flag is cleared, and found that it happens here:
of_platform_populate
|
...
|
of_device_alloc
|
...
|
irq_of_parse_and_map
(some levels below this flag is dropped)
So that code is invoked from mach init code and parse DTB, all interrupt numbers that are mentioned in DTB would be mapped to irq virtual space and will be accessible through appropriate devices structures, for example:
irq = platform_get_irq(pdev, 0);
As I already said, this old - fashion drivers just have hard-coded irq numbers in include files, and they don't have no appropriate dtb entries.
The question is what is the right way, from the kernel perspective of view, to port this? Do I need to make this old driver a platform device (now it is just a char device) and create appropriate dtb description for it? Or I can just use some kernel API to mark this interrupts as available? Is it a common/normal style?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am new here and am trying to develop a concept fs driver for the tar 'filesystem' (mount tar). My question is, how does the OS detect that a partition has the TAR filesystem and automatically load my driver?
first of all loaded FS called IoRegisterFileSystem - this routine inserts the device object into the list of file systems in the system. then you must have a WRK. when say file opened on device with VPB IopCheckVpbMounted is called and he call IopMountVolume - this is key point for mount understand. this routine first walk through list with registered FS and send IRP_MN_MOUNT_VOLUME to all until some FS not return success code. also the last entry in the list - special File system recognizer - he try determinate format of the volume. and if yes - he return STATUS_FS_DRIVER_REQUIRED - indicates that need load new FS for this volume. system in this case call IopLoadFileSystemDriver. this routine is invoked when a mini-file system recognizer driver recognizes a volume as being a particular file system, but the driver for that file system has not yet been loaded. at the current moment FS_Rec.sys support next FS:
cdfs
ReFS
ReFSv1 // begin from win 10
ExFat
FastFat
Udfs
Ntfs
for support other - you need or auto load self FS driver or self recognizer (mini driver) which recognize your FS and return STATUS_FS_DRIVER_REQUIRED on IRP_MJ_FILE_SYSTEM_CONTROL.IRP_MN_MOUNT_VOLUME and load your FS (by ZwLoadDriver call ) on IRP_MJ_FILE_SYSTEM_CONTROL.IRP_MN_LOAD_FILE_SYSTEM
I am writing a device driver for a PCIe card in Linux. I am trying to use interrupts in my driver.
Reading the "IRQ Line" section of the PCI configuration register (offset 0x3C) reports that the assigned IRQ line for the device is 11. lspci -b -vv also reports that my device's interrupt number is 11.
Heres where it gets weird... cat /sys/bus/pci/devices/<my_device>/irq reports that the interrupt number is 19. lspci -vv also reports that the interrupt number is 19.
Requesting 11 in my driver does not work. If I request 19 in the driver, I catch interrupts just fine.
What gives?
Thanks!!!
I believe that it has to do with the difference between "physical" and "virtual" IRQ lines. Because the processor has a limited number of physical IRQ lines it assigns virtual IRQ lines to allow the total number of PCI devices to exceed the number of physical lines.
In this instance, 19 is your virtual IRQ line (as recognized by the processor) while 11 is the physical line (as recognized by the PCI device).
By the way, you should probably really get the IRQ number from the struct pci_dev for that device since they're dynamically generated.
Sean's answer is easy to understand. However here I would try to make it more complete.
CPU's IRQ pin, almost always, isn't connected directly to a peripheral device, but via an programmable interrupt controller(PIC, e.g. Intel 8259A). This helps handling large device fan-out and also heterogeneous interrupt format (pin based v.s. message based as in PCIe).
If you run a recent version of lspci, it would print information like
Interrupt: pin A routed to IRQ 26
Here, pin A as 11 in OP, is the physical pin. This is something saved by the PCI device and used by the hardware to exchange between interrupts controller. From LDP:
The PCI set up code writes the pin number of the interrupt controller
into the PCI configuration header for each device. It determines the
interrupt pin (or IRQ) number using its knowledge of the PCI interrupt
routing topology together with the devices PCI slot number and which
PCI interrupt pin that it is using. The interrupt pin that a device
uses is fixed and is kept in a field in the PCI configuration header
for this device. It writes this information into the interrupt line
field that is reserved for this purpose. When the device driver runs,
it reads this information and uses it to request control of the
interrupt from the Linux kernel.
IRQ 26 as 19 in OP is something that kernel code and CPU deal with. According to Linux Documentation/IRQ.txt:
An IRQ number is a kernel identifier used to talk about a hardware
interrupt source. Typically this is an index into the global irq_desc
array, but except for what linux/interrupt.h implements the details
are architecture specific.
So the PCI first receives interrupts from device, translate interrupt source to a IRQ number and informs the CPU. CPU use IRQ number to look into Interrupt Descriptor Table(IDT) and find the correct software handler.
Ref:
http://www.tldp.org/LDP/tlk/dd/interrupts.html
http://www.brokenthorn.com/Resources/OSDevPic.html