From: Felix Fietkau <nbd@nbd.name>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
netdev@vger.kernel.org, Krzysztof Kozlowski <krzk+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 05/14] dt-bindings: arm: mediatek: document the pcie mirror node on MT7622
Date: Thu, 7 Apr 2022 19:29:59 +0200 [thread overview]
Message-ID: <f9d76e22-0400-24fa-e4c4-af4b03ed5f8f@nbd.name> (raw)
In-Reply-To: <Yk8chzNBsRZR8e1q@robh.at.kernel.org>
On 07.04.22 19:16, Rob Herring wrote:
> On Wed, Apr 06, 2022 at 01:01:06PM +0200, Felix Fietkau wrote:
>>
>> On 06.04.22 10:20, Krzysztof Kozlowski wrote:
>> > On 05/04/2022 21:57, Felix Fietkau wrote:
>> > > From: Lorenzo Bianconi <lorenzo@kernel.org>
>> > >
>> > > This patch adds the pcie mirror document bindings for MT7622 SoC.
>> > > The feature is used for intercepting PCIe MMIO access for the WED core
>> > > Add related info in mediatek-net bindings.
>> > >
>> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > > Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> > > ---
>> > > .../mediatek/mediatek,mt7622-pcie-mirror.yaml | 42 +++++++++++++++++++
>> >
>> > Eh, I wanted to ask to not put it inside arm/, but judging by your usage
>> > - you did not create drivers for both of these (WED and PCIe mirror).
>> >
>> > You only need them to expose address spaces via syscon.
>> >
>> > This actually looks hacky. Either WED and PCIe mirror are part of
>> > network driver, then add the address spaces via "reg". If they are not,
>> > but instead they are separate blocks, why you don't have drivers for them?
>> The code that uses the WED block is built into the Ethernet driver, but not
>> all SoCs that use this ethernet core have it. Also, there are two WED
>> blocks, and I'm not sure if future SoCs might have a different number of
>> them at some point.
>> The WED code also needs to access registers of the ethernet MAC.
>> One reason for having a separate device is this:
>> As long as WED is not in use, ethernet supports coherent DMA for increased
>> performance. When the first wireless device attaches to WED, IO coherency
>> gets disabled and the ethernet DMA rings are cleaned up and allocated again,
>> this time with the struct device of WED (which doesn't have the dma-coherent
>> property).
>
> I'm pretty sure there are assumptions in the driver core that coherency
> is not changing on the fly. In any case, if it is, using 'dma-coherent'
> is not appropriate. You obviously have another method to determine
> whether you are coherent or not.
It's not really on the fly. Before changing coherency, all DMA memory is
freed, and the subsequent reallocation uses the struct device of the WED
core, which does not have the dma-coherent property.
- Felix
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-07 17:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 19:57 [PATCH v2 00/14] MediaTek SoC flow offload improvements + wireless support Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 01/14] dt-bindings: net: mediatek: add optional properties for the SoC ethernet core Felix Fietkau
2022-04-07 17:20 ` Rob Herring
2022-04-08 9:34 ` Lorenzo Bianconi
2022-04-05 19:57 ` [PATCH v2 02/14] net: ethernet: mtk_eth_soc: add support for coherent DMA Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 03/14] arm64: dts: mediatek: mt7622: " Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 04/14] dt-bindings: arm: mediatek: document WED binding for MT7622 Felix Fietkau
2022-04-06 8:09 ` Krzysztof Kozlowski
2022-04-06 8:18 ` Felix Fietkau
2022-04-06 8:29 ` Arnd Bergmann
2022-04-06 8:32 ` Felix Fietkau
2022-04-06 8:57 ` Krzysztof Kozlowski
2022-04-07 16:59 ` Felix Fietkau
2022-04-07 15:50 ` Andrew Lunn
2022-04-07 16:10 ` Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 05/14] dt-bindings: arm: mediatek: document the pcie mirror node on MT7622 Felix Fietkau
2022-04-06 8:20 ` Krzysztof Kozlowski
2022-04-06 11:01 ` Felix Fietkau
2022-04-07 17:16 ` Rob Herring
2022-04-07 17:29 ` Felix Fietkau [this message]
2022-04-07 17:19 ` Rob Herring
2022-04-08 9:03 ` Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 06/14] net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED) Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 07/14] net: ethernet: mtk_eth_soc: implement flow offloading to WED devices Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 08/14] arm64: dts: mediatek: mt7622: introduce nodes for Wireless Ethernet Dispatch Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 09/14] net: ethernet: mtk_eth_soc: add ipv6 flow offload support Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 10/14] net: ethernet: mtk_eth_soc: support TC_SETUP_BLOCK for PPE offload Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 11/14] net: ethernet: mtk_eth_soc: allocate struct mtk_ppe separately Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 12/14] net: ethernet: mtk_eth_soc: rework hardware flow table management Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 13/14] net: ethernet: mtk_eth_soc: remove bridge flow offload type entry support Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 14/14] net: ethernet: mtk_eth_soc: support creating mac address based offload entries Felix Fietkau
2022-04-07 18:10 ` Andrew Lunn
2022-04-07 18:21 ` Felix Fietkau
2022-04-11 13:00 ` Andrew Lunn
2022-04-12 7:13 ` Felix Fietkau
2022-04-12 13:07 ` Andrew Lunn
2022-04-12 13:49 ` Felix Fietkau
2022-04-12 14:21 ` Andrew Lunn
2022-04-12 15:51 ` Felix Fietkau
2022-04-12 17:37 ` Andrew Lunn
2022-04-12 17:51 ` Felix Fietkau
2022-04-06 13:30 ` [PATCH v2 00/14] MediaTek SoC flow offload improvements + wireless support patchwork-bot+netdevbpf
2022-04-07 15:57 ` Andrew Lunn
2022-04-07 17:00 ` Felix Fietkau
2022-04-07 17:28 ` Andrew Lunn
2022-04-07 17:34 ` Felix Fietkau
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=f9d76e22-0400-24fa-e4c4-af4b03ed5f8f@nbd.name \
--to=nbd@nbd.name \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).