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]

Date:	Mon, 16 Dec 2013 16:09:52 -0800
From:	Sören Brinkmann <soren.brinkmann@...inx.com>
To:	Peter Crosthwaite <peter.crosthwaite@...inx.com>
CC:	Jonas Jensen <jonas.jensen@...il.com>,
	"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>
Subject: Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree
 files

Hi,

On Tue, Dec 17, 2013 at 09:53:27AM +1000, Peter Crosthwaite wrote:
> 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.

I think it's less SoC vs. non-SoC parts. There are even platforms using
more than two levels of includes. IMHO, it's just to avoid duplication.
So, stuff that doesn't change ever goes into the lowest level dtsi and
then you work your way up. That way people bringing up a board with your
part just have to enable the correct set of peripherals and provide
board specific properties. You don't want everybody to repeat the same
memory map (reg properties), clock references, etc. over and over again
in all dtses that use a specific SoC, right?

Long story short: I separate by: Properties that are statically defined
by the SOC => dtsi. Properties that are defined by the PCB design =>
board level dts.

	Sören


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