EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY
which behaves slightly differently because one slot is Gen1/Gen2 while
the other is Gen1 only.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
---
.../phy/econet,en751221-pcie-phy.yaml | 50 +++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
new file mode 100644
index 000000000000..987d396c1c64
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/econet,en751221-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet PCI-Express PHY for EcoNet EN751221 and EN7528
+
+maintainers:
+ - Caleb James DeLisle <cjd@cjdns.fr>
+
+description:
+ The PCIe PHY supports physical layer functionality for PCIe Gen1 and
+ Gen1/Gen2 ports. On these SoCs, port 0 is a Gen1-only port while
+ port 1 is Gen1/Gen2 capable.
+
+properties:
+ compatible:
+ enum:
+ - econet,en751221-pcie-gen1
+ - econet,en751221-pcie-gen2
+ - econet,en7528-pcie-gen1
+ - econet,en7528-pcie-gen2
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pcie-phy@1faf2000 {
+ compatible = "econet,en7528-pcie-gen1";
+ reg = <0x1faf2000 0x1000>;
+ #phy-cells = <0>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 3781d55db5bb..bc925fa08baa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9122,6 +9122,12 @@ F: drivers/irqchip/irq-econet-en751221.c
F: include/dt-bindings/clock/econet,en751221-scu.h
F: include/dt-bindings/reset/econet,en751221-scu.h
+ECONET PCIE PHY DRIVER
+M: Caleb James DeLisle <cjd@cjdns.fr>
+L: linux-mips@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
+
ECRYPT FILE SYSTEM
M: Tyler Hicks <code@tyhicks.com>
L: ecryptfs@vger.kernel.org
--
2.39.5On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: > EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY > which behaves slightly differently because one slot is Gen1/Gen2 while > the other is Gen1 only. > > Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Still, four separate subsystems unnecessarily merged into one patchset. Split independent parts of your work per subsystem. See also submitting patches. > --- > .../phy/econet,en751221-pcie-phy.yaml | 50 +++++++++++++++++++ > MAINTAINERS | 6 +++ > 2 files changed, 56 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
On 10/03/2026 09:24, Krzysztof Kozlowski wrote: > On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: >> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY >> which behaves slightly differently because one slot is Gen1/Gen2 while >> the other is Gen1 only. >> >> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> > Still, four separate subsystems unnecessarily merged into one patchset. > Split independent parts of your work per subsystem. See also submitting > patches. I asked for clarification last time and didn't get a reply. I'm not against changing it but need to understand exactly what's expected b/c the way I'm imagining it seems way worse. submitting-patches.rst only says of patch sets "only post say 15 or so at a time", obviously not the case here. If you're asking for one patchset for phy, one for clock, one for PCI, and then one to introduce them to the device, I can do that. I just want to be sure because introducing unused code, and patch sets that depend on other patch sets both seem like anti-patterns to me. Thanks, Caleb >> --- >> .../phy/econet,en751221-pcie-phy.yaml | 50 +++++++++++++++++++ >> MAINTAINERS | 6 +++ >> 2 files changed, 56 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> > > Best regards, > Krzysztof > >
On 10/03/2026 11:37, Caleb James DeLisle wrote: > > On 10/03/2026 09:24, Krzysztof Kozlowski wrote: >> On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: >>> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY >>> which behaves slightly differently because one slot is Gen1/Gen2 while >>> the other is Gen1 only. >>> >>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> >> Still, four separate subsystems unnecessarily merged into one patchset. >> Split independent parts of your work per subsystem. See also submitting >> patches. > > > I asked for clarification last time and didn't get a reply. I'm not > against changing it but need to understand exactly what's expected b/c > the way I'm imagining it seems way worse. submitting-patches.rst only > says of patch sets "only post say 15 or so at a time", obviously not the > case here. > > If you're asking for one patchset for phy, one for clock, one for PCI, > and then one to introduce them to the device, I can do that. I just want > to be sure because introducing unused code, and patch sets that depend What is "unused" code? Or how is it unused? Do you understand this will go via different subsystems and nothing will be "used" anyway? > on other patch sets both seem like anti-patterns to me. And asking four different maintainers to manually pick up individual bits with multiple commands, instead of just applying entire set targeting their subsystem, is pro-pattern here? No. Why adding more work to maintainers? Think how this is seen by individual subsystem maintainers and how they should handle it. Best regards, Krzysztof
On 10/03/2026 11:40, Krzysztof Kozlowski wrote: > On 10/03/2026 11:37, Caleb James DeLisle wrote: >> On 10/03/2026 09:24, Krzysztof Kozlowski wrote: >>> On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: >>>> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY >>>> which behaves slightly differently because one slot is Gen1/Gen2 while >>>> the other is Gen1 only. >>>> >>>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> >>> Still, four separate subsystems unnecessarily merged into one patchset. >>> Split independent parts of your work per subsystem. See also submitting >>> patches. >> >> I asked for clarification last time and didn't get a reply. I'm not >> against changing it but need to understand exactly what's expected b/c >> the way I'm imagining it seems way worse. submitting-patches.rst only >> says of patch sets "only post say 15 or so at a time", obviously not the >> case here. >> >> If you're asking for one patchset for phy, one for clock, one for PCI, >> and then one to introduce them to the device, I can do that. I just want >> to be sure because introducing unused code, and patch sets that depend > What is "unused" code? Or how is it unused? Do you understand this will > go via different subsystems and nothing will be "used" anyway? Unused in the sense that you can't exercise that code without additional code which is out of tree - at least until the subsequent patch set lands. >> on other patch sets both seem like anti-patterns to me. > And asking four different maintainers to manually pick up individual > bits with multiple commands, instead of just applying entire set > targeting their subsystem, is pro-pattern here? No. Why adding more work > to maintainers? > > Think how this is seen by individual subsystem maintainers and how they > should handle it. Okay I think I see the goal, thank you. And you know I'm not smart enough to have an actual opinion on this, I just needed to understand the "why" so that I can do what's expected w/o goofing it up. Thanks, Caleb > > > > Best regards, > Krzysztof >
On 10/03/2026 12:13, Caleb James DeLisle wrote: > > On 10/03/2026 11:40, Krzysztof Kozlowski wrote: >> On 10/03/2026 11:37, Caleb James DeLisle wrote: >>> On 10/03/2026 09:24, Krzysztof Kozlowski wrote: >>>> On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: >>>>> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY >>>>> which behaves slightly differently because one slot is Gen1/Gen2 while >>>>> the other is Gen1 only. >>>>> >>>>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> >>>> Still, four separate subsystems unnecessarily merged into one patchset. >>>> Split independent parts of your work per subsystem. See also submitting >>>> patches. >>> >>> I asked for clarification last time and didn't get a reply. I'm not >>> against changing it but need to understand exactly what's expected b/c >>> the way I'm imagining it seems way worse. submitting-patches.rst only >>> says of patch sets "only post say 15 or so at a time", obviously not the >>> case here. >>> >>> If you're asking for one patchset for phy, one for clock, one for PCI, >>> and then one to introduce them to the device, I can do that. I just want >>> to be sure because introducing unused code, and patch sets that depend >> What is "unused" code? Or how is it unused? Do you understand this will >> go via different subsystems and nothing will be "used" anyway? > > > Unused in the sense that you can't exercise that code without additional > code which is out of tree - at least until the subsequent patch set lands. Which is exactly the same as with your method of combining independent subsystems here. Do you know this goes via independent subsystems? Around four of them? Best regards, Krzysztof
On 10/03/2026 11:40, Krzysztof Kozlowski wrote: > On 10/03/2026 11:37, Caleb James DeLisle wrote: >> >> On 10/03/2026 09:24, Krzysztof Kozlowski wrote: >>> On Mon, Mar 09, 2026 at 01:18:13PM +0000, Caleb James DeLisle wrote: >>>> EN751221 and EN7528 SoCs have two PCIe slots, and each one has a PHY >>>> which behaves slightly differently because one slot is Gen1/Gen2 while >>>> the other is Gen1 only. >>>> >>>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> >>> Still, four separate subsystems unnecessarily merged into one patchset. >>> Split independent parts of your work per subsystem. See also submitting >>> patches. >> >> >> I asked for clarification last time and didn't get a reply. I'm not >> against changing it but need to understand exactly what's expected b/c >> the way I'm imagining it seems way worse. submitting-patches.rst only >> says of patch sets "only post say 15 or so at a time", obviously not the >> case here. >> >> If you're asking for one patchset for phy, one for clock, one for PCI, >> and then one to introduce them to the device, I can do that. I just want >> to be sure because introducing unused code, and patch sets that depend > > What is "unused" code? Or how is it unused? Do you understand this will > go via different subsystems and nothing will be "used" anyway? > >> on other patch sets both seem like anti-patterns to me. > > And asking four different maintainers to manually pick up individual > bits with multiple commands, instead of just applying entire set > targeting their subsystem, is pro-pattern here? No. Why adding more work > to maintainers? > > Think how this is seen by individual subsystem maintainers and how they > should handle it. > Heh, and nothing of this is explained in cover letter - nothing about dependencies or merging order - so how anyone can figure out what can be applied here? Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.