From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: linux-rockchip@lists.infradead.org
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Geraldo Nascimento" <geraldogabriel@gmail.com>
Subject: [RFC PATCH 0/2] PCI: rockchip-host: support quirky devices
Date: Mon, 3 Nov 2025 03:26:35 -0300 [thread overview]
Message-ID: <cover.1762150971.git.geraldogabriel@gmail.com> (raw)
With these two changes I'm able to work with a Samsung PM981a OEM SSD
that is known to be not-working with Rockchip-IP PCIe.
Previously I attempted a contrived solution that mostly worked for my
simple purposes but was rather inelegant and impractical.
Now I have isolated the behavior to the three lines in the two commits.
Omit those three lines and you get a working set with the kernel.
I have no idea how to actually implement this in a way that makes sense
and doesn't break the PCIe spec but it is my sincere wish that
interested RK3399 parties test the change and report any regressions
with already-working devices and specifically, successes or failures of
initial link-training with these changes.
Geraldo Nascimento (2):
arm64: dts: rockchip: drop PCIe 3v3 always-on/boot-on
PCI: rockchip-host: drop wait on PERST# toggle
arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi | 2 --
drivers/pci/controller/pcie-rockchip-host.c | 1 -
2 files changed, 3 deletions(-)
--
2.49.0
WARNING: multiple messages have this Message-ID (diff)
From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: linux-rockchip@lists.infradead.org
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Geraldo Nascimento" <geraldogabriel@gmail.com>
Subject: [RFC PATCH 0/2] PCI: rockchip-host: support quirky devices
Date: Mon, 3 Nov 2025 03:26:35 -0300 [thread overview]
Message-ID: <cover.1762150971.git.geraldogabriel@gmail.com> (raw)
With these two changes I'm able to work with a Samsung PM981a OEM SSD
that is known to be not-working with Rockchip-IP PCIe.
Previously I attempted a contrived solution that mostly worked for my
simple purposes but was rather inelegant and impractical.
Now I have isolated the behavior to the three lines in the two commits.
Omit those three lines and you get a working set with the kernel.
I have no idea how to actually implement this in a way that makes sense
and doesn't break the PCIe spec but it is my sincere wish that
interested RK3399 parties test the change and report any regressions
with already-working devices and specifically, successes or failures of
initial link-training with these changes.
Geraldo Nascimento (2):
arm64: dts: rockchip: drop PCIe 3v3 always-on/boot-on
PCI: rockchip-host: drop wait on PERST# toggle
arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi | 2 --
drivers/pci/controller/pcie-rockchip-host.c | 1 -
2 files changed, 3 deletions(-)
--
2.49.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next reply other threads:[~2025-11-03 6:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 6:26 Geraldo Nascimento [this message]
2025-11-03 6:26 ` [RFC PATCH 0/2] PCI: rockchip-host: support quirky devices Geraldo Nascimento
2025-11-03 6:27 ` [RFC PATCH 1/2] arm64: dts: rockchip: drop PCIe 3v3 always-on/boot-on Geraldo Nascimento
2025-11-03 6:27 ` Geraldo Nascimento
2025-11-03 6:27 ` [RFC PATCH 2/2] PCI: rockchip-host: drop wait on PERST# toggle Geraldo Nascimento
2025-11-03 6:27 ` Geraldo Nascimento
2025-11-03 18:10 ` Bjorn Helgaas
2025-11-03 18:10 ` Bjorn Helgaas
2025-11-03 20:55 ` Geraldo Nascimento
2025-11-03 20:55 ` Geraldo Nascimento
2025-11-05 3:55 ` Geraldo Nascimento
2025-11-05 3:55 ` Geraldo Nascimento
2025-11-05 9:06 ` Diederik de Haas
2025-11-05 9:06 ` Diederik de Haas
2025-11-05 21:22 ` Geraldo Nascimento
2025-11-05 21:22 ` Geraldo Nascimento
2025-11-07 10:27 ` Diederik de Haas
2025-11-07 10:27 ` Diederik de Haas
2025-11-09 23:51 ` Dragan Simic
2025-11-09 23:51 ` Dragan Simic
2025-11-09 23:57 ` Geraldo Nascimento
2025-11-09 23:57 ` Geraldo Nascimento
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=cover.1762150971.git.geraldogabriel@gmail.com \
--to=geraldogabriel@gmail.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.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.