All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Romain Gantois <romain.gantois@bootlin.com>
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Clément Léger" <clement.leger@bootlin.com>,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 2/7] net: phylink: add rxc_always_on flag to phylink_pcs
Date: Wed, 21 Feb 2024 19:07:40 +0000	[thread overview]
Message-ID: <20240221190740.GG722610@kernel.org> (raw)
In-Reply-To: <20240221-rxc_bugfix-v4-2-4883ee1cc7b1@bootlin.com>

On Wed, Feb 21, 2024 at 02:04:19PM +0100, Romain Gantois wrote:
> Some MAC drivers (e.g. stmmac) require a continuous receive clock signal to
> be generated by a PCS that is handled by a standalone PCS driver.
> 
> Such a PCS driver does not have access to a PHY device, thus cannot check
> the PHY_F_RXC_ALWAYS_ON flag. They cannot check max_requires_rxc in the
> phylink config either, since it is a private member. Therefore, a new flag
> is needed to signal to the PCS that it should keep the RX clock signal up
> at all times.
> 
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>

...

> @@ -549,6 +557,34 @@ void pcs_an_restart(struct phylink_pcs *pcs);
>   */
>  void pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
>  		 phy_interface_t interface, int speed, int duplex);
> +
> +/**
> + * pcs_pre_init() - Configure PCS components necessary for MAC initialization
> + * @pcs: a pointer to a &struct phylink_pcs.
> + *
> + * This function can be called by MAC drivers through the
> + * phylink_pcs_pre_init() wrapper, before their hardware is initialized. It
> + * should not be called after the link is brought up, as reconfiguring the PCS
> + * at this point could break the link.
> + *
> + * Some MAC devices require specific hardware initialization to be performed by
> + * their associated PCS device before they can properly initialize their own
> + * hardware. An example of this is the initialization of stmmac controllers,
> + * which requires an active REF_CLK signal to be provided by the PHY/PCS.
> + *
> + * By calling phylink_pcs_pre_init(), MAC drivers can ensure that the PCS is
> + * setup in a way that allows for successful hardware initialization.
> + *
> + * The specific configuration performed by pcs_pre_init() is dependent on the
> + * model of PCS and the requirements of the MAC device attached to it. PCS
> + * driver authors should consider whether their target device is to be used in
> + * conjunction with a MAC device whose driver calls phylink_pcs_pre_init(). MAC
> + * driver authors should document their requirements for the PCS
> + * pre-initialization.
> + *
> + */
> +int pcs_config(struct phylink_pcs *pcs);

Hi Romain,

Should this be pcs_pre_init instead of pcs_config?

> +
>  #endif
>  
>  struct phylink *phylink_create(struct phylink_config *,

...

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Romain Gantois <romain.gantois@bootlin.com>
Cc: "Russell King" <linux@armlinux.org.uk>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Clément Léger" <clement.leger@bootlin.com>,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 2/7] net: phylink: add rxc_always_on flag to phylink_pcs
Date: Wed, 21 Feb 2024 19:07:40 +0000	[thread overview]
Message-ID: <20240221190740.GG722610@kernel.org> (raw)
In-Reply-To: <20240221-rxc_bugfix-v4-2-4883ee1cc7b1@bootlin.com>

On Wed, Feb 21, 2024 at 02:04:19PM +0100, Romain Gantois wrote:
> Some MAC drivers (e.g. stmmac) require a continuous receive clock signal to
> be generated by a PCS that is handled by a standalone PCS driver.
> 
> Such a PCS driver does not have access to a PHY device, thus cannot check
> the PHY_F_RXC_ALWAYS_ON flag. They cannot check max_requires_rxc in the
> phylink config either, since it is a private member. Therefore, a new flag
> is needed to signal to the PCS that it should keep the RX clock signal up
> at all times.
> 
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>

...

> @@ -549,6 +557,34 @@ void pcs_an_restart(struct phylink_pcs *pcs);
>   */
>  void pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
>  		 phy_interface_t interface, int speed, int duplex);
> +
> +/**
> + * pcs_pre_init() - Configure PCS components necessary for MAC initialization
> + * @pcs: a pointer to a &struct phylink_pcs.
> + *
> + * This function can be called by MAC drivers through the
> + * phylink_pcs_pre_init() wrapper, before their hardware is initialized. It
> + * should not be called after the link is brought up, as reconfiguring the PCS
> + * at this point could break the link.
> + *
> + * Some MAC devices require specific hardware initialization to be performed by
> + * their associated PCS device before they can properly initialize their own
> + * hardware. An example of this is the initialization of stmmac controllers,
> + * which requires an active REF_CLK signal to be provided by the PHY/PCS.
> + *
> + * By calling phylink_pcs_pre_init(), MAC drivers can ensure that the PCS is
> + * setup in a way that allows for successful hardware initialization.
> + *
> + * The specific configuration performed by pcs_pre_init() is dependent on the
> + * model of PCS and the requirements of the MAC device attached to it. PCS
> + * driver authors should consider whether their target device is to be used in
> + * conjunction with a MAC device whose driver calls phylink_pcs_pre_init(). MAC
> + * driver authors should document their requirements for the PCS
> + * pre-initialization.
> + *
> + */
> +int pcs_config(struct phylink_pcs *pcs);

Hi Romain,

Should this be pcs_pre_init instead of pcs_config?

> +
>  #endif
>  
>  struct phylink *phylink_create(struct phylink_config *,

...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-21 19:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21 13:04 [PATCH net-next v4 0/7] Fix missing PHY-to-MAC RX clock Romain Gantois
2024-02-21 13:04 ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 1/7] net: phylink: add PHY_F_RXC_ALWAYS_ON to PHY dev flags Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 2/7] net: phylink: add rxc_always_on flag to phylink_pcs Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 19:07   ` Simon Horman [this message]
2024-02-21 19:07     ` Simon Horman
2024-02-22  8:31     ` Romain Gantois
2024-02-22  8:31       ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 3/7] net: stmmac: don't rely on lynx_pcs presence to check for a PHY Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 4/7] net: stmmac: Support a generic PCS field in mac_device_info Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 5/7] net: stmmac: Signal to PHY/PCS drivers to keep RX clock on Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 19:14   ` Jakub Kicinski
2024-02-21 19:14     ` Jakub Kicinski
2024-02-21 13:04 ` [PATCH net-next v4 6/7] net: phy: qcom: at803x: Avoid hibernating if MAC requires RX clock Romain Gantois
2024-02-21 13:04   ` Romain Gantois
2024-02-21 13:04 ` [PATCH net-next v4 7/7] net: pcs: rzn1-miic: Init RX clock early if MAC requires it Romain Gantois
2024-02-21 13:04   ` Romain Gantois

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=20240221190740.GG722610@kernel.org \
    --to=horms@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=clement.leger@bootlin.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=romain.gantois@bootlin.com \
    --cc=thomas.petazzoni@bootlin.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.