linux-kernel - Re: [PATCH 1/2] regulator: new driver for the AD5398 and AD5821

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: <20100603190858.GK2762@rakim.wolfsonmicro.main>
Date:	Thu, 3 Jun 2010 20:08:59 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	Mike Frysinger <vapier@...too.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>,
	"Zhang, Sonic" <Sonic.Zhang@...log.com>
Subject: Re: [PATCH 1/2] regulator: new driver for the AD5398 and AD5821

On Thu, Jun 03, 2010 at 02:59:53PM -0400, Robin Getz wrote:
> On Tue 1 Jun 2010 10:37, Mark Brown pondered:

> > Why are the current bits and offset being suppied as platform data?  I
> > would *very* strongly expect that the location of the control in the
> > register will be fixed by the device type and should therefore be
> > figured out by the driver.  Having the machine specifying this seems
> > redundant and error prone.

> Since the parts are general purpose (their not PMU, but people use them to 
> build their own PCB defined power management system) - so it depends on the 
> PCB implementation...

Please look more closely at what's actually being done by the code here.
This is controlling the location of the bitfields in the register map.
It would be exceptionally unusal for the PCB design and layout to affect
the register map of the device at all - this will be fixed in silicon no
matter how the system is wired up.  Even without a regulator framework
there would be no need to specify where the bitfields in the register
map are located via platform data.

As far as system specific integration goes the regulator driver should
only be worrying about the properties of the chip, other parts of the
regulator API handle the board-specific setup.

> http://www.analog.com/ad5398 
> http://www.analog.com/ad5821
> are both I2C D/A Converter, with 120mA sink capability

This is not at all unusual for drivers/regulator except in that it's a
current regulator and voltage regulators are very much more common.
--
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/