linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY
Date: Wed, 20 Sep 2017 20:23:50 +0200	[thread overview]
Message-ID: <20170920182350.GA21482@Red> (raw)
In-Reply-To: <CAL_JsqJ2eVA9Zg60Hagqm732ZoOzHWTwVBqOabOhjE5aQ26L+g@mail.gmail.com>

On Tue, Sep 19, 2017 at 09:49:52PM -0500, Rob Herring wrote:
> On Thu, Sep 14, 2017 at 2:19 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> > Is the MDIO controller "allwinner,sun8i-h3-emac" or "snps,dwmac-mdio"?
> >> > If the latter, then I think the node is fine, but then the mux should be
> >> > a child node of it. IOW, the child of an MDIO controller should either
> >> > be a mux node or slave devices.
> >
> > Hi Rob
> >
> > Up until now, children of an MDIO bus have been MDIO devices. Those
> > MDIO devices are either Ethernet PHYs, Ethernet Switches, or the
> > oddball devices that Broadcom iProc has, like generic PHYs.
> >
> > We have never had MDIO-muxes as MDIO children. A Mux is not an MDIO
> > device, and does not have the properties of an MDIO device. It is not
> > addressable on the MDIO bus. The current MUXes are addressed via GPIOs
> > or MMIO.
> 
> The DT parent/child relationship defines the bus topology. We describe
> MDIO buses in that way and if a mux is sitting between the controller
> and the devices, then the DT hierarchy should reflect that. Now
> sometimes we have 2 options for what interface has the parent/child
> relationship (e.g. an I2C controlled USB hub chip), but in this case
> we don't.
> 

Putting mdio-mux as a child of it (the mdio node) give me:
[   18.175338] libphy: stmmac: probed
[   18.175379] mdio_bus stmmac-0: /soc/ethernet at 1c30000/mdio/mdio-mux has invalid PHY address
[   18.175408] mdio_bus stmmac-0: scan phy mdio-mux at address 0
[   18.175450] mdio_bus stmmac-0: scan phy mdio-mux at address 1
[   18.175482] mdio_bus stmmac-0: scan phy mdio-mux at address 2
[   18.175513] mdio_bus stmmac-0: scan phy mdio-mux at address 3
[   18.175544] mdio_bus stmmac-0: scan phy mdio-mux at address 4
[   18.175575] mdio_bus stmmac-0: scan phy mdio-mux at address 5
[   18.175607] mdio_bus stmmac-0: scan phy mdio-mux at address 6
[   18.175638] mdio_bus stmmac-0: scan phy mdio-mux at address 7
[   18.175669] mdio_bus stmmac-0: scan phy mdio-mux at address 8
[   18.175700] mdio_bus stmmac-0: scan phy mdio-mux at address 9
[   18.175731] mdio_bus stmmac-0: scan phy mdio-mux at address 10
[   18.175762] mdio_bus stmmac-0: scan phy mdio-mux at address 11
[   18.175795] mdio_bus stmmac-0: scan phy mdio-mux at address 12
[   18.175827] mdio_bus stmmac-0: scan phy mdio-mux at address 13
[   18.175858] mdio_bus stmmac-0: scan phy mdio-mux at address 14
[   18.175889] mdio_bus stmmac-0: scan phy mdio-mux at address 15
[   18.175919] mdio_bus stmmac-0: scan phy mdio-mux at address 16
[   18.175951] mdio_bus stmmac-0: scan phy mdio-mux at address 17
[   18.175982] mdio_bus stmmac-0: scan phy mdio-mux at address 18
[   18.176014] mdio_bus stmmac-0: scan phy mdio-mux at address 19
[   18.176045] mdio_bus stmmac-0: scan phy mdio-mux at address 20
[   18.176076] mdio_bus stmmac-0: scan phy mdio-mux at address 21
[   18.176107] mdio_bus stmmac-0: scan phy mdio-mux at address 22
[   18.176139] mdio_bus stmmac-0: scan phy mdio-mux at address 23
[   18.176170] mdio_bus stmmac-0: scan phy mdio-mux at address 24
[   18.176202] mdio_bus stmmac-0: scan phy mdio-mux at address 25
[   18.176233] mdio_bus stmmac-0: scan phy mdio-mux at address 26
[   18.176271] mdio_bus stmmac-0: scan phy mdio-mux at address 27
[   18.176320] mdio_bus stmmac-0: scan phy mdio-mux at address 28
[   18.176371] mdio_bus stmmac-0: scan phy mdio-mux at address 29
[   18.176420] mdio_bus stmmac-0: scan phy mdio-mux at address 30
[   18.176452] mdio_bus stmmac-0: scan phy mdio-mux at address 31

Adding a fake <reg> to mdio-mux remove it, but I found that a bit ugly.
Or perhaps patching of_mdiobus_register() to not scan node with compatible "mdio-mux".

What do you think ?

Regards

  reply	other threads:[~2017-09-20 18:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08  7:11 [PATCH v5 00/10] net: stmmac: dwmac-sun8i: Handle integrated PHY Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 01/10] arm64: dts: allwinner: Restore EMAC changes Corentin Labbe
2017-09-08  7:19   ` Maxime Ripard
2017-09-08  7:36     ` Corentin Labbe
2017-09-08  7:39       ` Chen-Yu Tsai
2017-09-10 18:56         ` Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 02/10] dt-bindings: net: Restore sun8i dwmac binding Corentin Labbe
2017-09-13 18:07   ` Rob Herring
2017-09-14 18:31     ` Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 03/10] arm: dts: sunxi: Restore EMAC changes Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 04/10] net: stmmac: sun8i: Restore the compatibles Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY Corentin Labbe
2017-09-08  7:25   ` Maxime Ripard
2017-09-08  7:43     ` Corentin Labbe
2017-09-13 18:20       ` Rob Herring
2017-09-14 18:53         ` Corentin Labbe
2017-09-14 19:19           ` Andrew Lunn
2017-09-19  5:31             ` Corentin Labbe
2017-09-20  2:49             ` Rob Herring
2017-09-20 18:23               ` Corentin Labbe [this message]
2017-09-08  7:11 ` [PATCH v5 06/10] ARM: dts: sunxi: h3/h5: represent the mdio switch used by sun8i-h3-emac Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 07/10] arm64: dts: allwinner: add snps, dwmac-mdio compatible to emac/mdio Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 08/10] net: stmmac: dwmac-sun8i: choose internal PHY via phy-is-integrated Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 09/10] net: stmmac: snps, dwmac-mdio MDIOs are automatically registered Corentin Labbe
2017-09-08  7:11 ` [PATCH v5 10/10] net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs Corentin Labbe
2017-09-08 13:05   ` Andrew Lunn
2017-09-08 13:26     ` Corentin Labbe
2017-09-08 14:00       ` Andrew Lunn
2017-09-08 14:08         ` Corentin Labbe
2017-09-08 14:17           ` Andrew Lunn
2017-09-08 14:28             ` Corentin Labbe
2017-09-11 16:11               ` Andrew Lunn
2017-09-11 19:08                 ` Corentin Labbe
2017-09-11 20:19                   ` Andrew Lunn
2017-09-12  7:54                     ` Corentin Labbe

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=20170920182350.GA21482@Red \
    --to=clabbe.montjoie@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).