linux-kernel - Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files

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: <CAEgOgz6qz8ES_rQX8+UE-Ukh=G=_kHnAWJLQ-sUm6vkz=Xa7pg@mail.gmail.com>
Date:	Tue, 17 Dec 2013 09:53:27 +1000
From:	Peter Crosthwaite <peter.crosthwaite@...inx.com>
To:	Jonas Jensen <jonas.jensen@...il.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"arm@...nel.org" <arm@...nel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	devicetree@...r.kernel.org,
	Soren Brinkmann <soren.brinkmann@...inx.com>
Subject: Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files

On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen <jonas.jensen@...il.com> wrote:
> On 15 December 2013 05:27, Peter Crosthwaite
> <peter.crosthwaite@...inx.com> wrote:
>>> +       sdhci: sdhci@...00000 {
>>> +               compatible = "moxa,moxart-sdhci";
>>> +               reg = <0x98e00000 0x5C>;
>>> +               interrupts = <5 0>;
>>> +               clocks = <&clk_apb>;
>>> +               dmas =  <&dma 5>,
>>> +                       <&dma 5>;
>>> +               dma-names = "tx", "rx";
>>> +       };
>>
>> Is your SDHCI really implemented on the board level? The fact that its
>> reg property is within the same as the SoC range (for your dtsi)
>> suggests the SDHCI is part of the SoC and should perhaps be in the
>> dtsi?
>
>>> +       mac1: mac@...00000 {
>>> +               compatible = "moxa,moxart-mac";
>>> +               reg = <0x92000000 0x90>;
>>> +               interrupts = <27 0>;
>>> +               phy-handle = <&ethphy1>;
>>> +               phy-mode = "mii";
>>> +       };
>>
>> Same for MACs.
>
>>> +
>>> +       uart0: uart@...00000 {
>>> +               compatible = "ns16550a";
>>> +               reg = <0x98200000 0x20>;
>>> +               interrupts = <31 8>;
>>> +               reg-shift = <2>;
>>> +               reg-io-width = <4>;
>>> +               clock-frequency = <14745600>;
>>> +               status = "okay";
>>> +       };
>>> +
>>
>> And UARTs.
>>
>> Let me know if i'm misunderstanding dts/dtsi split but looking at some
>> of the other SoCs this seems inconsistent to me.
>
>
> It is likely to be true, that technically these are all part of the
> SoC. By examining the hardware, there are no external chips (on either
> base or main board) that looks capable of handling such functions:
>
> https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953
>
> I made the split with some consideration to other MOXA ART machines,
> that they can be added as a separate file including the same dtsi:
>
> MOXA ART hardware examples:
>
> UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)":
> http://www.moxa.com/product/UC-7112_UC-7110.htm
>
> IA241: "64 MB RAM":
> http://www.moxa.com/product/IA241_IA240.htm
>
> UC-7101-LX: "One 10/100 Mbps Ethernet port":
> http://www.moxa.com/product/UC-7101-LX.htm
>
>
> UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think
> MAC is good as is, RAM should move out from SoC?
>
> I don't know if they all have a debug UART (I only have access to
> UC-7112-LX), and it's not obvious in specifications. UART can possibly
> be moved into SoC as you say.
>

I think its going to all be in the SoC. Having it board level would
mean you have a system bus as copper which is not very SoC like (at
least for UART anyway).

> In cases where SD slot is missing but the register remains in the SoC,
> how is that normally handled?
>

Soren Brinkmann's recent addition of ethernet to the Zynq SoC
illustrates the concept for a MAC. The two MACs are added to the
shared dtsi but disabled. The board level dts then enables it for the
one which is board populated:

https://lkml.org/lkml/2013/12/11/434

I think its generally applicable to your SD MAC and UART cases. The
tegra20 dtsi illustrates the status = "disabled" concept specifically
for SDHCI.

Regards,
Peter

>
> Regards,
> Jonas
> --
> 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/
--
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/