All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: andrew@lunn.ch, hkallweit1@gmail.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 4/4] net: ethernet: renesas: rswitch: Add phy_power_{on,off}() calling
Date: Fri, 27 Jan 2023 15:17:32 +0000	[thread overview]
Message-ID: <Y9PrDPPbtIClVtB4@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230127142621.1761278-5-yoshihiro.shimoda.uh@renesas.com>

On Fri, Jan 27, 2023 at 11:26:21PM +0900, Yoshihiro Shimoda wrote:
> Some Ethernet PHYs (like marvell10g) will decide the host interface
> mode by the media-side speed. So, the rswitch driver needs to
> initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports
> after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has
> .init() for initializing all ports and .power_on() for initializing
> each port. So, add phy_power_{on,off} calling for it.

So how does this work?

88x3310 can change it's MAC facing interface according to the speed
negotiated on the media side, or it can use rate adaption mode, but
if it's not a MACSEC device, the MAC must pace its transmission
rate to that of the media side link.

The former requires one to reconfigure the interface mode in
mac_config(), which I don't see happening in this patch set.

The latter requires some kind of configuration in mac_link_up()
which I also don't see happening in this patch set.

So, I doubt this works properly.

Also, I can't see any sign of any working DT configuration for this
switch to even be able to review a use case - all there is in net-next
is the basic description of the rswitch in a .dtsi and no users. It
may be helpful if there was some visibility of its use, and why
phylink is being used in this driver - because right now with phylink's
MAC methods stubbed out in the way they are, and even after this patch
set, I see little point to this driver using phylink.

Moreover, looking at the binding document, you don't even support SFPs
or fixed link, which are really the two reasons to use phylink over
phylib.

Also, phylink only really makes sense if the methods in its _ops
structures actually do something useful, because without that there
can be no dynamic configuration of the system to suit what is
connected.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2023-01-27 15:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 14:26 [PATCH net-next v4 0/4] net: ethernet: renesas: rswitch: Modify initialization for SERDES and PHY Yoshihiro Shimoda
2023-01-27 14:26 ` [PATCH net-next v4 1/4] net: phylink: Set host_interfaces for a non-sfp PHY Yoshihiro Shimoda
2023-01-27 14:26 ` [PATCH net-next v4 2/4] net: ethernet: renesas: rswitch: Simplify struct phy * handling Yoshihiro Shimoda
2023-01-27 14:26 ` [PATCH net-next v4 3/4] net: ethernet: renesas: rswitch: Enable ovr_host_interfaces Yoshihiro Shimoda
2023-01-27 14:26 ` [PATCH net-next v4 4/4] net: ethernet: renesas: rswitch: Add phy_power_{on,off}() calling Yoshihiro Shimoda
2023-01-27 15:17   ` Russell King (Oracle) [this message]
2023-01-30  5:52     ` Yoshihiro Shimoda
2023-01-30 12:15       ` Russell King (Oracle)
2023-01-30 16:30         ` Marek Behún
2023-01-30 16:48           ` Russell King (Oracle)
2023-01-30 16:59             ` Marek Behún
2023-01-31  4:42               ` Yoshihiro Shimoda
2023-01-31  4:42         ` Yoshihiro Shimoda

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=Y9PrDPPbtIClVtB4@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=yoshihiro.shimoda.uh@renesas.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 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.