linux-kernel - Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091026213450.GA19119@core.coreip.homeip.net>
Date:	Mon, 26 Oct 2009 14:34:50 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	?ric Piel <eric.piel@...mplin-utc.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work
	anymore

On Mon, Oct 26, 2009 at 01:59:53PM -0700, Greg KH wrote:
> On Thu, Oct 22, 2009 at 07:01:50PM -0700, Dmitry Torokhov wrote:
> > On Sun, Oct 18, 2009 at 01:02:38AM -0700, Greg KH wrote:
> > > On Sun, Oct 18, 2009 at 12:51:27AM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Oct 12, 2009 at 08:17:41PM -0700, Dmitry Torokhov wrote:
> > > > > On Mon, Oct 12, 2009 at 11:54:17AM -0700, Greg KH wrote:
> > > > > > On Mon, Oct 12, 2009 at 11:33:13AM -0700, Dmitry Torokhov wrote:
> > > > > > > On Mon, Oct 12, 2009 at 10:35:51AM -0700, Greg KH wrote:
> > > > > > > > On Mon, Oct 12, 2009 at 08:48:46AM -0700, Dmitry Torokhov wrote:
> > > > > > > > > > So at least, unbind should fail as well as bind.
> > > > > > > > > >
> > > > > > > > > 
> > > > > > > > > That would be Greg's domain s it is driver core decision whether to
> > > > > > > > > allow unbinding platform devices registered with
> > > > > > > > > platform_driver_probe().
> > > > > > > > 
> > > > > > > > No, I do not see why that should not be allowed.
> > > > > > > > 
> > > > > > > 
> > > > > > > Because once you did unbind the device you are stuck (unless the driver
> > > > > > > is compiled as a module, but then you could just unload the module
> > > > > > > instead of unbinding). Disallowing unbind would allow discarding not
> > > > > > > only __devinit but __devexit sections when driver is built in which
> > > > > > > would make ebedded people happy[^Hier].
> > > > > > 
> > > > > > Yeah, good point.
> > > > > > 
> > > > > > Does anyone do bind/unbind with platform devices today?
> > > > > > 
> > > > > > If not, a patch changing this would be welcome.
> > > > > > 
> > > > > 
> > > > > How about this one?
> > > > > 
> > > > 
> > > > *ping* We need to resolve this, otherwise everyone who likes to rebind
> > > > i8042 in couse of STR/STD will be in trouble.
> > > 
> > > Sorry, am in Tokyo right now.
> > > 
> > > I like this patch, and will queue it up, but it's too late for .32, it
> > > will have to wait for .33.
> > > 
> > 
> > Greg,
> > 
> > I hope you will reconsider. The patch is extremely small but without it
> > I am afraid many people whose distributions blindly rebind i8042 on
> > suspend/resume will lose their keyboards and mice now that i8042 uses
> > platform_driver_probe()...
> 
> What distros do something like that automatically? 

It looks SUSE recommends to do so in one of the Wikis.. There certainly
lots of recommendations to do so in case of keyboard resume troubles all
over the forums (Ubunto, Gentoo, other random ones).

> And this patch will
> not solve that problem, just forbid it from happening, right?
> 

It will prevent unbind from happening so that users who have suspend and
resume working properly but who have bind/unbind in their suspend/resume
scripts regardless will not run into trouble.

This still leaves users whose suspend/resume don't work by default but I
would rather fix their boxes properly instead of relying on that
workaround.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/