mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Vladimir Oltean <olteanv@gmail.com>,
	Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,  Eric Dumazet <edumazet@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	Arun Ramadoss <arun.ramadoss@microchip.com>,
	kernel@pengutronix.de,  linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org,  UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net-next v1 3/3] net: dsa: microchip: lan937x: disable VPHY output
Date: Fri, 28 Jun 2024 10:45:24 +0200	[thread overview]
Message-ID: <d9bdcc0cd504df1ddc19012f9d23a90d0a76b294.camel@pengutronix.de> (raw)
In-Reply-To: <20240627223818.655p2c34dp6ynxnq@skbuf>

Am Freitag, dem 28.06.2024 um 01:38 +0300 schrieb Vladimir Oltean:
> On Thu, Jun 27, 2024 at 02:39:11PM +0200, Oleksij Rempel wrote:
> > The VPHY is a compatibility functionality to be able to attach network
> > drivers without fixed-link support to the switch, which generally
> > should not be needed with linux network drivers.
> 
> Sorry, I don't have much to base my judgement upon. I did search for the
> "VPHY" string and found it to be accessed in the dev_ops->r_phy() and
> dev_ops->w_phy() implementations, suggesting that it is more than just
> that? These methods are used for accessing the registers of the embedded
> PHYs for user ports. I don't see what is the connection with RGMII on
> the CPU port.

There is a bit of a mixup with the names here. The VPHY (as in virtual
PHY) is a emulated PHY register space accessible via MDIO to allow
operating systems that don't support the concept of direct MAC to MAC
connections to work with the switch. However, it is buggy and the
emulated auto-negotiation does the wrong thing for RGMII interfaces. As
this part isn't needed for Linux we disable it with this patch, or to
be precise the VPHY itself isn't disabled, but rather the result of the
VPHY state machine isn't allowed to override explicit link
configurations in other registers anymore.

The VPHY used by the driver to access the registers of real PHYs is
described in the datasheet like this:

"Direct access to the PHY registers via SPI requires a reduced SPI_CLK
frequency. This is due to the latency incurred from clock crossings
from the internal bus and into the PHY. To avoid a degradation of
SPI_CLK, an indirect mechanism has been added to the VPHY for accessing
the PHY registers via Indirect Address Register, Indirect Data
Register, and Indirect Control Register."

This mechanism is located in the VPHY register range, but otherwise has
nothing to do with the VPHY state machine and is also not affected by
this patch.

Regards,
Lucas

  parent reply	other threads:[~2024-06-28  8:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 12:39 [PATCH net-next v1 1/1] net: dsa: microchip: add regmap_range for KSZ9563 chip Oleksij Rempel
2024-06-27 12:39 ` [PATCH net-next v1 1/3] net: dsa: microchip: lan9372: add 100BaseTX PHY support Oleksij Rempel
2024-06-28  2:31   ` Arun.Ramadoss
2024-06-27 12:39 ` [PATCH net-next v1 2/3] net: dsa: microchip: lan937x: force RGMII interface into PHY mode Oleksij Rempel
2024-06-27 15:15   ` Andrew Lunn
2024-06-27 22:25   ` Vladimir Oltean
2024-06-28  7:10     ` Oleksij Rempel
2024-06-28 14:02       ` Andrew Lunn
2024-06-27 12:39 ` [PATCH net-next v1 3/3] net: dsa: microchip: lan937x: disable VPHY output Oleksij Rempel
2024-06-27 22:38   ` Vladimir Oltean
2024-06-28  5:27     ` Oleksij Rempel
2024-06-28  8:45     ` Lucas Stach [this message]
2024-06-27 12:43 ` [PATCH net-next v1 1/1] net: dsa: microchip: add regmap_range for KSZ9563 chip Oleksij Rempel
2024-06-27 22:00   ` Jakub Kicinski

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=d9bdcc0cd504df1ddc19012f9d23a90d0a76b294.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=arun.ramadoss@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=woojung.huh@microchip.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®