All of lore.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: 33+ 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  8:28                                   ` Alexander Dahl
2020-12-04  8:28                                   ` Alexander Dahl
2020-12-04 13:42                                   ` Grant Edwards
2020-12-04 17:36                                   ` Andrew Lunn
2020-12-04 17:36                                     ` Andrew Lunn
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.com \
    --cc=netdev@vger.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.