linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Saravana Kannan <saravanak@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	netdev@vger.kernel.org, kernel-team@android.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Neil Armstrong <narmstrong@baylibre.com>,
	linux-amlogic@lists.infradead.org
Subject: Re: [PATCH v2] of: property: fw_devlink: Add support for "phy-handle" property
Date: Mon, 23 Aug 2021 21:50:39 +0200	[thread overview]
Message-ID: <YSP8D9SzN1wmQgtV@lunn.ch> (raw)
In-Reply-To: <CAGETcx_eUE1gLAaqXdLjCb2XxttH20066kXs969khnrEZQ71mA@mail.gmail.com>

On Mon, Aug 23, 2021 at 11:13:08AM -0700, Saravana Kannan wrote:
> On Mon, Aug 23, 2021 at 6:16 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Mon, Aug 23, 2021 at 02:08:48PM +0200, Marek Szyprowski wrote:
> > > Hi,
> > >
> > > On 18.08.2021 04:17, Saravana Kannan wrote:
> > > > Allows tracking dependencies between Ethernet PHYs and their consumers.
> > > >
> > > > Cc: Andrew Lunn <andrew@lunn.ch>
> > > > Cc: netdev@vger.kernel.org
> > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > >
> > > This patch landed recently in linux-next as commit cf4b94c8530d ("of:
> > > property: fw_devlink: Add support for "phy-handle" property"). It breaks
> > > ethernet operation on my Amlogic-based ARM64 boards: Odroid C4
> > > (arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts) and N2
> > > (meson-g12b-odroid-n2.dts) as well as Khadas VIM3/VIM3l
> > > (meson-g12b-a311d-khadas-vim3.dts and meson-sm1-khadas-vim3l.dts).
> > >
> > > In case of OdroidC4 I see the following entries in the
> > > /sys/kernel/debug/devices_deferred:
> > >
> > > ff64c000.mdio-multiplexer
> > > ff3f0000.ethernet
> > >
> > > Let me know if there is anything I can check to help debugging this issue.
> >
> > Hi Marek
> >
> > Please try this. Completetly untested, not even compile teseted:
> >
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index 0c0dc2e369c0..7c4e257c0a81 100644
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1292,6 +1292,7 @@ DEFINE_SIMPLE_PROP(resets, "resets", "#reset-cells")
> >  DEFINE_SIMPLE_PROP(leds, "leds", NULL)
> >  DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
> >  DEFINE_SIMPLE_PROP(phy_handle, "phy-handle", NULL)
> > +DEFINE_SIMPLE_PROP(mdio_parent_bus, "mdio-parent-bus", NULL);
> >  DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
> >  DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
> >
> > @@ -1381,6 +1382,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
> >         { .parse_prop = parse_leds, },
> >         { .parse_prop = parse_backlight, },
> >         { .parse_prop = parse_phy_handle, },
> > +       { .parse_prop = parse_mdio_parent_bus, },
> >         { .parse_prop = parse_gpio_compat, },
> >         { .parse_prop = parse_interrupts, },
> >         { .parse_prop = parse_regulators, },
> 
> Looking at the code, I'm fairly certain that the device that
> corresponds to a DT node pointed to by mdio-parent-bus will be a "bus"
> device that's registered with the mdio_bus_class.
> 
> If my understanding is right, then Nak for this patch. It'll break a
> lot of probes.
> 
> TL;DR is that stateful/managed device links don't make sense for
> devices that are never probed/bound to a driver.

So some more background, which might help you get an idea what is
going on here, and what you will need to implement.

There are a number of different ways an mdio bus driver can come into
existence.

They can be classical devices, which are described in device tree and
probed in the normal way. Most of the mdio bus drivers in
driver/net/mdio are like this, and they have documented bindings, and
compatible strings, e.g. Documentation/devicetree/bindings/net/marvell-orion-mdio.txt

Multiplexers, which are probably a subclass of the above classical
devices. They have documented binds and compatible strings. They link
to another MDIO bus, and some other resource to switch the
multiplexor, e.g, GPIOs, a MMIO register, a Linux multiplexer.

They can be embedded inside some other device, typically an Ethernet
controller, but also a Ethernet switch. In this case, the parent
device should have an MDIO node in its device tree. An example would
be the freescale FEC
Documentation/devicetree/bindings/net/fsl,fec.yaml So if you are
trying to fulfil dependencies for this sort of mdio bus, you need to
probe the FEC driver, and as a side effect, the MDIO bus driver will
pop into existence.

    Andrew


  reply	other threads:[~2021-08-23 19:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  2:17 Saravana Kannan
2021-08-18 17:00 ` Rob Herring
     [not found] ` <CGME20210823120849eucas1p11d3919886444358472be3edd1c662755@eucas1p1.samsung.com>
2021-08-23 12:08   ` Marek Szyprowski
2021-08-23 12:42     ` Rob Herring
2021-08-23 13:16     ` Andrew Lunn
2021-08-23 18:13       ` Saravana Kannan
2021-08-23 19:50         ` Andrew Lunn [this message]
2021-08-24  6:52       ` Marek Szyprowski
2021-08-23 18:22     ` Saravana Kannan
2021-08-23 19:58       ` Andrew Lunn
2021-08-23 20:48         ` Saravana Kannan
2021-08-23 22:01           ` Andrew Lunn
2021-08-23 22:08           ` Rob Herring
2021-08-24  7:03       ` Marek Szyprowski
2021-08-24  7:31         ` Saravana Kannan
2021-09-01  2:37           ` Saravana Kannan
2021-09-01  7:22             ` Marek Szyprowski
2021-09-08 21:58               ` [PATCH v1] RFC: of: property: fix phy-hanlde issue Saravana Kannan
2021-09-09  8:03                 ` Marek Szyprowski
2021-09-14  0:54                   ` Saravana Kannan
2021-09-14  4:44                     ` Saravana Kannan
2021-09-14  6:15                       ` Marek Szyprowski

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=YSP8D9SzN1wmQgtV@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=kernel-team@android.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=narmstrong@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --subject='Re: [PATCH v2] of: property: fw_devlink: Add support for "phy-handle" property' \
    /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

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).