mbox series

[v3,0/6] Enable IPQ5018 PCI support

Message ID DS7PR19MB8883BC190797BECAA78EC50F9DCB2@DS7PR19MB8883.namprd19.prod.outlook.com
Headers show
Series Enable IPQ5018 PCI support | expand

Message

George Moussalem March 5, 2025, 1:41 p.m. UTC
From: Sricharan Ramabadhran <quic_srichara@quicinc.com>

This patch series adds the relevant phy and controller
DT configurations for enabling PCI gen2 support
on IPQ5018. IPQ5018 has two phys and two controllers, 
one dual-lane and one single-lane.

Last patch series (v2) submitted dates back to August 27, 2024.
As I've worked to add IPQ5018 platform support in OpenWrt, I'm
continuing the efforts to add Linux kernel support.

v3:
  *) Depends on: https://patchwork.kernel.org/project/linux-arm-msm/cover/20250220094251.230936-1-quic_varada@quicinc.com/
  *) Added 8 MSI SPI and 1 global interrupts (Thanks Mani for confirming)
  *) Added hw revision (internal/synopsys) and nr of lanes in patch 4
     commit msg
  *) Sorted reg addresses and moved PCIe nodes accordingly
  *) Moved to GIC based interrupts
  *) Added rootport node in controller nodes
  *) Tested on Linksys devices (MX5500/SPNMX56)
  *) Link to v2: https://lore.kernel.org/all/20240827045757.1101194-1-quic_srichara@quicinc.com/

v2:
  Fixed all review comments from Krzysztof, Robert Marko,
  Dmitry Baryshkov, Manivannan Sadhasivam, Konrad Dybcio.
  Updated the respective patches for their changes.

v1:
 https://lore.kernel.org/lkml/32389b66-48f3-8ee8-e2f1-1613feed3cc7@gmail.com/T/

Sricharan Ramabadhran (6):
  dt-bindings: phy: qcom: uniphy-pcie: Add ipq5018 compatible
  phy: qualcomm: qcom-uniphy-pcie 28LP add support for IPQ5018
  dt-bindings: PCI: qcom: Add IPQ5018 SoC
  PCI: qcom: Add support for IPQ5018
  arm64: dts: qcom: ipq5018: Add PCIe related nodes
  arm64: dts: qcom: ipq5018: Enable PCIe

 .../devicetree/bindings/pci/qcom,pcie.yaml    |  49 ++++
 .../phy/qcom,ipq5332-uniphy-pcie-phy.yaml     |   3 +-
 .../arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts |  38 +++
 arch/arm64/boot/dts/qcom/ipq5018.dtsi         | 232 +++++++++++++++++-
 drivers/pci/controller/dwc/pcie-qcom.c        |   1 +
 .../phy/qualcomm/phy-qcom-uniphy-pcie-28lp.c  |  45 ++++
 6 files changed, 365 insertions(+), 3 deletions(-)

Comments

Krzysztof Kozlowski March 5, 2025, 4:47 p.m. UTC | #1
On 05/03/2025 14:41, George Moussalem wrote:
> From: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> 
> This patch series adds the relevant phy and controller
> DT configurations for enabling PCI gen2 support
> on IPQ5018. IPQ5018 has two phys and two controllers, 
> one dual-lane and one single-lane.
> 
> Last patch series (v2) submitted dates back to August 27, 2024.
> As I've worked to add IPQ5018 platform support in OpenWrt, I'm
> continuing the efforts to add Linux kernel support.

Why is this changelog separate? We talked about this 5 revisions ago and
you keep doing the same mistakes.

Best regards,
Krzysztof
George Moussalem March 5, 2025, 5:54 p.m. UTC | #2
On 3/5/25 20:47, Krzysztof Kozlowski wrote:
> On 05/03/2025 14:41, George Moussalem wrote:
>> From: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>
>> This patch series adds the relevant phy and controller
>> DT configurations for enabling PCI gen2 support
>> on IPQ5018. IPQ5018 has two phys and two controllers, 
>> one dual-lane and one single-lane.
>>
>> Last patch series (v2) submitted dates back to August 27, 2024.
>> As I've worked to add IPQ5018 platform support in OpenWrt, I'm
>> continuing the efforts to add Linux kernel support.
> Why is this changelog separate? We talked about this 5 revisions ago and
> you keep doing the same mistakes.
I've finally figured it out. It wasn't a git send-email bug I was running into.
I just analyzed the entire mail flow and found Outlook.com smtp servers replace the Message-ID
header value with the server name handling the email and places the actual Message-ID in another attribute
called X-Microsoft-Original-Message-ID. So when send-email sets the In-Reply-To header,
it uses the right one but the outlook.com mail servers replaced it with another value so threading breaks.

As a workaround, which I just tested, I will send the cover letter separately first, pick up the value
of Message-ID (which isn't the original one), and send the remaining patches with the --in-reply-to
argument of git send-email set to the newly replaced Message-ID.

This works. And apologies for the confusion/mess.
>
> Best regards,
> Krzysztof
Best regards,
George