From: Milan Plzik <milan.plzik@gm...> - 2008-10-04 16:54:57
first of all, I apologize for posting this e-mail more times -- I
tried sending it to the mailing list via gmail smtp, but it probably got
blocked; then privately to Samuel Ortiz, but he did not respond (maybe
spamfilter?). Sorry for possible duplicates :).
Recently I've been implementing IrDA support for one ARM board (uses
pxaficp_ir driver; in fact re-implementing, as the same code for 2.6.21
already works pretty nicely) in current linux-arm master branch;
unfortunately, the code did not work.
Further examination has shown that the IrDA transceiver always works
on 9600 bauds (when forcing this as maximal baudrate, things seem to
work). From what I was able to find, it looks like IrDA stack stores
instruction on how to manage speed to skb->cb structure, but according
to documentation, the content of this structure is owned by layer in
which the packet is enqueued.
It looks like in recent versions of kernel, linux general networking
layer starts using skb->cb to store some qdisc data
(include/net/sch_generic.h, e.g. qdisc_enqueue_root). This in the end
overwrites (at least) LAP_MAGIC stored in 'cb' by IrDA stack, preventing
low-level drivers from changing their operation speed.
Unfortunately, I could not find any quick and clean fix for this so
there is no patch attached; it doesn't seem like fixable without
changing few other pieces of code (or just delaying the needed rewrite
by placing the data farther into the 'cb'). Maybe it could be solved
similar way as the mac80211 layer solves it -- the low-level drivers
provide method to set their rate.