All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Sergej Bauer <sbauer@blackbox.su>, Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Bryan Whitehead <bryan.whitehead@microchip.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Rob Herring <robh@kernel.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] add virtual PHY for PHY-less devices
Date: Thu, 17 Sep 2020 18:31:28 -0700	[thread overview]
Message-ID: <9ad8b493-f6ba-a249-9654-da2a8c0c2c73@gmail.com> (raw)
In-Reply-To: <1680322.qRJ2Tc3Qy1@metabook>

(please do not top-post)

On 9/17/2020 5:17 PM, Sergej Bauer wrote:
> Hi Andrew
> 
>    To tell the truth, I thought that fixed_phy is only for devices with a Device
> Trees and I never met DTS on x86 machines...

fixed_phy existed long before Device Tree was popular and you can 
register a fixed PHY device from within your Ethernet MAC driver, see 
drivers/net/dsa/dsa_loop.c for an example.

> 
> So it looks like there realy no any significant advantage _except_ of
> ability to use ethtool and ioctl to set speed and rx-all/fcs flags without
> removing module. That was most wanted request from HW designers as they are
> wanted to change registers of virtual PHY on-the-fly with ethtool either custom
> tool (using SIOCSMIIREG ioctl) for controling PHY registers.

NETIF_F_RXALL and NETIF_F_RXFCS are feature flags that are applicable to 
the Ethernet MAC, so I am not really sure where the virtual PHY, or the 
fixed PHY plays a role in those?

The key thing with the fixed PHY is that it is an emulation device, 
therefore from the Ethernet MAC perspective you can tell 
(phy_is_pseudo_fixed_link) whether this is a real PHY device on a MDIO 
bus or the emulated fixed PHY but there is really no need for you to 
make that difference.

> 
> p.s. And that's my bad, the original driver was developed year ago (for
> linux-5.2.15),
> but I had no time before this moment.
> 
> 
> p.p.s. sorry for long time to answer but it's far behind the midnight in my
> region.
> 

-- 
Florian

  reply	other threads:[~2020-09-18  1:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 21:40 [PATCH] add virtual PHY for PHY-less devices Sergej Bauer
2020-09-17 22:15 ` Andrew Lunn
2020-09-18  0:17   ` Sergej Bauer
2020-09-18  1:31     ` Florian Fainelli [this message]
2020-09-17 22:16 ` Florian Fainelli
2020-09-18  0:58   ` Sergej Bauer

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=9ad8b493-f6ba-a249-9654-da2a8c0c2c73@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bryan.whitehead@microchip.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sbauer@blackbox.su \
    /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.