These might all be merged into mainline already, if not, they should
be :)
:)
If the code is upstream, in the kernel.org releases, nothing new
should
need to be "ported", it should "just work". If not, we are doing
something wrong in the kernel development process.
For years arm code was patched from maxim's page not included to
mainline. There is a lot of platforms (eg. NXP LPC313x) not included to
mainline.
Interrupt/tasklets racing is not visible on machines like fast PC.
Even for current kernel, 280MHz CPU and eg. external UART chipset
the CPU under high load is not able to service interrupt before FIFO
overrun. Additional protection code must be added because UART
chip's FIFO blocks after the overrun and linux kernel drivers rule
"write simple as you can but not simpler" is not always good.
What FIFO are you talking about here? What driver is affected?
FIFO inside UART chip, eg. SC16C550B (NXP). Driver: very good 8250.c
(serial). I must add eg. Russell King extra debug, chip's FIFO reset if
problem detected (to be sure), config lowest FIFO trigger level for the
chip (CPU is slow). FIFO hangs after overrun but it is hardware issue -
not bug.
No, there are no plans to do this, it's a non-trivial task, one that
I
did for my employer once, and never want to, and never will, do again
(900+ patches to just get the USB 3.0 code working in the 2.6.32
kernel
release.)
wow, it's clear:)
usbmon should work on your existing kernel.
It works but I'm gathering knowledge and tips how to use collected data
to debug/identify my problem.
kind regards
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
