From: Scott Wood <scottwood@freescale.com>
To: Emil Medve <Emilian.Medve@Freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Date: Thu, 31 Jul 2014 13:30:33 -0500 [thread overview]
Message-ID: <1406831433.29414.339.camel@snotra.buserror.net> (raw)
In-Reply-To: <53D9D893.8090105@Freescale.com>
On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 07/31/2014 12:28 AM, Scott Wood wrote:
> > On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 07/30/2014 09:30 PM, Scott Wood wrote:
> >>> On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
> >>>>>>>> + mdio0: mdio <at> fc000 {
> >>>>>>>> + };
> >>>>>>>
> >>>>>>> Why is the empty node needed?
> >>>>>>
> >>>>>> For the label
> >>>>>
> >>>>> For mdio-parent-bus, or is there some other dts layer that makes this
> >>>>> node non-empty?
> >>>>
> >>>> 'powerpc/corenet: Create the dts components for the DPAA FMan' -
> >>>> http://patchwork.ozlabs.org/patch/370872
> >>>
> >>> Why does this patch define the mdio0 label for mdio@e1120, but not
> >>> define a label for any other node?
> >>
> >> Only MDIO controllers that are pinned out have these labels. Only pinned
> >> out MDIO(s) are capable of controlling external PHY(s) via these board
> >> level MDIO buses
> >
> > Is there any reason to describe non-pinned-out MDIO controllers at all?
>
> Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
> PHY that is attached to the MDIO controller of the respective MAC
OK, so similar to eTSEC. I didn't know if you were counting aTBI
connection as being (partially) pinned out.
> > Is the lack of pinning out inherent to the silicon, or is it board
> > design/config?
>
> It's a silicon level decision
So why is it the board file that adds the label, if it's always going to
be the same node?
> > I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
> > others are labelled elsewhere.
>
> Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
> bus muxing support to the board device tree(s)' -
> http://patchwork.ozlabs.org/patch/370866. Most labels are created and
> used in the board .dts file except b4qds.dtsi which is shared between
> b4420qds.dts and b4860qds.dts
I'm talking about qoriq-fman-0-1g-0.dtsi, not b4qds.dtsi. It labels
mdio@e1120 as mdio0.
In other words, why is the decision on where to label made differently
for fman v3 than for previous fman versions?
-Scott
next prev parent reply other threads:[~2014-07-31 18:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 20:17 [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 2/7] net/fsl_pq_mdio: Document supported compatibles Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 3/7] powerpc/corenet: Create the dts components for the DPAA FMan Shruti Kanetkar
2014-07-21 22:13 ` Scott Wood
2014-07-16 20:17 ` [PATCH v2 4/7] powerpc/corenet: Add DPAA FMan support to the SoC device tree(s) Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board " Shruti Kanetkar
2014-07-21 22:45 ` Scott Wood
2014-07-28 6:51 ` Emil Medve
2014-07-29 19:58 ` Scott Wood
2014-07-30 21:52 ` Emil Medve
2014-07-31 2:30 ` Scott Wood
2014-07-31 4:35 ` Emil Medve
2014-07-31 5:28 ` Scott Wood
2014-07-31 5:48 ` Emil Medve
2014-07-31 18:30 ` Scott Wood [this message]
2014-07-31 18:49 ` Emil Medve
2014-08-13 8:44 ` Shaohui Xie
2014-07-16 20:17 ` [PATCH v2 6/7] powerpc/corenet: Enable muxing MDIO buses via GPIO Shruti Kanetkar
2014-07-16 20:17 ` [PATCH v2 7/7] powerpc/corenet: Enable muxing MDIO buses via FPGA Shruti Kanetkar
2014-07-25 3:11 ` [PATCH v2 1/7] dt: Introduce the FMan 10 Gb/s MDIO binding Shaohui Xie
2014-07-25 19:54 ` Scott Wood
2014-07-26 8:17 ` Emil Medve
2014-07-25 20:00 ` Emil Medve
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1406831433.29414.339.camel@snotra.buserror.net \
--to=scottwood@freescale.com \
--cc=Emilian.Medve@Freescale.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.