From: Florian Fainelli <f.fainelli@gmail•com>
To: Grant Edwards <grant.b.edwards@gmail•com>,
netdev@vger•kernel.org, Andrew Lunn <andrew@lunn•ch>
Subject: Re: net: macb: fail when there's no PHY
Date: Fri, 4 Dec 2020 08:47:53 -0800 [thread overview]
Message-ID: <b842bb79-85c8-3da7-ec89-01dbbab447f5@gmail.com> (raw)
In-Reply-To: <rq9nih$egv$1@ciao.gmane.io>
On 12/2/2020 7:54 PM, Grant Edwards wrote:
> On 2020-12-03, Florian Fainelli <f.fainelli@gmail•com> wrote:
>
>> You would have to have a local hack that intercepts the macb_ioctl()
>> and instead of calling phylink_mii_ioctl() it would have to
>> implement a custom ioctl() that does what
>> drivers/net/phy/phy.c::phy_mii_ioctl does except the mdiobus should
>> be pointed to the MACB MDIO bus instance and not be derived from the
>> phy_device instance (because that one points to the fixed PHY).
>
> So I can avoid my local hack to macb_main.c by doing a doing a local
> hack to macb_main.c?
There is value in having the macb driver support the scheme that was
just described which is to support a fixed PHY as far as the MAC link
parameters go, and also support registering the MACB internal MDIO bus
to interface with other devices. People using DSA would typically fall
under that category.
The fact that you need to access the MACB internal MDIO bus to interface
with your PHYs would be a hack that is easier to carry forward, and
maybe more justifiable.
I don't have a dog in the fight, but dealing myself with cute little
hacks in our downstream Linux kernel, the better it fits with useful
functionality to other people, the better.
--
Florian
next prev parent reply other threads:[~2020-12-04 16:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 19:59 net: macb: fail when there's no PHY Grant Edwards
2017-09-21 20:05 ` Florian Fainelli
2017-09-21 20:36 ` Grant Edwards
2017-09-21 21:35 ` Brandon Streiff
2017-09-29 7:05 ` Harini Katakam
[not found] ` <CAK=1mW6Gti0QpUjirB6PfMCiQvnDjkbb56pVKkQmpCSkRU6wtA@mail.gmail.com>
2020-12-02 18:10 ` Florian Fainelli
2020-12-02 18:24 ` Grant Edwards
2020-12-02 18:35 ` Andrew Lunn
2020-12-02 19:16 ` Grant Edwards
2020-12-02 21:11 ` Andrew Lunn
2020-12-02 21:23 ` Grant Edwards
2020-12-03 2:39 ` Andrew Lunn
2020-12-03 3:03 ` Grant Edwards
2020-12-03 3:42 ` Florian Fainelli
2020-12-03 3:54 ` Grant Edwards
2020-12-03 4:07 ` Andrew Lunn
2020-12-03 15:07 ` Grant Edwards
2020-12-03 21:17 ` Andrew Lunn
2020-12-03 21:39 ` Grant Edwards
2020-12-03 21:49 ` Andrew Lunn
2020-12-03 22:20 ` Grant Edwards
2020-12-04 8:28 ` Alexander Dahl
2020-12-04 17:36 ` Andrew Lunn
2020-12-04 16:47 ` Florian Fainelli [this message]
2020-12-05 2:52 ` Grant Edwards
2020-12-05 3:06 ` Florian Fainelli
2020-12-03 4:00 ` Andrew Lunn
2020-12-02 18:10 ` Grant Edwards
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=b842bb79-85c8-3da7-ec89-01dbbab447f5@gmail.com \
--to=f.fainelli@gmail$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=grant.b.edwards@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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