[v3,0/2] Mark Ethernet devices on sa8775p as DMA-coherent

Message

Sagar Cheluvegowda May 8, 2024, 1:30 a.m. UTC

To: Bjorn Andersson <[e-mail]>
To: Konrad Dybcio <[e-mail]>
To: Rob Herring <[e-mail]>
To: Krzysztof Kozlowski <[e-mail]>
To: Conor Dooley <[e-mail]>
To: Bartosz Golaszewski <[e-mail]>
To: Andrew Halaney <[e-mail]>
To: Vinod Koul <[e-mail]>
To: David S. Miller <[e-mail]>
To: Eric Dumazet <[e-mail]>
To: Jakub Kicinski <[e-mail]>
To: Paolo Abeni <[e-mail]>
To: Bhupesh Sharma <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]

Patch 1 :- This patch marks Ethernet devices on Sa8775p as DMA-coherent
as both the devices are cache coherent.

Patch 2 :- Update the schema of qcom,ethqos to allow specifying Ethernet
devices as "dma-coherent".

Changes in v3:
Update the schema to specify Ethernet devices as "dma-coherent".
- Link: https://lore.kernel.org/r/[e-mail]

Changes in v2:
Remove internal change-id from commit message
- Link to v1: https://lore.kernel.org/r/[e-mail]

---
---
Sagar Cheluvegowda (2):
      arm64: dts: qcom: sa8775p: mark ethernet devices as DMA-coherent
      dt-bindings: net: qcom: ethernet: Allow dma-coherent

 Documentation/devicetree/bindings/net/qcom,ethqos.yaml | 2 ++
 arch/arm64/boot/dts/qcom/sa8775p.dtsi                  | 2 ++
 2 files changed, 4 insertions(+)
---
base-commit: a93289b830ce783955b22fbe5d1274a464c05acf
change-id: 20240425-mark_ethernet_devices_dma_coherent-6c6154b84165

Best regards,

Comments

Konrad Dybcio May 8, 2024, 6:45 p.m. UTC | #1

On 5/8/24 03:30, Sagar Cheluvegowda wrote:
> To: Bjorn Andersson <[e-mail]>
> To: Konrad Dybcio <[e-mail]>
> To: Rob Herring <[e-mail]>
> To: Krzysztof Kozlowski <[e-mail]>
> To: Conor Dooley <[e-mail]>
> To: Bartosz Golaszewski <[e-mail]>
> To: Andrew Halaney <[e-mail]>
> To: Vinod Koul <[e-mail]>
> To: David S. Miller <[e-mail]>
> To: Eric Dumazet <[e-mail]>
> To: Jakub Kicinski <[e-mail]>
> To: Paolo Abeni <[e-mail]>
> To: Bhupesh Sharma <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> 
> Patch 1 :- This patch marks Ethernet devices on Sa8775p as DMA-coherent
> as both the devices are cache coherent.
> 
> Patch 2 :- Update the schema of qcom,ethqos to allow specifying Ethernet
> devices as "dma-coherent".
Per-patch descriptions like this are usually redundant, unless you're
reworking something complex and non-obvious. These things above, we
can infer from the commit titles alone.

Generally, when there's not much to say in the cover letter, you can just
give a very brief summary like "This series fixes X on Y".

Not a huge deal though.

Konrad

Andrew Halaney May 14, 2024, 2:21 p.m. UTC | #2

On Tue, May 07, 2024 at 06:30:59PM GMT, Sagar Cheluvegowda wrote:
> To: Bjorn Andersson <[e-mail]>
> To: Konrad Dybcio <[e-mail]>
> To: Rob Herring <[e-mail]>
> To: Krzysztof Kozlowski <[e-mail]>
> To: Conor Dooley <[e-mail]>
> To: Bartosz Golaszewski <[e-mail]>
> To: Andrew Halaney <[e-mail]>
> To: Vinod Koul <[e-mail]>
> To: David S. Miller <[e-mail]>
> To: Eric Dumazet <[e-mail]>
> To: Jakub Kicinski <[e-mail]>
> To: Paolo Abeni <[e-mail]>
> To: Bhupesh Sharma <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> 
> Patch 1 :- This patch marks Ethernet devices on Sa8775p as DMA-coherent
> as both the devices are cache coherent.
> 
> Patch 2 :- Update the schema of qcom,ethqos to allow specifying Ethernet
> devices as "dma-coherent".

I've been keeping my eye on this series, and realized that I should know
better (but don't). How can I tell what tree these should go through?

Just trolling through the list, it seems dt-bindings go through netdev,
whereas dts changes go through the Qualcomm tree.

Is there something in the get_maintainers.pl output that I should be
interpreting differently to understand what patch should target what
maintainer tree?

    halaney@x1gen2nano ~/git/linux-next (git)-[remotes/net/main] % ./scripts/get_maintainer.pl Documentation/devicetree/bindings/net/qcom,ethqos.yaml     :(
    Vinod Koul <[e-mail]> (maintainer:QUALCOMM ETHQOS ETHERNET DRIVER)
    Bjorn Andersson <[e-mail]> (maintainer:ARM/QUALCOMM SUPPORT)
    Konrad Dybcio <[e-mail]> (maintainer:ARM/QUALCOMM SUPPORT)
    "David S. Miller" <[e-mail]> (maintainer:NETWORKING DRIVERS)
    Eric Dumazet <[e-mail]> (maintainer:NETWORKING DRIVERS)
    Jakub Kicinski <[e-mail]> (maintainer:NETWORKING DRIVERS)
    Paolo Abeni <[e-mail]> (maintainer:NETWORKING DRIVERS)
    Rob Herring <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    Krzysztof Kozlowski <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    Conor Dooley <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    Bhupesh Sharma <[e-mail]> (in file)
    [e-mail] (open list:QUALCOMM ETHQOS ETHERNET DRIVER)
    [e-mail] (open list:QUALCOMM ETHQOS ETHERNET DRIVER)
    [e-mail] (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    [e-mail] (open list)

I don't know how to figure out who takes this patch in the end based on
the output above :)

    ahalaney@x1gen2nano ~/git/linux-next (git)-[remotes/net/main] % ./scripts/get_maintainer.pl arch/arm64/boot/dts/qcom/sa8775p.dtsi                 
    Bjorn Andersson <[e-mail]> (maintainer:ARM/QUALCOMM SUPPORT)
    Konrad Dybcio <[e-mail]> (maintainer:ARM/QUALCOMM SUPPORT)
    Rob Herring <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    Krzysztof Kozlowski <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    Conor Dooley <[e-mail]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    [e-mail] (open list:ARM/QUALCOMM SUPPORT)
    [e-mail] (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
    [e-mail] (open list)
    ahalaney@x1gen2nano ~/git/linux-next (git)-[remotes/net/main] %

This one's a little more obviously Qualcomm specific.. but yeah. Sorry
for the obvious question, was talking to Sagar offline and realized I
didn't have a good way to tell him how to figure that out other than dig
through lkml, so just asking directly here!

Thanks,
Andrew

Jakub Kicinski May 14, 2024, 2:41 p.m. UTC | #3

On Tue, 14 May 2024 09:21:08 -0500 Andrew Halaney wrote:
> I don't know how to figure out who takes this patch in the end based on
> the output above :)

bindings/net is usually going via netdev, but my reading of Krzysztof's
comment was that there will be a v4...

Andrew Halaney May 14, 2024, 3:11 p.m. UTC | #4

On Tue, May 14, 2024 at 07:41:42AM GMT, Jakub Kicinski wrote:
> On Tue, 14 May 2024 09:21:08 -0500 Andrew Halaney wrote:
> > I don't know how to figure out who takes this patch in the end based on
> > the output above :)
> 
> bindings/net is usually going via netdev, but my reading of Krzysztof's
> comment was that there will be a v4...
> 

Ahh, I read that differently. I'll ask Sagar to respin with that comment
taken into consideration!

But ignoring that, let me know if there's a good way to know who really
picks things up outside of experience contributing. It's Sagar's first
submission upstream, etc, so I've been fielding some first time
contribution questions and realized I didn't have a good answer to that
other than troll through lkml or the git log and see who picked those up
in the past!

Thanks,
Andrew

Jakub Kicinski May 14, 2024, 4:05 p.m. UTC | #5

On Tue, 14 May 2024 10:11:35 -0500 Andrew Halaney wrote:
> But ignoring that, let me know if there's a good way to know who really
> picks things up outside of experience contributing. It's Sagar's first
> submission upstream, etc, so I've been fielding some first time
> contribution questions and realized I didn't have a good answer to that
> other than troll through lkml or the git log and see who picked those up
> in the past!

I'm not sure how well define it is to be honest. MAINTAINERS is focused
a bit too much on CCing people rather than code flow. Which hurts us in
more than one way. I _think_ the right way to find the responsible tree
is to do an longest prefix match on the path in MAINTAINERS, looking
just at the entries which have a T: attribute. (Q: attribute for that
entry may also be useful.) In practice I myself usually look at:

	git log --format=committer -- $path

where:

[pretty]
	committer = %<(20)%cn %cs  %<(47,trunc)%s