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] [day] [month] [year] [list]
Date:	Thu, 06 Jun 2013 09:53:41 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	"J, KEERTHY" <j-keerthy@...com>
CC:	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"wim@...ana.be" <wim@...ana.be>,
	"lgirdwood@...il.com" <lgirdwood@...il.com>,
	"Kristo, Tero" <t-kristo@...com>,
	"lee.jones@...aro.org" <lee.jones@...aro.org>,
	Ian Lartey <ian@...mlogic.co.uk>
Subject: Re: [PATCH v2] mfd: DT bindings for the palmas family MFD

On 06/05/2013 09:34 PM, J, KEERTHY wrote:
> Hi Stephen,
> 
> Thanks for the quick review.
> 
> Stephen Warren wrote at Wednesday, June 05, 2013 10:44 PM:
>> On 06/04/2013 02:41 AM, J Keerthy wrote:
>>> From: Graeme Gregory <gg@...mlogic.co.uk>
>>>
>>> Add the various binding files for the palmas family of chips. There is
>>> a top level MFD binding then a seperate binding for regulators IP
>> blocks on chips.
...
>> Oh, one question though: How does the regulator driver determine the
>> register address of the regulator sub-device within the overall PMIC?
>> Presumably if these are pluggable independent modules, that could
>> change depending on which overall chip the PMIC device is plugged into.
>> don't you need a reg property to specify that?
> 
> The variants have identical register addresses. These are not pluggable
> Independent modules. All the variants come with all the regulators
> Listed above in general. The driver today has a statically defined
> Array of all the above mentioned regulators with their addresses.
>  
> drivers/regulator/palmas-regulator.c
> 
> Line 38.

I meant the I2C address used to communicate with the regulator registers
really, and I suppose the base address of the regulator register block.

In the driver, I see this is handled by the top-level Palmas driver
creating a regmap object which the regulator driver used. This keeps the
regulator driver completely unaware of these issues, only the top-level
chip driver cares about this, which is fine.

While that justification is in terms of OS-specific code, the basic
argument can be applied to the HW itself (the top-level chip implies the
I2C address and any register offset), so this really is a HW-driven
argument, so I guess it's fine not having a reg property in the
top-level regulator node.

One question though: I wonder why if the HW IP blocks aren't completely
independent modules that can be mixed/matched together to form new
chips, there's even a need for a separate regulator node with its own
compatible value. Still, I suppose it's a valid way to construct the DT
either way, so it's fine.
--
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/

Powered by blists - more mailing lists