From: Simon Horman <simon.horman@corigine•com>
To: Andrew Halaney <ahalaney@redhat•com>
Cc: linux-kernel@vger•kernel.org, agross@kernel•org,
andersson@kernel•org, konrad.dybcio@linaro•org,
davem@davemloft•net, edumazet@google•com, kuba@kernel•org,
pabeni@redhat•com, robh+dt@kernel•org,
krzysztof.kozlowski+dt@linaro•org, vkoul@kernel•org,
bhupesh.sharma@linaro•org, wens@csie•org,
jernej.skrabec@gmail•com, samuel@sholland•org,
mturquette@baylibre•com, peppe.cavallaro@st•com,
alexandre.torgue@foss•st.com, joabreu@synopsys•com,
mcoquelin.stm32@gmail•com, richardcochran@gmail•com,
linux@armlinux•org.uk, veekhee@apple•com,
tee.min.tan@linux•intel.com, mohammad.athari.ismail@intel•com,
jonathanh@nvidia•com, ruppala@nvidia•com, bmasney@redhat•com,
andrey.konovalov@linaro•org, linux-arm-msm@vger•kernel.org,
netdev@vger•kernel.org, devicetree@vger•kernel.org,
linux-stm32@st-md-mailman•stormreply.com,
linux-arm-kernel@lists•infradead.org, ncai@quicinc•com,
jsuraj@qti•qualcomm.com, hisunil@quicinc•com,
echanude@redhat•com
Subject: Re: [PATCH net-next v3 09/12] net: stmmac: dwmac4: Allow platforms to specify some DMA/MTL offsets
Date: Sat, 1 Apr 2023 16:58:59 +0200 [thread overview]
Message-ID: <ZChGswjgAOkT0jvY@corigine.com> (raw)
In-Reply-To: <20230331214549.756660-10-ahalaney@redhat.com>
On Fri, Mar 31, 2023 at 04:45:46PM -0500, Andrew Halaney wrote:
> Some platforms have dwmac4 implementations that have a different
> address space layout than the default, resulting in the need to define
> their own DMA/MTL offsets.
>
> Extend the functions to allow a platform driver to indicate what its
> addresses are, overriding the defaults.
>
> Signed-off-by: Andrew Halaney <ahalaney@redhat•com>
> ---
>
> This patch (and the prior patch) are replacements for
> https://lore.kernel.org/netdev/20230320204153.21736840@kernel.org/
> as was requested. Hopefully I was understanding the intent correctly :)
>
> I'm pretty sure further refinement will be requested for this one, but
> it is the best I could come up with myself! Specifically some of the
> naming, dealing with spacing in some older spots of dwmac4,
> where the addresses should live in the structure hierarchy, etc are
> things I would not be surprised to have to rework if this is still
> preferred over the wrapper approach.
>
> Changes since v2:
> * New, replacing old wrapper approach
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 91 ++++++++--
> .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 36 ++--
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 157 ++++++++++--------
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 51 +++---
> .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 67 +++++---
> include/linux/stmmac.h | 19 +++
> 6 files changed, 279 insertions(+), 142 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index ccd49346d3b3..a0c0ee1dc13f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -336,14 +336,23 @@ enum power_event {
>
> #define MTL_CHAN_BASE_ADDR 0x00000d00
> #define MTL_CHAN_BASE_OFFSET 0x40
> -#define MTL_CHANX_BASE_ADDR(x) (MTL_CHAN_BASE_ADDR + \
> - (x * MTL_CHAN_BASE_OFFSET))
> -
> -#define MTL_CHAN_TX_OP_MODE(x) MTL_CHANX_BASE_ADDR(x)
> -#define MTL_CHAN_TX_DEBUG(x) (MTL_CHANX_BASE_ADDR(x) + 0x8)
> -#define MTL_CHAN_INT_CTRL(x) (MTL_CHANX_BASE_ADDR(x) + 0x2c)
> -#define MTL_CHAN_RX_OP_MODE(x) (MTL_CHANX_BASE_ADDR(x) + 0x30)
> -#define MTL_CHAN_RX_DEBUG(x) (MTL_CHANX_BASE_ADDR(x) + 0x38)
> +#define MTL_CHANX_BASE_ADDR(addrs, x) \
> +({ \
> + const struct dwmac4_addrs *__addrs = addrs; \
> + const u32 __x = x; \
> + u32 __addr; \
> + if (__addrs) \
> + __addr = __addrs->mtl_chan + (__x * __addrs->mtl_chan_offset); \
> + else \
> + __addr = MTL_CHAN_BASE_ADDR + (__x * MTL_CHAN_BASE_OFFSET); \
> + __addr; \
> +})
Could this and similar macros added by this patch be functions?
From my pov a benefit would be slightly more type safety.
And as a bonus there wouldn't be any need to handle aliasing of input.
next prev parent reply other threads:[~2023-04-01 14:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 21:45 [PATCH net-next v3 00/12] Add EMAC3 support for sa8540p-ride Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 01/12] dt-bindings: net: snps,dwmac: Update interrupt-names Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 02/12] dt-bindings: net: snps,dwmac: Add Qualcomm Ethernet ETHQOS compatibles Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 03/12] dt-bindings: net: qcom,ethqos: Convert bindings to yaml Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 04/12] dt-bindings: net: qcom,ethqos: Add Qualcomm sc8280xp compatibles Andrew Halaney
2023-04-02 10:49 ` Krzysztof Kozlowski
2023-03-31 21:45 ` [PATCH net-next v3 05/12] net: stmmac: Remove unnecessary if statement brackets Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 06/12] net: stmmac: Fix DMA typo Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 07/12] net: stmmac: Remove some unnecessary void pointers Andrew Halaney
2023-04-01 14:49 ` Simon Horman
2023-03-31 21:45 ` [PATCH net-next v3 08/12] net: stmmac: Pass stmmac_priv in some callbacks Andrew Halaney
2023-04-01 15:06 ` Simon Horman
2023-04-07 17:34 ` Andrew Halaney
2023-04-10 21:24 ` Andrew Halaney
2023-04-11 17:43 ` Simon Horman
2023-03-31 21:45 ` [PATCH net-next v3 09/12] net: stmmac: dwmac4: Allow platforms to specify some DMA/MTL offsets Andrew Halaney
2023-04-01 14:58 ` Simon Horman [this message]
2023-04-07 17:36 ` Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 10/12] net: stmmac: dwmac-qcom-ethqos: Respect phy-mode and TX delay Andrew Halaney
2023-03-31 21:45 ` [PATCH net-next v3 11/12] net: stmmac: dwmac-qcom-ethqos: Use loopback_en for all speeds Andrew Halaney
2023-03-31 22:06 ` [PATCH net-next v3 00/12] Add EMAC3 support for sa8540p-ride Andrew Halaney
2023-04-01 4:55 ` Jakub Kicinski
2023-04-03 13:01 ` Andrew Halaney
2023-04-03 16:52 ` [PATCH net-next v3 12/12] net: stmmac: dwmac-qcom-ethqos: Add EMAC3 support Andrew Halaney
2023-04-06 8:57 ` Paolo Abeni
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=ZChGswjgAOkT0jvY@corigine.com \
--to=simon.horman@corigine$(echo .)com \
--cc=agross@kernel$(echo .)org \
--cc=ahalaney@redhat$(echo .)com \
--cc=alexandre.torgue@foss$(echo .)st.com \
--cc=andersson@kernel$(echo .)org \
--cc=andrey.konovalov@linaro$(echo .)org \
--cc=bhupesh.sharma@linaro$(echo .)org \
--cc=bmasney@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=echanude@redhat$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=hisunil@quicinc$(echo .)com \
--cc=jernej.skrabec@gmail$(echo .)com \
--cc=joabreu@synopsys$(echo .)com \
--cc=jonathanh@nvidia$(echo .)com \
--cc=jsuraj@qti$(echo .)qualcomm.com \
--cc=konrad.dybcio@linaro$(echo .)org \
--cc=krzysztof.kozlowski+dt@linaro$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-arm-msm@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-stm32@st-md-mailman$(echo .)stormreply.com \
--cc=linux@armlinux$(echo .)org.uk \
--cc=mcoquelin.stm32@gmail$(echo .)com \
--cc=mohammad.athari.ismail@intel$(echo .)com \
--cc=mturquette@baylibre$(echo .)com \
--cc=ncai@quicinc$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=peppe.cavallaro@st$(echo .)com \
--cc=richardcochran@gmail$(echo .)com \
--cc=robh+dt@kernel$(echo .)org \
--cc=ruppala@nvidia$(echo .)com \
--cc=samuel@sholland$(echo .)org \
--cc=tee.min.tan@linux$(echo .)intel.com \
--cc=veekhee@apple$(echo .)com \
--cc=vkoul@kernel$(echo .)org \
--cc=wens@csie$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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