[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: SMSC LAN9118 Family driver
> > > > I.e. is the EEPROM backend dependent or each evaluation board dependent?
> > >
> > > No, isn't. Maybe it evalusion board dependent.
> > >
> > > > If some on-board ISA-based smsh(4) doesn't have EEPROM
> > > > but other smsh(4) on the ISA slot might have EEPROM,
> > > > it should be handled by proplib, like wm(4) on iyonix.
> > >
> > > I think that the case is very rare. I think that I can remove EEPROM.
> > > For instance, re(4) and tlp(4), etc. Should we use proplib in
> > > if_ethersubr.c::ether_ifattach() if it worries about such a case?
> > On-board wm(4) on iyonix doesn't have EEPROM and it uses proplib.
> It use in pci/if_wm.c.
pci/if_wm.c is not a backend. It's an actual driver itself
and ether_ifattach() is called from pci/if_wm.c.
> > On-board ahc(4) on O2 doesn't have EEPROM and it uses proplib.
> For this case, it use in pci/ahc_pci.c. Not use in ic/aic7xxx.c.
Because the AHC_USEDEFAULTS flag and SCSI ID are handled and configured
in pci/ahc_pci.c even in the default (no proplib) case.
In smsh(4) case, is there any reason why it can't be handled
in MI dev/ic/lan9118.c, where the MAC address is actually required?
"The default is LAN9118_ADDR[HL], exceptions are handled by proplib"
unless the exceptions are backend specific.
Even if you don't like to use proplib for such rare cases
(because most on-board backends may be board specific),
the "if (myea == NULL)" check looks weird for me.
If the backend indicates "no EEPROM" quirk explicitly in sc_flags
and its specific MAC address is passed via sc->sc_enaddr,
it's acceptable for me.
It looks system_serial_high and system_serial_low are board specific
and declared in board_machdep.c etc.
(BTW, I wonder if it has proper vendor code..)
Main Index |
Thread Index |