netdev - Re: [PATCH] Documentation: bindings: net: DPAA corenet binding document

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] [day] [month] [year] [list]

Date:	Wed, 3 Dec 2014 16:01:28 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Bucur Madalin-Cristian-B32716 <madalin.bucur@...escale.com>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Medve Emilian-EMMEDVE1 <Emilian.Medve@...escale.com>,
	Liberman Igal-B31950 <Igal.Liberman@...escale.com>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	Shaohui Xie <Shaohui.Xie@...escale.com>
Subject: Re: [PATCH] Documentation: bindings: net: DPAA corenet binding
 document

On Tue, 2014-12-02 at 17:03 -0600, Scott Wood wrote:
> On Tue, 2014-12-02 at 06:12 -0600, Bucur Madalin-Cristian-B32716 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, December 02, 2014 6:40 AM
> > >
> > > No need for the <SoC> part.  As we previously discussed, the only
> > > purpose of this node is backwards compatibility with the U-Boot MAC
> > > address fixup -- if U-Boot doesn't look for the <SoC> version, then
> > > don't complicate things.
> > > 
> > > Though, I can't find where U-Boot references this node.  Are you sure
> > > it's not using the ethernet%d aliases like everything else, in which
> > > case why do we need this node at all?
> > > 
> > > -Scott
> > > 
> > 
> > The initial (Freescale SDK) binding document contained those compatibles,
> > not sure what the initial intent was for the <SoC> variants.
> > 
> > The "fsl,dpaa" node is of interest to the DPAA Ethernet because it is
> > the parent of the "fsl,dpa-ethernet" nodes.
> 
> I'm not interested in what the SDK binding says, or what the SDK kernel
> does.  I'm interested in whether there's a U-Boot compatibility issue,
> as was previously alleged.  If there isn't, then there's no need for
> fsl,dpaa *or* fsl,dpa-ethernet.

OK, I found the U-Boot fixup in question.  It's not for MAC addresses,
but for marking disabled ports as disabled.  It marks the dpa-ethernet
node as disabled, based on it having an fsl,fman-mac property that
points to the MAC node.

U-Boot also disables the MAC node itself, so it doesn't matter if it
doesn't find fsl,fman-mac -- except for the special case of fm1-dtsec1,
which is always kept enabled because it's used for MDIO for all ports.

Based on http://patchwork.ozlabs.org/patch/410770/ there's a separate
node for mdio, so why can't we mark the MAC disabled?  Assuming that
there's no real problem in marking the fm1-dtsec1 MAC node disabled, we
can consider this to be a bug in U-Boot which can be worked around by
having the fm1-dtsec1 mac node have an fsl,fman-mac property that points
to itself.  This property would only go on the fm1-dtsec1 mac node and
would only be in device trees for SoCs that are supported by U-Boots old
enough to not have had the bug be fixed.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html