public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail•com>
To: netdev@vger•kernel.org
Subject: Re: net: macb: fail when there's no PHY
Date: Thu, 3 Dec 2020 15:07:58 -0000 (UTC)	[thread overview]
Message-ID: <rqav0e$4m3$1@ciao.gmane.io> (raw)
In-Reply-To: 20201203040758.GC2333853@lunn.ch

On 2020-12-03, Andrew Lunn <andrew@lunn•ch> wrote:
>> So I can avoid my local hack to macb_main.c by doing a doing a local
>> hack to macb_main.c?
>
> User space drivers were never supported in any meaningful way. The
> IOCTL call is basically there for mii-tool, and nothing much more.

I probably wouldn't call a single ioctl() to check the link status a
user-space-driver, but I guess that's what it is. If it's good enough
for the mii-tool, it's good enough for me.

> The way to avoid your local hack is to move your drivers into the
> kernel, along side all the other drivers for devices on MDIO busses.

I don't think I can justify the additional effort to devlope and
maintain a custom kern-space driver. We've already got a custom macb
driver, and writing a spearate driver in order to remove a handful of
lines from the macb driver just isn't worth it.

What has confused me all along was Florian Fainelli's post:

>> [I modified the macb driver to support fixed PHY plus mdio access]
>
> That should be unnecessary see below.
>
>> Was there some other way I should have done this with a 5.4 kernel
>> that I was unable to discover?
>
> You should be able to continue having the macb MDIO bus controller
> be registered with no PHY/MDIO devices represented in Device Tree
> such that user-space can continue to use it for ioctl() *and* you
> can point the macb node to a fixed PHY for the purpose of having
> fixed link parameters.

But to do that, I have to modify the macb driver to support a fixed
PHY plus mdio access. What would be the advantage of that modification
over the modification I've already made and tested?

Alternatively, I could write a seperate kernel driver that would "own"
the macb's mdio bus and provide some something equivalent to the
existing SIOC[SG]MIIREG ioctl() calls to access the devices on that
mdio bus.

Thanks for clearing this up for me.

BTW Andrew, we're still shipping plenty of product that running
eCos. :)

--
Grant


  reply	other threads:[~2020-12-03 15:08 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 [this message]
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
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='rqav0e$4m3$1@ciao.gmane.io' \
    --to=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