From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Karumanchi, Vineeth" <vineeth@amd.com>
Cc: vineeth.karumanchi@amd.com, nicolas.ferre@microchip.com,
claudiu.beznea@tuxon.dev, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
andrew@lunn.ch, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
git@amd.com
Subject: Re: [RFC PATCH net-next 4/5] net: macb: Configure High Speed Mac for given speed.
Date: Thu, 10 Oct 2024 15:17:29 +0100 [thread overview]
Message-ID: <Zwfh-ZJB4BtnJY28@shell.armlinux.org.uk> (raw)
In-Reply-To: <6fc42ade-66cf-4462-914c-3dd5589c9a9f@amd.com>
On Thu, Oct 10, 2024 at 07:39:16PM +0530, Karumanchi, Vineeth wrote:
> Hi Russel,
>
> On 10/9/2024 2:49 PM, Russell King (Oracle) wrote:
> > It also looks like you're messing with MAC registers in the PCS code,
> > setting the MAC speed there. Are the PCS and MAC so integrated together
> > that abstracting the PCS into its own separate code block leads to
> > problems?
>
> Agreed, Since our current hardware configuration lacks AN and PHY, I've
> relocated the ENABLE_HS_MAC configuration into PCS to
> allow speed changes using ethtool. When more hardware with a PHY that
> supports AN becomes available,
> the phylink will invoke macb_mac_config() with the communicated speed
> (phylinkstate->speed).
Where are you getting that idea from, because that has not been true for
a good number of years - and it's been stated in the phylink
documentation for a very long time.
I've killed all the code references to ->speed in all mac_config()
implementations, and I've even gone to the extent of now ensuring that
all mac_config() methods will _always_ be called with state->speed
set to SPEED_UNKNOWN, so no one can make any useful determinations
from that.
If people continue to insist on using this, then I'll have no option
but to make a disruptive API change, making mac_config() take an
explicit set of arguments for the items that it should have access
to.
> Currently, for fixed-link, will keep the earlier implementation.
I want phylink users to be correct and easy to understand - because
I maintain phylink, and that means I need to understand the code
that makes use of its facilities. So, want to see phylink methods
implemented properly. If they aren't going to be implemented
properly, then I will ask that the driver ceases to use phylink
quite simply because it makes _my_ maintenance more difficult
when drivers don't implement phylink methods correctly.
The choice is: implement phylink methods properly or don't use
phylink.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-10-10 14:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 5:39 [RFC PATCH net-next 0/5] net: macb: Add versal2 10GBE device support Vineeth Karumanchi
2024-10-09 5:39 ` [RFC PATCH net-next 1/5] dt-bindings: net: macb: Add support for versal2 10gbe device Vineeth Karumanchi
2024-10-09 6:43 ` Krzysztof Kozlowski
2024-10-09 5:39 ` [RFC PATCH net-next 2/5] net: macb: Add versal2 10GBE device support Vineeth Karumanchi
2024-10-09 5:39 ` [RFC PATCH net-next 3/5] net: macb: Update USX_CONTROL reg's bitfields and constants Vineeth Karumanchi
2024-10-09 9:04 ` Russell King (Oracle)
2024-10-09 5:39 ` [RFC PATCH net-next 4/5] net: macb: Configure High Speed Mac for given speed Vineeth Karumanchi
2024-10-09 6:36 ` Maxime Chevallier
2024-10-10 13:53 ` Karumanchi, Vineeth
2024-10-09 9:19 ` Russell King (Oracle)
2024-10-10 14:09 ` Karumanchi, Vineeth
2024-10-10 14:17 ` Russell King (Oracle) [this message]
2024-10-09 5:39 ` [RFC PATCH net-next 5/5] net: macb: Get speed and link status runtime Vineeth Karumanchi
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=Zwfh-ZJB4BtnJY28@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=git@amd.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=vineeth.karumanchi@amd.com \
--cc=vineeth@amd.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.