On Wed, Nov 12, 2008 at 10:15 PM, John W. Linville <linville@xxxxxxxxxxxxx> wrote: > On Mon, Nov 03, 2008 at 06:20:40PM +0100, Ivo van Doorn wrote: >> On Monday 03 November 2008, Henrique de Moraes Holschuh wrote: >> > On Mon, 03 Nov 2008, Ivo van Doorn wrote: >> > > On Monday 03 November 2008, Henrique de Moraes Holschuh wrote: >> > > > This small patchset contains two fixes to issues in the suspend/resume >> > > > handling of the rfkill class core. >> > > > >> > > > It needs to go to 2.6.28. These patches are based on 2.6.28-rc3. >> > > >> > > Are they real regressions or normal bugfixes? >> > >> > I am not sure if they regress anything, but I am pretty sure there is no >> > bugzilla entry about them yet. I have added two more interested parties to >> > the CC. >> > >> > So, if there is a strong feeling this would best be held until the next >> > merge window, I can certainly respin the patches to on top of >> > wireless-testing... >> >> Well I'll give my ACK to the 2 patches, but I'll let john decide if they >> are "regression" enough for 2.6.28. ;) > > So I keep looking at these patches, and I'm not sure about them. > It seems that they restore the rfkill state after resume to what it > was before the suspend. Wouldn't this break hw kill switches? If I move the switch while the system is suspended it will ignore this event but the hw will still not work. > What I am unsure about is whether or not > that is the appropriate thing to do. I suppose it makes sense under > the rule of least surprise. Well the above scenario would be just broken. Unless the driver rereads the real hw state and updates the rfkill state on resume. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
