Date: Thu, 14 Dec 2000 13:24:02 -0700 From: Warner Losh <imp@village.org> To: arch@freebsd.org Subject: Minor proposed change to suspend/resume Message-ID: <200012142024.NAA49965@harmony.village.org>
next in thread | raw e-mail | index | archive | help
In talking about some improvements to cardbus that Justin is making, he's managed to convince me that allowing for suspend/resume in pccard/cardbus is a good idea. Between us we've hammered out a protocol that should work and will degenerate to the old behavior. First, the suspend routine will be responsible for putting the device into a state that can be suspended. This is as it is today. If it cannot do so because the device is busy or otherwise temporary unable to suspend, it should return EBUSY. If it cannot do so because it has no way of detecting the device is the same on resume as before, then it should return ENODEV. For devices that return ENODEV, the parent bus will detach that child before the suspend. For resume, the bus will make its best effort to see if the device is the same as it was when it left. This check is intended to be really simple (eg make sure that the vendor, device, subvendor and subdevice are the same as before on PCI). If the bus thinks the card might be the same one, it will call the device's resume routine. The device will check to make sure it is the "same one" that was there before (eg for NIC cards that it has the same MAC address, for sio maybe that it is still a 16550). If not, it returns an error (I suggest ENXIO). If successful, it will then generally need to initialize its hardware since suspend/resume will generally reset the hardware. This is bus specific, but is a common trait of all busses current extant, except maybe usb, so it should be viewed as advice. If the resume routine returns an error, the parent bus will detach the device. Parent busses need not participate in this protocol if they don't want to. It is only for those buses that have removable parts. pccard and cardbus are top of the list, but PCI might be on the list depending on how CompactPCI's hot plug stuff is integrated into the kernel in the future. There's also mini-pci in notebooks. Suspend to disk, pop out the minipci card and resume is physically possible. The above proposal is a minor change to the current way that we're doing suspend and resume. Right now it is simpler: default to a routine that always returns 0 (this won't change), non-zero on suspend means abort the suspend and call everybody's resume routine who has been suspended so far. I'm not sure what errors on resume are supposed to mean, but the current bus_generic_resume does nothing on errors. I have added conventions: The return value from suspend can be meaningful. The failure of resume means detach the device and reprobe that slot. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012142024.NAA49965>