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: <52DEF56C.1000209@ti.com>
Date:	Tue, 21 Jan 2014 16:32:12 -0600
From:	Nishanth Menon <nm@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	<devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: ti-abb: Add support for interleaved LDO registers

On 01/21/2014 03:56 PM, Mark Brown wrote:
> On Tue, Jan 21, 2014 at 02:06:25PM -0600, Nishanth Menon wrote:
> 
>> Without this change, on DRA7 I get:
>> [    0.579500] abb_mpu: 1060 <--> 1210 mV
>> [    0.580321] abb_ivahd: 1055 <--> 1250 mV
>> [    0.580583] ti_abb 4ae07e20.regulator-abb-dspeve: can't request
>> region for resource [mem 0x4ae07e20-0x4ae07e2f]
>> [    0.580610] ti_abb: probe of 4ae07e20.regulator-abb-dspeve failed
>> with error -16
>> [    0.581216] abb_gpu: 1090 <--> 1280 mV
> 
> OK, that's not to do with nocache, that's to do with duplicate
> request_mem_region() calls.  Of course the trick here is that if the
> other thing that requests the memory region doesn't do it then we have a
> problem.  
Yes. Both mappings are for ABB driver itself due to the interleaved
addresses for two ABB instances :(

> 
> I really can't help thinking that a system controller node as the parent
> is going to make things happier for devices that share this register
> bank.  I guess it might be possible to also do it with single register
> memory regions but I'd not be surprised if that wasn't possible and it
> doesn't seem as idiomatic.
> 
I am tempted by syscon and using regmap. but doing a syscon on entire
control module has impact to a bunch of drivers as you can expect.

The other alternative will be to use reg-names and map individual
registers (there are just setup and control registers to deal with per
abb instance). That will coexist with other pinctrl, bandgap and other
drivers which are not based off syscon.


-- 
Regards,
Nishanth Menon
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ