linux-kernel - Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init

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: <20111020061408.GE32007@S2100-06.ap.freescale.net>
Date:	Thu, 20 Oct 2011 14:14:09 +0800
From:	Shawn Guo <shawn.guo@...escale.com>
To:	Rajendra Nayak <rnayak@...com>
CC:	<broonie@...nsource.wolfsonmicro.com>, <grant.likely@...retlab.ca>,
	<patches@...aro.org>, <tony@...mide.com>,
	<devicetree-discuss@...ts.ozlabs.org>,
	<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<lrg@...com>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 3/5] regulator: helper routine to extract
 regulator_init_data

On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> >Let's look at mc13892-regulator driver.  There are 23 regulators defined
> >in array mc13892_regulators.  Needless to say, there is a dev behind
> >mc13892-regulator driver.  And when getting probed, this driver will
> >call regulator_register() to register those 23 regulators individually.
> >That said, for non-dt world, we have 1 + 23 'dev' with that 1 as the
> >parent of all other 23 'dev' (wrapped by regulator_dev).  But with the
> >current DT implementation, we will have at least 1 + 23 * 2 'dev'.
> >These extra 23 'dev' is totally new with DT.
> >
> 
> but thats only because the mc13892-regulator driver is implemeted in
> such a way that all the regulators on the platform are bundled in as
> *one* device.

I did not look into too many regulator drivers, but I expect this is
way that most regulator drivers are implemented in.  Having
mc13892-regulator being probed 23 times to register these 23 regulators
just makes less sense to me.

> It would again depend on how you would pass these from
> the DT, if you indeed stick to the same way of bundling all regulators
> as one device from DT, the mc13892-regulator probe would just get called
> once and there would be one device associated, no?
> 
Yes, I indeed would stick to the same way of bundling the registration
of all regulators with mc13892-regulator being probed once.  The problem
I have with the current regulator core DT implementation is that it
assumes the device_node of rdev->dev (dev wrapped in regulator_dev) is
being attached to rdev->dev.parent rather than itself.  Back to
mc13892-regulator example, that said, it requires the dev of
mc13892-regulator have the device_node of individual regulator attached
to.  IOW, the current implementation forces mc13892-regulator to be
probed 23 times to register those 23 regulators.  This is wrong to me.

-- 
Regards,
Shawn

--
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/