All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Adam Rudziński" <adam.rudzinski@arf.net.pl>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	robh+dt@kernel.org, frowand.list@gmail.com
Subject: Re: drivers/of/of_mdio.c needs a small modification
Date: Sat, 29 Aug 2020 20:01:35 +0200	[thread overview]
Message-ID: <79bcab16-5802-c075-1615-06c64078b6c9@arf.net.pl> (raw)
In-Reply-To: <20200829160047.GD2912863@lunn.ch>

W dniu 2020-08-29 o 18:00, Andrew Lunn pisze:
>> This is true assuming that the PHYs are always and forever connected to one
>> specific MDIO bus. This is probably reasonable. Although, in i.MX the MDIO
>> bus of FEC1 and FEC2 shares the pins.
> In general, they do not. In fact, i don't see how that can work. The
> FEC drive provides no mutual exclusion between MDIO operations on
> different MDIO controllers.
> (...)
> You have to decide which gets to control the bus, and the other
> controller is isolated.

Yes, true, but that was not what I meant. In i.MX6ULL MDIO buses of both 
FECs share the same pins, but of course only one can be active. It makes 
no sense to try to use both MDIO buses if the PHYs are connected to the 
same wires. I agree, the current state is good from this point of view.

I meant that with the split description of the mdio node the mdio bus 
for use in the system would be selected almost automatically. Suppose 
that I can do the device tree "my way":
&fec2 {
...
     mdio { phy2 ... };
...
};
&fec1 {
...
     mdio { phy1 ... };
...
};
This emphasizes which PHY is intended for use by which FEC, that's why 
it looks more natural for me.
Here, at least the FEC driver will automatically use MDIO bus from FEC2 
for all the PHYs.

Now suppose that I want to have a cheaper version, with only one 
Ethernet interface on board:
//&fec2 {
//...
//    mdio { phy2 ... };
//...
//};
&fec1 {
...
     mdio { phy1 ... };
...
};
Now, the system will use MDIO bus from FEC1.

This is just less playing with the device tree. But I agree, that you 
don't do that frequently, so that doesn't save much effort.
And, what this example doesn't show, is that the pin assignment has to 
be modfied - mdio pins have to get to fec1 now.

This way of building the device tree results from my proposition, but it 
was not my motivation.

Maybe it would be more useful if the device tree would be preprocessed 
and then compiled based on some conditions:

#if defined(CONFIG_USE_FEC2)
&fec2 {
...
     mdio { phy2 ... };
...
};
#endif
#if defined(CONFIG_USE_FEC1)
&fec1 {
...
     mdio { phy1 ... };
...
};
#endif

Best regards,
Adam


  reply	other threads:[~2020-08-29 18:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c8b74845-b9e1-6d85-3947-56333b73d756@arf.net.pl>
2020-08-28 22:28 ` drivers/of/of_mdio.c needs a small modification Andrew Lunn
2020-08-28 22:34   ` Adam Rudziński
2020-08-28 22:53     ` Andrew Lunn
2020-08-28 23:14       ` Adam Rudziński
2020-08-29  3:29         ` Florian Fainelli
2020-08-29  8:15           ` Adam Rudziński
2020-08-29 15:15             ` Andrew Lunn
2020-08-29 15:37               ` Adam Rudziński
2020-08-29 16:00                 ` Andrew Lunn
2020-08-29 18:01                   ` Adam Rudziński [this message]
2020-08-29 23:16                     ` Andrew Lunn
2020-08-30 20:47                       ` Adam Rudziński

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=79bcab16-5802-c075-1615-06c64078b6c9@arf.net.pl \
    --to=adam.rudzinski@arf.net.pl \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.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.