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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Dec 2013 21:05:22 +0100
From:	Jonas Jensen <jonas.jensen@...il.com>
To:	Peter Crosthwaite <peter.crosthwaite@...inx.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>
Subject: Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files

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.

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


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/