[rt2x00-users] [PATCH 1/4] rt2x00: if we do not support the RF chip, return ENOTSUPP

[Thadeu Lima de Souza Cascardo]

On Mon, Aug 31, 2009 at 11:40:12PM +0200, Ivo van Doorn wrote:
> On Monday 31 August 2009, Thadeu Lima de Souza Cascardo wrote:
> > In rt2800pci, when probing, if we find a chip we do not support, we may
> > end up allocating 0 channels, which will oops. We may assume other chips
> > have 14 channels or return ENOTSUPP, which is what we do by now. We may
> > change this later.
> 
> Actuall the reason why this oopses is because not all RF values were handled in the switch.
> I'll fix that, but perhaps we should have a check in rt2x00lib to see if the spec structure
> was properly initialized. That way all other drivers are checked as well.
> 
> Ivo
> 

Yes, other drivers seem to present the same issue. In the case of
rt2800pci, init_eeprom, which is called before probe_hw_mode, will
return failure, in case it identifies a RF chip it does not support.
However, not all of said supported chips were/are present in the
probe_hw_mode "switch". Besides RF3020, RF2020 is also missing. So, if
we find any of these two devices, we get the oops.

In the rt2800usb case, I've just checked that all supported chips in
init_eeprom are handled in probe_hw_mode. I didn't check any other one.

Anyway, I think it's good practice to handle the default case. If we can
make sure (like in the rt2800usb case) that it's not possible, perhaps,
even a WARN would be a waste of code. But, then, that's a matter of good
software maintenance versus robustness versus size.

I am OK with only handling both missing chips (in fact, only the RF2020,
since you've applied the RF3020 case). That was just a patch that I
thought we could have to avoid oopsing in case another chip wasn't
handled. Considering init_eeprom will already return an error and output
an error message, it's enough.

Regards,
Cascardo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20090831/27728fa1/attachment-0001.bin>