mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Karumanchi, Vineeth" <vineeth@amd.com>
To: sean.anderson@linux.dev, vineeth.karumanchi@amd.com,
	netdev@vger.kernel.org, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, linux@armlinux.org.uk
Cc: upstream@airoha.com, horms@kernel.org, hkallweit1@gmail.com,
	kory.maincent@bootlin.com, linux-kernel@vger.kernel.org,
	ansuelsmth@gmail.com, claudiu.beznea@microchip.com,
	nicolas.ferre@microchip.com
Subject: Re: [net-next PATCH v4 09/11] net: macb: Move most of mac_config to mac_prepare
Date: Thu, 15 May 2025 11:44:16 +0530	[thread overview]
Message-ID: <bdc5c3d3-a57e-4f80-92bb-3448e80a288f@amd.com> (raw)
In-Reply-To: <e545e5c2-daeb-4cd1-b9f8-e5d28e6250c8@linux.dev>

Hi Sean,

On 5/13/2025 9:19 PM, Sean Anderson wrote:
> On 5/13/25 11:29, Karumanchi, Vineeth wrote:
>> Hi Sean,

<..>

>>> +    spin_lock_irqsave(&bp->lock, flags);
>>> +    old = new = gem_readl(bp, NCFGR);
>>> +    new |= GEM_BIT(SGMIIEN);
>>
>> This bit represents the AN feature, can we make it conditional to facilitate IP's with AN disabled.
> 
> To clarify, this bit enables SGMII timings for AN (as opposed to
> 1000Base-X). If you don't have AN enabled at 1G, then this bit affects
> nothing.
> 
> 1000Base-X is not currently supported by the built-in PCS. Therefore,
> this bit should be set unconditionally at 1G speeds. This patch aims to
> avoid functional changes so I have not made it conditional. Making this
> bit conditional would be appropriate for a patch adding support for
> 1000Base-X using the internal PCS.
> 

Yes, agreed.

>>> +    if (old != new) {
>>> +        changed = true;
>>> +        gem_writel(bp, NCFGR, new);
>>> +    }
>>
>> <..>
>>
>>>      static void macb_usx_pcs_get_state(struct phylink_pcs *pcs,
>>> @@ -589,45 +661,60 @@ static int macb_usx_pcs_config(struct phylink_pcs *pcs,
>>>                       bool permit_pause_to_mac)
>>>    {
>>>        struct macb *bp = container_of(pcs, struct macb, phylink_usx_pcs);
>>> +    unsigned long flags;
>>> +    bool changed;
>>> +    u16 old, new;
>>>    -    gem_writel(bp, USX_CONTROL, gem_readl(bp, USX_CONTROL) |
>>> -           GEM_BIT(SIGNAL_OK));
>>> +    spin_lock_irqsave(&bp->lock, flags);
>>> +    if (macb_pcs_config_an(bp, neg_mode, interface, advertising))
>>> +        changed = true;
>>>    -    return 0;
>>> -}
>>> +    old = new = gem_readl(bp, USX_CONTROL);
>>> +    new |= GEM_BIT(SIGNAL_OK);
>>> +    if (old != new) {
>>> +        changed = true;
>>> +        gem_writel(bp, USX_CONTROL, new);
>>> +    }
>>>    -static void macb_pcs_get_state(struct phylink_pcs *pcs, unsigned int neg_mode,
>>> -                   struct phylink_link_state *state)
>>> -{
>>> -    state->link = 0;
>>> -}
>>> +    old = new = gem_readl(bp, USX_CONTROL);
>>> +    new = GEM_BFINS(SERDES_RATE, MACB_SERDES_RATE_10G, new);
>>> +    new = GEM_BFINS(USX_CTRL_SPEED, HS_SPEED_10000M, new);
>>> +    new &= ~(GEM_BIT(TX_SCR_BYPASS) | GEM_BIT(RX_SCR_BYPASS));
>>> +    new |= GEM_BIT(TX_EN);
>>> +    if (old != new) {
>>> +        changed = true;
>>> +        gem_writel(bp, USX_CONTROL, new);
>>> +    }
>>
>> The above speed/rate configuration was moved from macb_usx_pcs_link_up() where speed is an argument, which can be leveraged to configure multiple speeds.
>>
>> Can we achieve configuring for multiple speeds from macb_usx_pcs_config() in fixed-link and phy-mode ?
> 
> Form what I can tell, the USX PCS is only used for 10G interfaces. If
> you want to add support for using it at other link speeds, then yes some
> of these register writes should be moved to link_up. For the moment it
> doesn't matter where they happen.
> 
> --Sean

Ok, in the latest cadence IP, all speed configurations are mapped to USX 
registers for both internal PCS's (1000Base-X & 10GBase-R).

-- 
🙏 vineeth


  reply	other threads:[~2025-05-15  6:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12 16:10 [net-next PATCH v4 00/11] Add PCS core support Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 01/11] dt-bindings: net: Add Xilinx PCS Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 02/11] net: phylink: Support setting PCS link change callbacks Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 03/11] net: pcs: Add subsystem Sean Anderson
2025-05-14 16:22   ` Lei Wei
2025-05-19 17:43     ` Sean Anderson
2025-05-21 12:50       ` Lei Wei
2025-05-22 15:14         ` Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 04/11] net: dsa: ocelot: suppress PHY device scanning on the internal MDIO bus Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 05/11] net: pcs: lynx: Convert to an MDIO driver Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 06/11] net: phy: Export some functions Sean Anderson
2025-05-15  2:57   ` Jakub Kicinski
2025-05-15  5:38     ` Heiner Kallweit
2025-05-19 18:17       ` Sean Anderson
2025-05-15  8:12     ` Russell King (Oracle)
2025-05-15  8:39       ` Christian Marangi (Ansuel)
2025-05-19 18:14       ` Sean Anderson
2025-05-19 15:29     ` Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 07/11] net: pcs: Add Xilinx PCS driver Sean Anderson
2025-05-14 16:18   ` Lei Wei
2025-05-19 15:31     ` Sean Anderson
2025-05-12 16:10 ` [net-next PATCH v4 08/11] net: axienet: Convert to use PCS subsystem Sean Anderson
2025-05-12 16:14 ` [net-next PATCH v4 09/11] net: macb: Move most of mac_config to mac_prepare Sean Anderson
2025-05-12 16:14   ` [net-next PATCH v4 10/11] net: macb: Support external PCSs Sean Anderson
2025-05-12 16:14   ` [net-next PATCH v4 11/11] of: property: Add device link support for PCS Sean Anderson
2025-05-13 15:29   ` [net-next PATCH v4 09/11] net: macb: Move most of mac_config to mac_prepare Karumanchi, Vineeth
2025-05-13 15:49     ` Sean Anderson
2025-05-15  6:14       ` Karumanchi, Vineeth [this message]
2025-05-13 16:40     ` Sean Anderson
2025-05-15  6:20       ` Karumanchi, Vineeth
2025-05-12 17:11 ` [net-next PATCH v4 00/11] Add PCS core support Daniel Golle
2025-05-12 17:15   ` Sean Anderson

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=bdc5c3d3-a57e-4f80-92bb-3448e80a288f@amd.com \
    --to=vineeth@amd.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=claudiu.beznea@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=pabeni@redhat.com \
    --cc=sean.anderson@linux.dev \
    --cc=upstream@airoha.com \
    --cc=vineeth.karumanchi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome