linux-kernel - Re: [PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

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: <531886B4.2070002@free-electrons.com>
Date:	Thu, 06 Mar 2014 15:31:16 +0100
From:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	Jason Cooper <jason@...edaemon.net>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org,
	Lior Amsalem <alior@...vell.com>,
	Tawfik Bayouk <tawfik@...vell.com>,
	Nadav Haklai <nadavh@...vell.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

On 06/03/2014 15:21, Andrew Lunn wrote:
>>> Hi Gregory
>>>
>>> I guess checkpatch.pl is probably complaining about missing vendor
>>> prefix?
>>>
>>
>> yes and also about m25p128 itself because it was not explicitly written
>> in Documentation/devicetree/bindings/. Actually it was written to "see the
>> "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of" the compatible
>> name.
>>
>> For the first warning I can add the vendor part, but for the other warning, do we
>> really want to copy the m25p_ids table in Documentation/devicetree/bindings/mtd/m25p80.txt ?
> 
> I think the DT Maintainers and checkpatch.pl maintainers need to think
> about this. Maybe a regex would be enough in
> Documentation/devicetree/bindings/mtd/m25p80.txt?
> 
> For the moment i would suggest adding a vendor prefix, but nothing
> more.

OK

> 
> 
>>>> +			/*
>>>> +			 * The Ethernet nodes are not ordered by
>>>> +			 * address on purpose. Indeed the first
>>>> +			 * Ethernet port of the board (Giga0) is
>>>> +			 * located at 0x70000 whereas the the second
>>>> +			 * Ethernet(Giga 1) port is located at
>>>> +			 * 0x30000.
>>>> +			 */
>>>> +
>>>> +			ethernet@...00 {
>>>> +				status = "okay";
>>>> +				phy = <&phy0>;
>>>> +				phy-mode = "rgmii";
>>>> +			};
>>>> +
>>>> +			ethernet@...00 {
>>>> +				status = "okay";
>>>> +				phy = <&phy1>;
>>>> +				phy-mode = "rgmii";
>>>> +			};
>>>> +
>>>
>>> I think you can use aliases to get the order correct, independent of
>>> how you list them in DT. That should be a lot safer than assuming
>>> things are instantiated from top to bottom.
>>
>> It sounds interesting, how would you do this?
> 
> As there already is in armada-370-xp.dtsi
> 
>         aliases {
>                 eth0 = &eth0;
>                 eth1 = &eth1;
>         };
> 
> 
> 	eth0: ethernet@...00 {
> 	}
>         eth1: ethernet@...00 {
> 	}
> 
> This at least works for i2c devices. The pdev->id is set using the
> alias number.

Well I think it doesn't work with ethernet devices because we already do
this in aramda-38x.dtsi:

	aliases {
		gpio0 = &gpio0;
		gpio1 = &gpio1;
		eth0 = &eth0;
		eth1 = &eth1;
		eth2 = &eth2;
	};

	eth1: ethernet@...00 {
	}
	eth2: ethernet@...00 {
	}
	eth0: ethernet@...00 {
	}


Thanks,

Gregory

> 
>       Andrew
> 
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/