Jason Thorpe wrote:
> 
> We're talking about a built-in device on a specific model of board, 
> right?  If that's the case, then platform-specific code is allowed to 
> have knowledge of the physical location of that device, otherwise, how 
> does your MD hook know it's supposed to supply the Ethernet address?  
> ...since your original patch did not include an example of that [because 
> the MD code is proprietary?], I merely assumed that it was doing the 
> appropriate checking ... otherwise, how would it distinguish between the 
> on-board Ethernet and a plug-in card that simply has had its EEPROM 
> trashed somehow (something that has happened to me at least a few times 
> during driver development over the years :-)?

No, the MD code is not proprietary, and was going to follow in a 
separate commit.

If the EEPROM is trashed, all bets are off. Using the same configuration 
parameters as the on-board card seems at least as likely to render a 
working card as randomly scrambled data from an EEPROM. Although I think 
it's probably best at this point to warn and/or bail for a plug-in card 
with a trashed EEPROM.

(if it's trashed because you're developing a driver for it and poked at 
the wrong registers, you are clearly in the right area to poke at those 
registers again. if it's trashed for different reasons, you probably 
shouldn't be using it on a real network, right?)

>> I'd like to do this, but only if there's a reliable way of determining 
>> which device to set the properties for.
> 
> I'm about to check in in the following change to the "algor" port that 
> should provide a good example of how to do this:

Thanks for the example. It looks like what I probably want to be doing 
here. :)