All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@corigine.com>
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Wong Vee Khee <veekhee@apple.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>,
	Andrey Konovalov <andrey.konovalov@linaro.org>,
	Revanth Kumar Uppala <ruppala@nvidia.com>,
	Tan Tee Min <tee.min.tan@linux.intel.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Subject: Re: [PATCH 1/1] net: stmmac: add support for platform specific reset
Date: Wed, 22 Mar 2023 17:33:25 +0100	[thread overview]
Message-ID: <ZBst1SzcIS4j+t46@corigine.com> (raw)
In-Reply-To: <20230321190921.3113971-1-shenwei.wang@nxp.com>

On Tue, Mar 21, 2023 at 02:09:20PM -0500, Shenwei Wang wrote:
> This patch adds support for platform-specific reset logic in the
> stmmac driver. Some SoCs require a different reset mechanism than
> the standard dwmac IP reset. To support these platforms, a new function
> pointer 'fix_soc_reset' is added to the plat_stmmacenet_data structure.
> The stmmac_reset macro in hwif.h is modified to call the 'fix_soc_reset'
> function if it exists. This enables the driver to use the platform-specific
> reset logic when necessary.
> 
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/hwif.h | 10 +++++++++-
>  include/linux/stmmac.h                     |  1 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> index 16a7421715cb..e24ce870690e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> @@ -215,7 +215,15 @@ struct stmmac_dma_ops {
>  };
>  
>  #define stmmac_reset(__priv, __args...) \
> -	stmmac_do_callback(__priv, dma, reset, __args)
> +({ \
> +	int __result = -EINVAL; \
> +	if ((__priv) && (__priv)->plat && (__priv)->plat->fix_soc_reset) { \
> +		__result = (__priv)->plat->fix_soc_reset((__priv)->plat, ##__args); \
> +	} else { \
> +		__result = stmmac_do_callback(__priv, dma, reset, __args); \
> +	} \
> +	__result; \
> +})

Hi Shenwei Wang,

I am wondering if any consideration was given to an approach
that has a bit better type safety.

Something like this (*compile tested only!*):

static inline int stmmac_reset(struct stmmac_priv *priv, void __iomem *ioaddr)
{
       struct plat_stmmacenet_data *plat = priv ? priv->plat : NULL;

       if (plat && plat->fix_soc_reset)
	       return plat->fix_soc_reset(plat, ioaddr);

       return stmmac_do_callback(priv, dma, reset, ioaddr);
}

In which case the first parameter of the fix_soc_reset field
of struct plat_stmmacenet_data can become struct plat_stmmacenet_data *.

diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 9044477fad61..b26ade7e4be8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -223,6 +223,8 @@ struct plat_stmmacenet_data {
 	struct stmmac_rxq_cfg rx_queues_cfg[MTL_MAX_RX_QUEUES];
 	struct stmmac_txq_cfg tx_queues_cfg[MTL_MAX_TX_QUEUES];
 	void (*fix_mac_speed)(void *priv, unsigned int speed);
+	int (*fix_soc_reset)(struct plat_stmmacenet_data *,
+			     void __iomem *ioaddr);
 	int (*serdes_powerup)(struct net_device *ndev, void *priv);
 	void (*serdes_powerdown)(struct net_device *ndev, void *priv);
 	void (*speed_mode_2500)(struct net_device *ndev, void *priv);

I do see that the approach you have is
in keeping with the existing structure of stmmac_do_callback().
But I guess my question there is: why is that model used?
And could there be a plan to move away from that model?

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <simon.horman@corigine.com>
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Wong Vee Khee <veekhee@apple.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com>,
	Andrey Konovalov <andrey.konovalov@linaro.org>,
	Revanth Kumar Uppala <ruppala@nvidia.com>,
	Tan Tee Min <tee.min.tan@linux.intel.com>,
	netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Subject: Re: [PATCH 1/1] net: stmmac: add support for platform specific reset
Date: Wed, 22 Mar 2023 17:33:25 +0100	[thread overview]
Message-ID: <ZBst1SzcIS4j+t46@corigine.com> (raw)
In-Reply-To: <20230321190921.3113971-1-shenwei.wang@nxp.com>

On Tue, Mar 21, 2023 at 02:09:20PM -0500, Shenwei Wang wrote:
> This patch adds support for platform-specific reset logic in the
> stmmac driver. Some SoCs require a different reset mechanism than
> the standard dwmac IP reset. To support these platforms, a new function
> pointer 'fix_soc_reset' is added to the plat_stmmacenet_data structure.
> The stmmac_reset macro in hwif.h is modified to call the 'fix_soc_reset'
> function if it exists. This enables the driver to use the platform-specific
> reset logic when necessary.
> 
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/hwif.h | 10 +++++++++-
>  include/linux/stmmac.h                     |  1 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> index 16a7421715cb..e24ce870690e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> @@ -215,7 +215,15 @@ struct stmmac_dma_ops {
>  };
>  
>  #define stmmac_reset(__priv, __args...) \
> -	stmmac_do_callback(__priv, dma, reset, __args)
> +({ \
> +	int __result = -EINVAL; \
> +	if ((__priv) && (__priv)->plat && (__priv)->plat->fix_soc_reset) { \
> +		__result = (__priv)->plat->fix_soc_reset((__priv)->plat, ##__args); \
> +	} else { \
> +		__result = stmmac_do_callback(__priv, dma, reset, __args); \
> +	} \
> +	__result; \
> +})

Hi Shenwei Wang,

I am wondering if any consideration was given to an approach
that has a bit better type safety.

Something like this (*compile tested only!*):

static inline int stmmac_reset(struct stmmac_priv *priv, void __iomem *ioaddr)
{
       struct plat_stmmacenet_data *plat = priv ? priv->plat : NULL;

       if (plat && plat->fix_soc_reset)
	       return plat->fix_soc_reset(plat, ioaddr);

       return stmmac_do_callback(priv, dma, reset, ioaddr);
}

In which case the first parameter of the fix_soc_reset field
of struct plat_stmmacenet_data can become struct plat_stmmacenet_data *.

diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 9044477fad61..b26ade7e4be8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -223,6 +223,8 @@ struct plat_stmmacenet_data {
 	struct stmmac_rxq_cfg rx_queues_cfg[MTL_MAX_RX_QUEUES];
 	struct stmmac_txq_cfg tx_queues_cfg[MTL_MAX_TX_QUEUES];
 	void (*fix_mac_speed)(void *priv, unsigned int speed);
+	int (*fix_soc_reset)(struct plat_stmmacenet_data *,
+			     void __iomem *ioaddr);
 	int (*serdes_powerup)(struct net_device *ndev, void *priv);
 	void (*serdes_powerdown)(struct net_device *ndev, void *priv);
 	void (*speed_mode_2500)(struct net_device *ndev, void *priv);

I do see that the approach you have is
in keeping with the existing structure of stmmac_do_callback().
But I guess my question there is: why is that model used?
And could there be a plan to move away from that model?

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

  parent reply	other threads:[~2023-03-22 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 19:09 [PATCH 1/1] net: stmmac: add support for platform specific reset Shenwei Wang
2023-03-21 19:09 ` Shenwei Wang
2023-03-21 19:09 ` [PATCH 2/2] net: stmmac: dwmac-imx: use platform specific reset for imx93 SoCs Shenwei Wang
2023-03-21 19:09   ` Shenwei Wang
2023-03-22 16:33 ` Simon Horman [this message]
2023-03-22 16:33   ` [PATCH 1/1] net: stmmac: add support for platform specific reset Simon Horman
2023-03-22 21:56   ` [EXT] " Shenwei Wang
2023-03-22 21:56     ` Shenwei Wang
2023-03-30 14:55 ` Shenwei Wang
2023-03-30 14:55   ` Shenwei Wang
2023-03-30 16:37   ` Jakub Kicinski
2023-03-30 16:37     ` 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=ZBst1SzcIS4j+t46@corigine.com \
    --to=simon.horman@corigine.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrey.konovalov@linaro.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=joabreu@synopsys.com \
    --cc=jonathanh@nvidia.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mohammad.athari.ismail@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peppe.cavallaro@st.com \
    --cc=ruppala@nvidia.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=shenwei.wang@nxp.com \
    --cc=tee.min.tan@linux.intel.com \
    --cc=veekhee@apple.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.