From mboxrd@z Thu Jan  1 00:00:00 1970
From: Amit Tomer <amittomer25@gmail.com>
Date: Tue, 12 May 2020 20:07:19 +0530
Subject: [PATCH v1 5/7] arm: dts: s700: add node for ethernet controller
In-Reply-To: <17165fd0-fd21-8262-91e7-b8c347818e86@arm.com>
References: <1589034315-19722-1-git-send-email-amittomer25@gmail.com>
 <1589034315-19722-6-git-send-email-amittomer25@gmail.com>
 <17165fd0-fd21-8262-91e7-b8c347818e86@arm.com>
Message-ID: <CABHD4K9VdTHYmJJDdUaGSWcJr0K+5Av625c9WYS=UvMG-kRsFg@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

On Tue, May 12, 2020 at 7:49 PM Andr? Przywara <andre.przywara@arm.com> wrote:
>
> On 09/05/2020 15:25, Amit Singh Tomar wrote:
> > This patch adds node for ethernet controller found on Action Semi OWL
> > S700 SoC.
> >
> > Since, there is no upstream Linux binding exist for S700 ethernet
> > controller, Changes are put in u-boot specific dtsi file.
>
> But that should not be the S700 SoC .dtsi, instead the cubieboard .dts
> file, since you specify the PHY mode in here (which is board specific).

But MAC is present on SoC , so I thought of adding it s700 specific
u-boot.dtsi as
it is already hosting few other things .

> > Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> > ---
> >  arch/arm/dts/s700-u-boot.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
> > index a527cccc75f2..1b2768272c62 100644
> > --- a/arch/arm/dts/s700-u-boot.dtsi
> > +++ b/arch/arm/dts/s700-u-boot.dtsi
> > @@ -6,6 +6,19 @@
> >  /{
> >       soc {
> >               u-boot,dm-pre-reloc;
> > +
> > +             gmac:  ethernet at e0220000 {
> > +                     compatible = "actions,s700-ethernet";
> > +                     reg = <0 0xe0220000 0 0x2000>;
> > +                     interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> > +                     interrupt-names = "macirq";
> > +                     local-mac-address = [ 00 18 fe 66 66 66 ];
>
> Is there another solution to that? Maybe put that in the environment
> instead? Or generate this randomly or ideally by hashing some serial number?

Yeah, I tried having "CONFIG_NET_RANDOM_ETHADDR" other day which seems
to work(would double check it).

But is there a reason not to use "local-mac-address", since driver
does not support parsing this
property ?

Thanks
-Amit.