linux-kernel - Re: [PATCH] AB3100 regulator support v1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090901121212.GI19719@n2100.arm.linux.org.uk>
Date:	Tue, 1 Sep 2009 13:12:12 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Linus Walleij <linus.ml.walleij@...il.com>,
	linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [PATCH] AB3100 regulator support v1

On Sun, Aug 30, 2009 at 08:01:07PM +0100, Mark Brown wrote:
> On Sun, Aug 30, 2009 at 12:27:32PM -0400, Alan Stern wrote:
> > On Sun, 30 Aug 2009, Mark Brown wrote:
> 
> > > On the face of it (and without having actually looked at a running
> > > system or anything yet) I'm rather surprised that platform based MFD
> > > drivers aren't running into this issue more often.  CCing in Alan who
> > > made the change.
> 
> > I'm not at all familiar with the detailed issues involved here.  
> > Perhaps because of this, I don't see why there's any reason for
> > deadlocking.  __driver_attach() is invoked when a new driver is
> > registered; to avoid problems all you have to do is make sure you
> > aren't holding any device locks when you register a driver.
> 
> Ah, it's platform_driver_probe() that's causing issues.  When it is used
> the devices need to have been registered previously since the driver
> probe function isn't kept around.  In order to do this for the child
> device the driver for the subdevice has to be registered from within the
> probe function of the parent, which is itself happening within the
> parent device registration.

The simple solution to this is to avoid platform_driver_probe() in this
case.  platform_driver_probe() assumes that the device has already been
registered.  If it hasn't, then it really doesn't work.

Rather than plastering over platform_driver_probe() by playing games with
locks, it would be much better to do things the standard way and leave
the sub device probe code around such that it can cope with devices
registered after driver initialization.
--
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/