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: <51F67AD8.1070904@gmail.com>
Date:	Mon, 29 Jul 2013 16:23:20 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>
CC:	Russell King <linux@....linux.org.uk>,
	Jason Cooper <jason@...edaemon.net>,
	Andrew Lunn <andrew@...n.ch>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] ARM: dove: add MBus DT node

On 07/29/2013 03:52 PM, Ezequiel Garcia wrote:
> Hi Sebastian,
>
> (Ccing devicetree ML)
>
> On Mon, Jul 29, 2013 at 02:36:46PM +0200, Sebastian Hesselbarth wrote:
>> On 07/29/2013 02:31 PM, Sebastian Hesselbarth wrote:
>>> This adds a MBus node including ranges and pcie apertures required later.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
>>> ---
>>>    arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
>>>    1 file changed, 19 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
>>> index 397674c..bdda016 100644
>>> --- a/arch/arm/boot/dts/dove.dtsi
>>> +++ b/arch/arm/boot/dts/dove.dtsi
>>> @@ -29,6 +29,20 @@
>>>    		marvell,tauros2-cache-features = <0>;
>>>    	};
>>>
>>> +	mbus {
>>> +		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
>>> +		#address-cells = <2>;
>>> +		#size-cells = <1>;
>>> +		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
>>> +		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */
>>
>> Actually, current v9 of the mbus patch set still requires "controller"
>> property to match the corresponding controller node. I had a short
>> discussion with Ezequiel to possibly just use of_find_compatible_node
>> and blindly assumed post-v8 will already use it.
>
> Ah, regarding this: despite your good arguin against the 'controller' property approach,
> I still feel a bit inclined for it, as I like the way it tightly-binds the two nodes.

I understand that the phandle property *shows* you that both are
related. But with DT you should always ask for every property, if
(a) it is really required to do the job and (b) does it really
describe the HW or just your SW needs/wishes.

So for the phandle property, I'd prefer to not put it into DT but
let the driver handle it.

Sebastian

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