CF8385 issues on older kernel

Holger Schurig hs4233 at
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, 
u16 nb)
        struct if_cs_card *card = (struct if_cs_card 
+       u16 status;
+       if_cs_disable_ints(card);
+       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, 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 mailing list