Re: SMSC LAN9118 Family driver

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > > > 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?

I prefer:
"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.

>   ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/tmp/if_slan_gxio.c

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..)
---
Izumi Tsutsui