Searched hist:d60626f8c11e3d76cb53c3ba16249c7b054c5a1e (Results 1 – 2 of 2) sorted by relevance
| /rk3399_rockchip-uboot/drivers/net/ |
| H A D | e1000.h | d60626f8c11e3d76cb53c3ba16249c7b054c5a1e Tue Oct 18 11:05:26 UTC 2011 Kyle Moffett <Kyle.D.Moffett@boeing.com> e1000: Restructure and streamline PCI device probing
By allocating the e1000 device structures much earlier, we can easily
generate better error messages and siginficantly clean things up.
The only user-visable change (aside from reworded error messages) is
that a detected e1000 device which fails to initialize due to software
or hardware error will still be allocated a device number.
As one example, consider a system with 2 e1000 PCI devices where the
first controller has a corrupted EEPROM. Using the old code the
second controller would be "e1000#0", while with this change it would be
"e1000#1".
This change should hopefully make such EEPROM errors much more
straightforward to handle correctly in boot scripts and the like.
It is also necessary for a followup patch which allows SPI programming
of an e1000 controller's EEPROM even if the checksum is invalid.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Cc: Ben Warren <biggerbadderben@gmail.com>
|
| H A D | e1000.c | d60626f8c11e3d76cb53c3ba16249c7b054c5a1e Tue Oct 18 11:05:26 UTC 2011 Kyle Moffett <Kyle.D.Moffett@boeing.com> e1000: Restructure and streamline PCI device probing
By allocating the e1000 device structures much earlier, we can easily
generate better error messages and siginficantly clean things up.
The only user-visable change (aside from reworded error messages) is
that a detected e1000 device which fails to initialize due to software
or hardware error will still be allocated a device number.
As one example, consider a system with 2 e1000 PCI devices where the
first controller has a corrupted EEPROM. Using the old code the
second controller would be "e1000#0", while with this change it would be
"e1000#1".
This change should hopefully make such EEPROM errors much more
straightforward to handle correctly in boot scripts and the like.
It is also necessary for a followup patch which allows SPI programming
of an e1000 controller's EEPROM even if the checksum is invalid.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Cc: Ben Warren <biggerbadderben@gmail.com>
|