Re: [RFC] New Driver Model for 2.5

Jonathan Lundell
2001-10-19T17:13:14Z

At 4:19 PM -0400 10/18/01, Jeff Garzik wrote:
> > In this particular case, of course, the driver can keep a soft copy
>> of the current MAC address and and restore from that, but that means
>> making special cases of special things.
>
>For that specific case, NIC drivers should read a copy of the MAC
>address at probe time, and store it in dev->dev_addr. Each power-up+if
>open cycle, the MAC address to programmed onto the NIC. So that is not
>a special case but the normal case, keeping a soft copy of the MAC.
>
>Just being picky :)

No, you're right, and it's especially true of NIC drivers. Partly, I
assume, because it's SOP in NIC drivers to routinely reinitialize the
hardware after various errors. And for Ethernet makes it easy,
because we're allowed to silently discard packets.

My own inclination would be to always keep enough information in
driver structures to reinitialize the device, though I'd hesitate to
assert that this is always possible, or practical.

WRT the suspend/resume sequence, I'd like to see the process
extensible. So, for example, a single suspend entry point with an
argument specifying the current action. The stuff I'm working on
requires a kind of "suspend with extreme prejudice" in which the
driver can't decline to suspend, as well as a suspend that comes
*after* a bus (therefore device) reset (which would explain my urge
to keep device state in soft structures). This is generally simple
enough for Ethernet drivers, but a little trickier for other devices.

BTW (and excuse me for not searching this out, if it's available), is
2.5 intended to have a real device tree? There's a related issue for
suspend/resume, namely the hierarchical relationship of some devices
(eg md->sd->adapter or whatever).
--
/Jonathan Lundell.