CF8385 issues on older kernel
hs4233 at mail.mn-solutions.de
Mon Apr 27 07:24:50 EDT 2009
> Looking at the current mainline kernel, this code is still
> present, in mostly the same form as it was in the above patch.
> What exactly is the BUG_ON checking for here, and what can go
> wrong to trigger the bug?
static void if_cs_send_data(struct lbs_private *priv, u8 *buf,
struct if_cs_card *card = (struct if_cs_card
+ u16 status;
+ status = if_cs_read16(card, IF_CS_C_STATUS);
+ BUG_ON((status & IF_CS_C_S_TX_DNLD_RDY) == 0);
The routine we're in is trying to send some data. You can only
send data into the chip if the chip says "Hey, I'm ready". If
everything is right, you'll always get the "I'm ready" response
from the status register. And if you don't get it, then
something very serious is broken. This is detected by the
> Also, isn't bugging in a driver
> reasonably drastic?
Yes, it's very drastic. It causes a hard crash of the whole
system. This is hopefully a good enought incentive to think
about the problem and fixing it.
Some systems automatically collect kernel oopses and send them to
http://www.kerneloops.org/, so developers are made aware of the
BTW: on my hardware, I never get a crash in this
BUG_ON-statement, so for my environment, the code seems to be
reasonably correct. We have deployed over 250 systems with that
card to various customers (I don't know exact counts because I'm
in R&D, not in sales :-)
> Would it not be better to return an error
> condition, which propogates back to a transmit failed at the
> upper networking layer?
That's debatable. My opininion is "No, better fix the driver,
hardware and/or firmware".
The code that sends data won't know what to do with such an error
anyway. A check in user-space can only be a workaround, a proper
fix of the cause is always desirable. At least that's the way
Linux' kernel code is usually designed. Let errors be viewable
and not pasted over.
Your mileage may vary :-)
More information about the libertas-dev