* [PATCH v4 2/2] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Christophe Roullier @ 2024-03-26 13:00 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
The Linux kernel dwmac-stm32 driver currently supports three DT
properties used to configure whether PHY clock are generated by
the MAC or supplied to the MAC from the PHY.
Originally there were two properties, st,eth-clk-sel and
st,eth-ref-clk-sel, each used to configure MAC clocking in
different bus mode and for different MAC clock frequency.
Since it is possible to determine the MAC 'eth-ck' clock
frequency from the clock subsystem and PHY bus mode from
the 'phy-mode' property, two disparate DT properties are
no longer required to configure MAC clocking.
Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
introduced a third, unified, property st,ext-phyclk. This property
covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
properties, as well as a new use case for 25 MHz clock generated
by the MAC.
The third property st,ext-phyclk is so far undocumented,
document it.
Below table summarizes the clock requirement and clock sources for
supported PHY interface modes.
__________________________________________________________________________
|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
| | | 25MHz | 50MHz | |
---------------------------------------------------------------------------
| MII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| GMII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| RGMII | - | eth-ck | n/a | eth-ck |
| | | st,ext-phyclk | | st,eth-clk-sel or|
| | | | | st,ext-phyclk |
---------------------------------------------------------------------------
| RMII | - | eth-ck | eth-ck | n/a |
| | | st,ext-phyclk | st,eth-ref-clk-sel | |
| | | | or st,ext-phyclk | |
---------------------------------------------------------------------------
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index 80937b28fa046..529665d4fc911 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -85,6 +85,13 @@ properties:
phy-supply:
description: PHY regulator
+ st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
+
st,eth-clk-sel:
description:
set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125.
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/4] dt-bindings: rtc: convert multiple devices to dtschema
From: Javier Carrasco @ 2024-03-26 13:03 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco, Krzysztof Kozlowski
This series converts the following existing bindings to dtschema:
- armada-380-rtc
- alphascale,asm9260-rtc
- digicolor-rtc (moved to trivial-rtc)
- nxp,lpc1788-rtc
All bindings include at least one compatible that is referenced in the
existing dts (arch/arm). Those dts could be tested against the new
bindings.
It might be worth mentioning that the reference to nxp,lpc1788-rtc in
arch/arm/boot/dts/nxp/lpc/lpc18xx.dtsi also includes another compatible
called nxp,lpc1850-rtc, which is not documented or supported by existing
drivers. That generates a warning when testing against nxp,lpc1788-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Changes in v3:
- alphascale-asm9260-rtc: drop unnecessary reg description.
- nxp,lpc1788-rtc: drop unnecessary reg description.
- Link to v2: https://lore.kernel.org/r/20240325-rtc-yaml-v2-0-ff9f68f43dbc@gmail.com
Changes in v2:
- General: reference to rtc.yaml
- digicolor-rtc: move to trivial-rtc
- Link to v1: https://lore.kernel.org/r/20240323-rtc-yaml-v1-0-0c5d12b1b89d@gmail.com
---
Javier Carrasco (4):
dt-bindings: rtc: armada-380-rtc: convert to dtschema
dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
.../bindings/rtc/alphascale,asm9260-rtc.txt | 19 -------
.../bindings/rtc/alphascale,asm9260-rtc.yaml | 50 +++++++++++++++++++
.../devicetree/bindings/rtc/armada-380-rtc.txt | 24 ---------
.../devicetree/bindings/rtc/digicolor-rtc.txt | 17 -------
.../bindings/rtc/marvell,armada-380-rtc.yaml | 51 +++++++++++++++++++
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.txt | 21 --------
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml | 58 ++++++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 2 +
8 files changed, 161 insertions(+), 81 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240322-rtc-yaml-473335cbf911
Best regards,
--
Javier Carrasco <javier.carrasco.cruz@gmail.com>
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: rtc: armada-380-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-26 13:03 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco, Krzysztof Kozlowski
In-Reply-To: <20240326-rtc-yaml-v3-0-caa430ecace7@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/armada-380-rtc.txt | 24 ----------
.../bindings/rtc/marvell,armada-380-rtc.yaml | 51 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt b/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
deleted file mode 100644
index c3c9a1226f9a..000000000000
--- a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Real Time Clock of the Armada 38x/7K/8K SoCs
-
-RTC controller for the Armada 38x, 7K and 8K SoCs
-
-Required properties:
-- compatible : Should be one of the following:
- "marvell,armada-380-rtc" for Armada 38x SoC
- "marvell,armada-8k-rtc" for Aramda 7K/8K SoCs
-- reg: a list of base address and size pairs, one for each entry in
- reg-names
-- reg names: should contain:
- * "rtc" for the RTC registers
- * "rtc-soc" for the SoC related registers and among them the one
- related to the interrupt.
-- interrupts: IRQ line for the RTC.
-
-Example:
-
-rtc@a3800 {
- compatible = "marvell,armada-380-rtc";
- reg = <0xa3800 0x20>, <0x184a0 0x0c>;
- reg-names = "rtc", "rtc-soc";
- interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
new file mode 100644
index 000000000000..adf3ba0cd09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,armada-380-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RTC controller for the Armada 38x, 7K and 8K SoCs
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-380-rtc
+ - marvell,armada-8k-rtc
+
+ reg:
+ items:
+ - description: RTC base address size
+ - description: Base address and size of SoC related registers
+
+ reg-names:
+ items:
+ - const: rtc
+ - const: rtc-soc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@a3800 {
+ compatible = "marvell,armada-380-rtc";
+ reg = <0xa3800 0x20>, <0x184a0 0x0c>;
+ reg-names = "rtc", "rtc-soc";
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.40.1
^ permalink raw reply related
* [PATCH v3 2/4] dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-26 13:03 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco, Krzysztof Kozlowski
In-Reply-To: <20240326-rtc-yaml-v3-0-caa430ecace7@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../bindings/rtc/alphascale,asm9260-rtc.txt | 19 --------
.../bindings/rtc/alphascale,asm9260-rtc.yaml | 50 ++++++++++++++++++++++
2 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
deleted file mode 100644
index 76ebca568db9..000000000000
--- a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Alphascale asm9260 SoC Real Time Clock
-
-Required properties:
-- compatible: Should be "alphascale,asm9260-rtc"
-- reg: Physical base address of the controller and length
- of memory mapped region.
-- interrupts: IRQ line for the RTC.
-- clocks: Reference to the clock entry.
-- clock-names: should contain:
- * "ahb" for the SoC RTC clock
-
-Example:
-rtc0: rtc@800a0000 {
- compatible = "alphascale,asm9260-rtc";
- reg = <0x800a0000 0x100>;
- clocks = <&acc CLKID_AHB_RTC>;
- clock-names = "ahb";
- interrupts = <2>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
new file mode 100644
index 000000000000..f955a7f638ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/alphascale,asm9260-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alphascale asm9260 SoC Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: alphascale,asm9260-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ahb
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/alphascale,asm9260.h>
+
+ rtc@800a0000 {
+ compatible = "alphascale,asm9260-rtc";
+ reg = <0x800a0000 0x100>;
+ clocks = <&acc CLKID_AHB_RTC>;
+ clock-names = "ahb";
+ interrupts = <2>;
+ };
--
2.40.1
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-03-26 13:03 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco, Krzysztof Kozlowski
In-Reply-To: <20240326-rtc-yaml-v3-0-caa430ecace7@gmail.com>
Convert existing binding to dtschema to support validation.
This device meets the requirements to be moved to trivial-rtc
(compatible, reg and a single interrupt).
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/digicolor-rtc.txt | 17 -----------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt b/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
deleted file mode 100644
index d464986012cd..000000000000
--- a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Conexant Digicolor Real Time Clock controller
-
-This binding currently supports the CX92755 SoC.
-
-Required properties:
-- compatible: should be "cnxt,cx92755-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: rtc alarm interrupt
-
-Example:
-
- rtc@f0000c30 {
- compatible = "cnxt,cx92755-rtc";
- reg = <0xf0000c30 0x18>;
- interrupts = <25>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index c9e3c5262c21..a3db41c5207c 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -24,6 +24,8 @@ properties:
- abracon,abb5zes3
# AB-RTCMC-32.768kHz-EOZ9: Real Time Clock/Calendar Module with I2C Interface
- abracon,abeoz9
+ # Conexant Digicolor Real Time Clock Controller
+ - cnxt,cx92755-rtc
# I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
- dallas,ds1374
# Dallas DS1672 Real-time Clock
--
2.40.1
^ permalink raw reply related
* [PATCH v3 4/4] dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
From: Javier Carrasco @ 2024-03-26 13:03 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
Javier Carrasco, Krzysztof Kozlowski
In-Reply-To: <20240326-rtc-yaml-v3-0-caa430ecace7@gmail.com>
Convert existing binding to dtschema to support validation.
This is a direct conversion with no additions.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.txt | 21 --------
.../devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml | 58 ++++++++++++++++++++++
2 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
deleted file mode 100644
index 3c97bd180592..000000000000
--- a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-NXP LPC1788 real-time clock
-
-The LPC1788 RTC provides calendar and clock functionality
-together with periodic tick and alarm interrupt support.
-
-Required properties:
-- compatible : must contain "nxp,lpc1788-rtc"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A single interrupt specifier.
-- clocks : Must contain clock specifiers for rtc and register clock
-- clock-names : Must contain "rtc" and "reg"
- See ../clocks/clock-bindings.txt for details.
-
-Example:
-rtc: rtc@40046000 {
- compatible = "nxp,lpc1788-rtc";
- reg = <0x40046000 0x1000>;
- interrupts = <47>;
- clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
- clock-names = "rtc", "reg";
-};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
new file mode 100644
index 000000000000..e88b847a1cc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,lpc1788-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1788 real-time clock
+
+description:
+ The LPC1788 RTC provides calendar and clock functionality
+ together with periodic tick and alarm interrupt support.
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: nxp,lpc1788-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: RTC clock
+ - description: Register clock
+
+ clock-names:
+ items:
+ - const: rtc
+ - const: reg
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ rtc@40046000 {
+ compatible = "nxp,lpc1788-rtc";
+ reg = <0x40046000 0x1000>;
+ clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
+ clock-names = "rtc", "reg";
+ interrupts = <47>;
+ };
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support
From: Landge, Sudan @ 2024-03-26 13:06 UTC (permalink / raw)
To: Rob Herring
Cc: Sudan Landge, tytso, Jason, krzysztof.kozlowski+dt, conor+dt,
sathyanarayanan.kuppuswamy, thomas.lendacky, dan.j.williams,
devicetree, linux-kernel, graf, dwmw, bchalios, xmarcalx
In-Reply-To: <CAL_JsqKpp+J2a_+wmcaOX8RfTEEyZBESWBX7GWGa_u_5_=4gsg@mail.gmail.com>
On 25/03/2024 20:41, Rob Herring wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Mon, Mar 25, 2024 at 3:11 PM Landge, Sudan <sudanl@amazon.co.uk> wrote:
>>
>>
>>
>> On 25/03/2024 15:06, Rob Herring wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> On Thu, Mar 21, 2024 at 02:51:04AM +0000, Sudan Landge wrote:
>>>> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
>>>> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
>>>> ACPI only device.
>>>>
>>>> VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
>>>> a mechanism for the BIOS/hypervisors to communicate to the virtual machine
>>>> that it is executed with a different configuration (e.g. snapshot execution
>>>> or creation from a template).
>>>> The guest operating system can use the notification for various purposes
>>>> such as re-initializing its random number generator etc.
>>>>
>>>> As per the specs, hypervisor should provide a globally unique identified,
>>>> or GUID via ACPI.
>>>>
>>>> This patch tries to mimic the mechanism to provide the same functionality
>>>> which is for a hypervisor/BIOS to notify the virtual machine when it is
>>>> executed with a different configuration.
>>>>
>>>> As part of this support the devicetree bindings requires the hypervisors or
>>>> BIOS to provide a memory address which holds the GUID and an IRQ which is
>>>> used to notify when there is a change in the GUID.
>>>> The memory exposed in the DT should follow the rules defined in the
>>>> vmgenid spec mentioned above.
>>>>
>>>> *Reason for this change*:
>>>> Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
>>>> Without going into details of why a hypervisor would chose DT over ACPI,
>>>> we would like to highlight that the hypervisors that have chose devicetree
>>>> and now want to make use of the vmgenid functionality cannot do so today
>>>> because vmgenid is an ACPI only device.
>>>> This forces these hypervisors to change their design which could have
>>>> undesirable impacts on their use-cases, test-scenarios etc.
>>>>
>>>> The point of vmgenid is to provide a mechanism to discover a GUID when
>>>> the execution state of a virtual machine changes and the simplest
>>>> way to do it is pass a memory location and an interrupt via devicetree.
>>>> It would complicate things unnecessarily if instead of using devicetree,
>>>> we try to implement a new protocol or modify other protocols to somehow
>>>> provide the same functionility.
>>>>
>>>> We believe that adding a devicetree binding for vmgenid is a simpler,
>>>> better alternative to provide the same functionality and will allow
>>>> such hypervisors as mentioned above to continue using devicetree.
>>>>
>>>> More references to vmgenid specs:
>>>> - https://www.qemu.org/docs/master/specs/vmgenid.html
>>>> - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-machine-generation-identifier
>>>>
>>>> Signed-off-by: Sudan Landge <sudanl@amazon.com>
>>>> ---
>>>> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
>>>> MAINTAINERS | 1 +
>>>> 2 files changed, 58 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>> new file mode 100644
>>>> index 000000000000..4b6ab62cc2ae
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
>>>> @@ -0,0 +1,57 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Virtual Machine Generation Counter ID device
>>>> +
>>>> +maintainers:
>>>> + - Jason A. Donenfeld <Jason@zx2c4.com>
>>>> +
>>>> +description:
>>>> + Firmwares or hypervisors can use this devicetree to describe
>>>> + interrupts and the shared resources to inject a Virtual Machine Generation
>>>> + counter.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: linux,vmgenctr
>>>
>>> Why 'linux'? It should be named for a particular host implementation
>>> (and that implementation's bugs/quirks). However, this thing is simple
>>> enough we can perhaps avoid that here. As the interface is defined by
>>> Microsoft, then perhaps they should be the vendor here.
>>>
>> We chose "linux" because the current implementation and usage of
>> devicetree was Linux specific. However, I think "virtual" would be a
>> better choice than "Microsoft" since this is a generic virtual device
>> that could be configured by any hypervisor or firmware not owned or
>> related to Microsoft. I have updated this as part of the new version if
>> it looks good. I don't have a strong opinion for "virtual" though so if
>> that is the right choice as per you I can update it.
>
> I'm not really a fan of 'virtual' and its one and only existing use.
> Don't add to it.
>
> Someone has defined how to read a GUID from register(s). I can think
> of many ways that could be implemented. The data itself could be hex
> or ascii. You could read N times from one register or read from N
> sequential registers. And again, there's endianness and access sizes.
> Given the only source of any of that is a Microsoft spec, then that
> makes sense to me. Or just no vendor prefix is possible, but I prefer
> to avoid those cases.
ok, you are right. Using "Microsoft" as the compatible string makes more
sense. I will use that.
>
> Also, consider 'vmgenctr' has basically 0 search results. 'vmgenid'
> returns some relevant results. Not that search results are a
> requirement for naming, but perhaps something to consider.
>
The original driver supports 2 ACPI CIDs, "VMGENCTR" and
"VM_GEN_COUNTER" and as per this commit
https://github.com/torvalds/linux/commit/0396e46dc46523cba8401a0df84f67cc0b6067ab
"VMGENCTR" is to be used for VMGenID specs. So, I used "vmgenctr" to be
consistent with its ACPI counterpart "VMGENCTR".
>>>> +
>>>> + "#interrupt-cells":
>>>> + const: 3
>>>> + description: |
>>>> + The 1st cell is the interrupt type.
>>>> + The 2nd cell contains the interrupt number for the interrupt type.
>>>> + The 3rd cell is for trigger type and level flags.
>>>> +
>>>> + interrupt-controller: true
>>>
>>> Why is this device an interrupt controller?
>>>
>> My devicetree references I took initially were incorrect which led to
>> the addition of this, I have removed this in the next version. Sorry
>> about that.
>
> Try again...
>
Ok, I will confirm my understanding and provide a better answer in my
next mail. As you mentioned in another mail, I will also pause on
posting any new version till the current threads are answered.
>>>> +
>>>> + reg:
>>>> + description: |
>>>> + specifies the base physical address and
>>>> + size of the regions in memory which holds the VMGenID counter.
>>>
>>> Odd wrapping, but drop unless you have something specific to say about
>>> region like perhaps the layout of the registers. Or maybe thats defined
>>> somewhere else?
>>>
>>> Does the spec say anything about endianness or access size? DT assumes
>>> native endianness by default. We have properties to deal these, but
>>> would be better to be explicit if that's defined already.
>>>
>> The spec doesn't mention anything about the endianness but, I have
>> updated the description with some more data.
>
> Then what does your driver assume? Microsoft may not have thought
> about it because they don't care, but now you want to use DT so you
> have to because it is frequently used on BE systems. If we define
> something, then there's some hope. Otherwise, it's pretty much a
> guarantee folks will do the opposite.
>
> Rob
The driver does not assume any endianness. To provide more context, The
hypervisor stores a 128bit unique ID at the address pointed by the
"reg"'s 1st cell, driver memcpy's this ID to an internal context and
uses memcmp to compare if the ID is new or old.
But yes, it will be good to define a fixed endianness to avoid any
error. I will update the description to use little endian.
^ permalink raw reply
* Re: [PATCH v3 1/8] firmware: smccc: Export revision soc_id function
From: Sudeep Holla @ 2024-03-26 13:18 UTC (permalink / raw)
To: Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Sudeep Holla, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Rafael J . Wysocki,
Mark Rutland, Lorenzo Pieralisi, linux-pm, devicetree,
linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi, Martin Botka,
Martin Botka, Chris Morgan, Ryan Walklin
In-Reply-To: <20240326114743.712167-2-andre.przywara@arm.com>
On Tue, Mar 26, 2024 at 11:47:36AM +0000, Andre Przywara wrote:
> From: Martin Botka <martin.botka@somainline.org>
>
> The "SoC ID revision" as provided via the SMCCC SOCID interface can be
> valuable information for drivers, when certain functionality depends
> on a die revision, for instance.
> One example is the sun50i-cpufreq-nvmem driver, which needs this
> information to determine the speed bin of the SoC.
>
> Export the arm_smccc_get_soc_id_revision() function so that it can be
> called by any driver.
>
Assuming sun50i cpufreq driver can be built as module,
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: hsi: omap-ssi: convert to YAML
From: Sebastian Reichel @ 2024-03-26 13:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tony Lindgren,
devicetree, linux-omap, linux-kernel
In-Reply-To: <8cd3158b-ed51-4a1f-a626-fa58c85d4aeb@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
Hi,
On Tue, Mar 26, 2024 at 08:26:54AM +0100, Krzysztof Kozlowski wrote:
> On 25/03/2024 22:45, Sebastian Reichel wrote:
> > Convert the legacy txt binding to modern YAML.
> > No semantic change.
>
> You deprecated a property: ti,hwmods. Also will be one more change:
> ti,ssi-cawake-gpio->gpios
and I will introduce a simple bus binding for referencing the
peripheral. I added a list to the commit message for v2.
> > Documentation/devicetree/bindings/hsi/omap-ssi.txt | 102 -----------
> > .../devicetree/bindings/hsi/ti,omap-ssi.yaml | 196 +++++++++++++++++++++
> > 2 files changed, 196 insertions(+), 102 deletions(-)
[...]
> > +patternProperties:
> > + "[hs]si-port@[0-9a-f]+":
>
> Does anything actually depends on the name? Can these be "port@[0-9a-f]+"?
That should work. The Linux driver is looping over all child nodes
and checking the compatible.
[...]
> > + ti,ssi-cawake-gpio:
>
> ti,ssi-cawake-gpios
mh, the kernel supports the extra s since 2016. I guess that should
be good enough. I will fix it in v2.
All other comments will be fixed in v2.
Thanks for the review,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: 回复: [PATCH v2 1/2] ASoC: dt-bindings: Add bindings for Cadence I2S-MC controller
From: Xingyu Wu @ 2024-03-26 13:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Claudiu Beznea,
Jaroslav Kysela, Takashi Iwai, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, linux-sound@vger.kernel.org
In-Reply-To: <9b1a5100-8536-4b59-b2e7-d6ebd2ba9e66@linaro.org>
On 26/03/2024 14:46, Krzysztof Kozlowski wrote:
>
> On 26/03/2024 07:29, Xingyu Wu wrote:
> >>
> >> On 20/03/2024 10:02, Xingyu Wu wrote:
> >>> Add bindings for the Multi-Channel I2S controller of Cadence.
>
> Your email app responds very weird. You bypassed all possible filters and it is
> simply not visible that you answer to me. You Reply to everyone, not to me with
> Cc to others. There is no standard header whom do you quote, e.g. "On
> 26/03/2024 07:29, Xingyu Wu wrote:"
>
> Please use some decent email system, otherwise I will miss all replies from you.
Thank you for reminding me. I will correct it.
>
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + enum:
> >>> + - cdns,i2s-mc
> >>
> >> Why did this appear? Who asked for this? Usually these blocks are not
> >> usable on their own.
> >
> > I wonder if I should keep the original IP compatible. Do I not need it?
>
> As I said, it is not usable on its own, so unless you have other arguments then no.
> But my point was that no one asked for this.
I want to keep the original IP compatible which can distinguish from the JH8100 SoC.
Can I write it like this:
compatible:
enum:
- starfive,jh8100-i2s
const: cdns,i2s-mc
and I write this in the DTS:
compatible = "starfive,jh8100-i2s", "cdns,i2s-mc";
>
> >
> >>
> >>> + - starfive,jh8100-i2s
> >>> +
> >>> + reg:
> >>> + maxItems: 1
> >>> +
> >>> + interrupts:
> >>> + description:
> >>> + The interrupt line number for the I2S controller. Add this
> >>> + parameter if the I2S controller that you are using does not
> >>> + using DMA.
> >>
> >> That's still wrong. You already got comment on this. Either you have interrupt
> or not.
> >> You do not add interrupts, based on your choice or not of having DMA.
> >> Drop the comment.
> >
> > Do I keep this property and drop this description?
>
> Drop description. Keep property, if your hardware has interrupts.
>
Will drop.
> ...
>
> >>
> >>> + - compatible
> >>> + - reg
> >>> + - clocks
> >>> + - clock-names
> >>> + - resets
> >>> +
> >>> +oneOf:
> >>> + - required:
> >>> + - dmas
> >>> + - dma-names
> >>> + - required:
> >>> + - interrupts
> >>
> >> This won't work. Provide both interrupts and dmas, and then test your DTS.
> >
> > I provided both properties in the DTS and test by dtbs_check. Then it printed
> that:
> > 'More than one condition true in one of shema: ...'
>
> Exactly. Having both properties is a correct DTS. Interrupts do not disappear just
> because you decide to describe DMA. It is OS choice what to use if both are
> provided.
>
But this I2S can only use either DMA or interrupts.
Can I use the config (like SND_SOC_CADENCE_I2S_MC_PCM) to choose DMA or
interrupt if having both them in DTS?
Best regards,
Xingyu Wu
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: net: add phy-supply property for stm32
From: Andrew Lunn @ 2024-03-26 13:58 UTC (permalink / raw)
To: Christophe Roullier
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Marek Vasut, netdev, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240326125849.226765-2-christophe.roullier@foss.st.com>
On Tue, Mar 26, 2024 at 01:58:48PM +0100, Christophe Roullier wrote:
> Phandle to a regulator that provides power to the PHY. This
> regulator will be managed during the PHY power on/off sequence.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> index fc8c96b08d7dc..80937b28fa046 100644
> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -82,6 +82,9 @@ properties:
> Should be phandle/offset pair. The phandle to the syscon node which
> encompases the glue register, and the offset of the control register
>
> + phy-supply:
> + description: PHY regulator
~/linux/drivers/net/ethernet/stmicro/stmmac$ grep regulator_get *
dwmac-rk.c: bsp_priv->regulator = devm_regulator_get(dev, "phy");
dwmac-sun8i.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
dwmac-sunxi.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
Maybe i'm missing something, but i don't see an actual implementation
of this binding?
Andrew
^ permalink raw reply
* Re: [PATCH v3 4/4] virt: vmgenid: add support for devicetree bindings
From: Landge, Sudan @ 2024-03-26 14:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sudan Landge, tytso, Jason, robh+dt,
krzysztof.kozlowski+dt, conor+dt, sathyanarayanan.kuppuswamy,
thomas.lendacky, dan.j.williams, devicetree, linux-kernel
Cc: graf, dwmw, bchalios, xmarcalx
In-Reply-To: <5ca78fc8-4a53-4f09-878f-4a47875f9de5@linaro.org>
On 25/03/2024 21:51, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 25/03/2024 20:53, Sudan Landge wrote:
>> - Extend the vmgenid platform driver to support devicetree bindings.
>> With this support, hypervisors can send vmgenid notifications to
>> the virtual machine without the need to enable ACPI. The bindings
>> are located at: Documentation/devicetree/bindings/rng/vmgenid.yaml
>>
>> - Use proper FLAGS to compile with and without ACPI and/or devicetree.
>
> I do not see any flags. You use if/ifdefs which is a NAK.
>
> Do not mix independent changes within one commit. Please follow
> guidelines in submitting-patches for this.
>
By flags, I was referring to "#if IS_ENABLED(CONFIG_ACPI)". I will
remove the comment if its incorrect.
>>
>> Signed-off-by: Sudan Landge <sudanl@amazon.com>
>> ---
>> drivers/virt/Kconfig | 1 -
>> drivers/virt/vmgenid.c | 85 +++++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 80 insertions(+), 6 deletions(-)
>>
>
> ...
>
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +static irqreturn_t vmgenid_of_irq_handler(int irq, void *dev)
>> +{
>> + (void)irq;
>> + vmgenid_notify(dev);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +#endif
>>
>> static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
>> {
>> @@ -55,6 +70,7 @@ static int setup_vmgenid_state(struct vmgenid_state *state, u8 *next_id)
>>
>> static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
>> {
>> +#if IS_ENABLED(CONFIG_ACPI)
>
> Why do you create all this ifdeffery in the code? You already got
> comments to get rid of all this #if.
>
This was added to avoid errors if CONFIG_ACPI or CONFIG_OF was not
enabled. I will refer to other drivers again to see how they handle this.
>> struct acpi_device *device = ACPI_COMPANION(dev);
>> struct acpi_buffer parsed = { ACPI_ALLOCATE_BUFFER };
>> union acpi_object *obj;
>> @@ -96,6 +112,49 @@ static int vmgenid_add_acpi(struct device *dev, struct vmgenid_state *state)
>> out:
>> ACPI_FREE(parsed.pointer);
>> return ret;
>> +#else
>> + (void)dev;
>> + (void)state;
>> + return -EINVAL;
>> +#endif
>> +}
>> +
>> +static int vmgenid_add_of(struct platform_device *pdev, struct vmgenid_state *state)
>> +{
>> +#if IS_ENABLED(CONFIG_OF)
>> + void __iomem *remapped_ptr;
>> + int ret = 0;
>> +
>> + remapped_ptr = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
>> + if (IS_ERR(remapped_ptr)) {
>> + ret = PTR_ERR(remapped_ptr);
>> + goto out;
>> + }
>> +
>> + ret = setup_vmgenid_state(state, remapped_ptr);
>> + if (ret)
>> + goto out;
>> +
>> + state->irq = platform_get_irq(pdev, 0);
>> + if (state->irq < 0) {
>> + ret = state->irq;
>> + goto out;
>> + }
>> + pdev->dev.driver_data = state;
>> +
>> + ret = devm_request_irq(&pdev->dev, state->irq,
>> + vmgenid_of_irq_handler,
>> + IRQF_SHARED, "vmgenid", &pdev->dev);
>> + if (ret)
>> + pdev->dev.driver_data = NULL;
>> +
>> +out:
>> + return ret;
>> +#else
>
>
> That's neither readable code nor matching Linux coding style. Driver
> don't do such magic. Please open some recent drivers for ACPI and OF and
> look there. Old drivers had stubs for !CONFIG_XXX, but new drivers don't
> have even that.
>
Sorry about that, I will refer to a new driver and correct this.
>> + (void)dev;
>> + (void)state;
>> + return -EINVAL;
>> +#endif
>> }
>>
>> static int vmgenid_add(struct platform_device *pdev)
>> @@ -108,7 +167,10 @@ static int vmgenid_add(struct platform_device *pdev)
>> if (!state)
>> return -ENOMEM;
>>
>> - ret = vmgenid_add_acpi(dev, state);
>> + if (dev->of_node)
>> + ret = vmgenid_add_of(pdev, state);
>> + else
>> + ret = vmgenid_add_acpi(dev, state);
>>
>> if (ret)
>> devm_kfree(dev, state);
>> @@ -116,18 +178,31 @@ static int vmgenid_add(struct platform_device *pdev)
>> return ret;
>> }
>>
>> -static const struct acpi_device_id vmgenid_ids[] = {
>> +#if IS_ENABLED(CONFIG_OF)
>
> No, drop.
>
>> +static const struct of_device_id vmgenid_of_ids[] = {
>> + { .compatible = "linux,vmgenctr", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, vmgenid_of_ids);
>> +#endif
>> +
>> +#if IS_ENABLED(CONFIG_ACPI)
>
>
>> +static const struct acpi_device_id vmgenid_acpi_ids[] = {
>> { "VMGENCTR", 0 },
>> { "VM_GEN_COUNTER", 0 },
>> { }
>> };
>> -MODULE_DEVICE_TABLE(acpi, vmgenid_ids);
>> +MODULE_DEVICE_TABLE(acpi, vmgenid_acpi_ids);
>> +#endif
>>
>> static struct platform_driver vmgenid_plaform_driver = {
>> .probe = vmgenid_add,
>> .driver = {
>> .name = "vmgenid",
>> - .acpi_match_table = ACPI_PTR(vmgenid_ids),
>> + .acpi_match_table = ACPI_PTR(vmgenid_acpi_ids),
>> +#if IS_ENABLED(CONFIG_OF)
>
> No, really, this is some ancient code.
>
> Please point me to single driver doing such ifdef.
>
>> + .of_match_table = vmgenid_of_ids,
>> +#endif
>> .owner = THIS_MODULE,
>
> This is clearly some abandoned driver... sigh... I thought we get rid of
> all this owner crap. Many years ago. How could it appear back if
> automated tools report it?
>
> Considering how many failures LKP reported for your patchsets, I have
> real doubts that anyone actually tests this code.
>
> Please confirm:
> Did you build W=1, run smatch, sparse and coccinelle on the driver after
> your changes?
>
> Best regards,
> Krzysztof
>
I built with W=1 but wasn't aware of the other tools. I will make sure
to run all the above before submitting any future patches.
^ permalink raw reply
* [PATCH net-next v6 05/17] net: pse-pd: Introduce PSE types enumeration
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Introduce an enumeration to define PSE types (C33 or PoDL),
utilizing a bitfield for potential future support of both types.
Include 'pse_get_types' helper for external access to PSE type info.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Rename PSE_POE to PSE_C33 to have naming consistency.
- Use "static inline" instead of simple static in the header
Changes in v3:
- Move the pse_type enum in uapi.
- Replace pse_get_types helper by pse_has_podl and pse_has_c33.
Changes in v5:
- Move the pse types enum in ethtool.
- Add ethtool prefix to the value.
Changes in v6:
- Fix a kdoc nit.
---
drivers/net/pse-pd/pse_core.c | 12 ++++++++++++
drivers/net/pse-pd/pse_regulator.c | 1 +
include/linux/pse-pd/pse.h | 15 +++++++++++++++
include/uapi/linux/ethtool.h | 12 ++++++++++++
4 files changed, 40 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 146b81f08a89..fed006cbc185 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -312,3 +312,15 @@ int pse_ethtool_set_config(struct pse_control *psec,
return err;
}
EXPORT_SYMBOL_GPL(pse_ethtool_set_config);
+
+bool pse_has_podl(struct pse_control *psec)
+{
+ return psec->pcdev->types & ETHTOOL_PSE_PODL;
+}
+EXPORT_SYMBOL_GPL(pse_has_podl);
+
+bool pse_has_c33(struct pse_control *psec)
+{
+ return psec->pcdev->types & ETHTOOL_PSE_C33;
+}
+EXPORT_SYMBOL_GPL(pse_has_c33);
diff --git a/drivers/net/pse-pd/pse_regulator.c b/drivers/net/pse-pd/pse_regulator.c
index 1dedf4de296e..547af384764b 100644
--- a/drivers/net/pse-pd/pse_regulator.c
+++ b/drivers/net/pse-pd/pse_regulator.c
@@ -116,6 +116,7 @@ pse_reg_probe(struct platform_device *pdev)
priv->pcdev.owner = THIS_MODULE;
priv->pcdev.ops = &pse_reg_ops;
priv->pcdev.dev = dev;
+ priv->pcdev.types = ETHTOOL_PSE_PODL;
ret = devm_pse_controller_register(dev, &priv->pcdev);
if (ret) {
dev_err(dev, "failed to register PSE controller (%pe)\n",
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index be4e5754eb24..19589571157f 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -77,6 +77,7 @@ struct pse_control;
* device tree to id as given to the PSE control ops
* @nr_lines: number of PSE controls in this controller device
* @lock: Mutex for serialization access to the PSE controller
+ * @types: types of the PSE controller
*/
struct pse_controller_dev {
const struct pse_controller_ops *ops;
@@ -89,6 +90,7 @@ struct pse_controller_dev {
const struct of_phandle_args *pse_spec);
unsigned int nr_lines;
struct mutex lock;
+ enum ethtool_pse_types types;
};
#if IS_ENABLED(CONFIG_PSE_CONTROLLER)
@@ -108,6 +110,9 @@ int pse_ethtool_set_config(struct pse_control *psec,
struct netlink_ext_ack *extack,
const struct pse_control_config *config);
+bool pse_has_podl(struct pse_control *psec);
+bool pse_has_c33(struct pse_control *psec);
+
#else
static inline struct pse_control *of_pse_control_get(struct device_node *node)
@@ -133,6 +138,16 @@ static inline int pse_ethtool_set_config(struct pse_control *psec,
return -ENOTSUPP;
}
+static inline bool pse_has_podl(struct pse_control *psec)
+{
+ return false;
+}
+
+static inline bool pse_has_c33(struct pse_control *psec)
+{
+ return false;
+}
+
#endif
#endif
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index b2f7906c7c5b..f920964e096a 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -752,6 +752,18 @@ enum ethtool_module_power_mode {
ETHTOOL_MODULE_POWER_MODE_HIGH,
};
+/**
+ * enum ethtool_pse_types - Types of PSE controller.
+ * @ETHTOOL_PSE_UNKNOWN: Type of PSE controller is unknown
+ * @ETHTOOL_PSE_PODL: PSE controller which support PoDL
+ * @ETHTOOL_PSE_C33: PSE controller which support Clause 33 (PoE)
+ */
+enum ethtool_pse_types {
+ ETHTOOL_PSE_UNKNOWN = 1 << 0,
+ ETHTOOL_PSE_PODL = 1 << 1,
+ ETHTOOL_PSE_C33 = 1 << 2,
+};
+
/**
* enum ethtool_c33_pse_admin_state - operational state of the PoDL PSE
* functions. IEEE 802.3-2022 30.9.1.1.2 aPSEAdminState
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 00/17] net: Add support for Power over Ethernet (PoE)
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5183 bytes --]
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
This patch series aims at adding support for PoE (Power over Ethernet),
based on the already existing support for PoDL (Power over Data Line)
implementation. In addition, it adds support for two specific PoE
controller, the Microchip PD692x0 and the TI TPS23881.
In detail:
- Patch 1 to 13 prepare net to support PoE devices.
- Patch 14 and 15 add PD692x0 PoE PSE controller driver and its binding.
- Patch 16 and 17 add TI TPS23881 PSE controller driver and its binding.
Changes in v6:
- TPS23881 fix firmware management release missing.
- Use pcdev device pointer as regulator consumer and provider.
- Rename of_legacy to no_of_pse_pi.
- Add kdoc, and separate functions for better readability.
- Add vpwr-supply regulator parent.
- Link to v5: https://lore.kernel.org/r/20240227-feature_poe-v5-0-28f0aa48246d@bootlin.com
Changes in v5:
- Fix bindings nit.
- Add supported-polarity parameter to bindings.
- Fix yamllint binding errors.
- Remove the nested lock brought by the use of regulator framework.
- Link to v4: https://lore.kernel.org/r/20240215-feature_poe-v4-0-35bb4c23266c@bootlin.com
Changes in v4:
- Replaced sponsored-by tag by a simple sentence.
- Fix pse_pi node bindings.
- Add pse pi documentation written by Oleksij.
- Link to v3: https://lore.kernel.org/r/20240208-feature_poe-v3-0-531d2674469e@bootlin.com
Changes in v3:
- Add patches to add Oleksij and myself to PSE MAINTAINERS.
- Add patches to add pse devlink.
- Add TI TPS23881 PSE controller driver with its binding.
- Replace pse_get_types helper by pse_has_podl and pse_has_c33
- Changed the PSE core bindings.
- Add a setup_pi_matrix callback.
- Register regulator for each PSE PI (Power Interface).
- Changed the PD692x0 bindings.
- Updated PD692x0 drivers to new bindings and PSE PI description.
- Updated PD692x0 drivers according to the reviews and made fixes.
- Link to v2: https://lore.kernel.org/r/20231201-feature_poe-v2-0-56d8cac607fa@bootlin.com
Changes in v2:
- Extract "firmware_loader: Expand Firmware upload error codes patches" to
send it alone and get it merge in an immutable branch.
- Add "c33" prefix for PoE variables and enums.
- Enhance few comments.
- Add PSE Documentation.
- Make several changes in pd692x0 driver, mainly for readibility.
- Link to v1: https://lore.kernel.org/r/20231116-feature_poe-v1-0-be48044bf249@bootlin.com
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Kory Maincent (17):
MAINTAINERS: net: Add Oleksij to pse-pd maintainers
of: property: Add fw_devlink support for pse parent
net: pse-pd: Rectify and adapt the naming of admin_cotrol member of struct pse_control_config
ethtool: Expand Ethernet Power Equipment with c33 (PoE) alongside PoDL
net: pse-pd: Introduce PSE types enumeration
net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface
netlink: specs: Modify pse attribute prefix
netlink: specs: Expand the pse netlink command with PoE interface
MAINTAINERS: Add myself to pse networking maintainer
net: pse-pd: Add support for PSE PIs
dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
net: pse-pd: Add support for setup_pi_matrix callback
net: pse-pd: Use regulator framework within PSE framework
dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller
net: pse-pd: Add PD692x0 PSE controller driver
dt-bindings: net: pse-pd: Add bindings for TPS23881 PSE controller
net: pse-pd: Add TI TPS23881 PSE controller driver
.../bindings/net/pse-pd/microchip,pd692x0.yaml | 158 +++
.../bindings/net/pse-pd/pse-controller.yaml | 102 +-
.../bindings/net/pse-pd/ti,tps23881.yaml | 93 ++
Documentation/netlink/specs/ethtool.yaml | 33 +-
Documentation/networking/ethtool-netlink.rst | 20 +
Documentation/networking/index.rst | 1 +
Documentation/networking/pse-pd/index.rst | 10 +
Documentation/networking/pse-pd/introduction.rst | 73 ++
Documentation/networking/pse-pd/pse-pi.rst | 302 +++++
MAINTAINERS | 8 +
drivers/net/pse-pd/Kconfig | 20 +
drivers/net/pse-pd/Makefile | 2 +
drivers/net/pse-pd/pd692x0.c | 1223 ++++++++++++++++++++
drivers/net/pse-pd/pse_core.c | 511 +++++++-
drivers/net/pse-pd/pse_regulator.c | 49 +-
drivers/net/pse-pd/tps23881.c | 818 +++++++++++++
drivers/of/property.c | 2 +
include/linux/pse-pd/pse.h | 86 +-
include/uapi/linux/ethtool.h | 55 +
include/uapi/linux/ethtool_netlink.h | 3 +
net/ethtool/pse-pd.c | 60 +-
21 files changed, 3527 insertions(+), 102 deletions(-)
---
base-commit: f81d6cec4a4ed1b6580340a43ec68f3132423964
change-id: 20231024-feature_poe-139490e73403
Best regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next v6 01/17] MAINTAINERS: net: Add Oleksij to pse-pd maintainers
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Oleksij was the first to add support for pse-pd net subsystem.
Add himself to the maintainers seems logical.
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f736af98d7b5..2ee2901581e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17765,6 +17765,13 @@ F: include/net/psample.h
F: include/uapi/linux/psample.h
F: net/psample
+PSE NETWORK DRIVER
+M: Oleksij Rempel <o.rempel@pengutronix.de>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/net/pse-pd/
+F: drivers/net/pse-pd/
+
PSTORE FILESYSTEM
M: Kees Cook <keescook@chromium.org>
R: Tony Luck <tony.luck@intel.com>
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 06/17] net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Add PSE PoE interface support in the ethtool pse command.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Follow the "c33" PoE prefix naming change.
Changes in v3:
- Replace the pse_get_types() helper by pse_has_podl() and pse_has_c33().
- Replace PoE to c33 in the netlink error log.
- Fix documentation build warning.
---
Documentation/networking/ethtool-netlink.rst | 20 ++++++++++
net/ethtool/pse-pd.c | 60 +++++++++++++++++++++++-----
2 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index d583d9abf2f8..294187c3a3b0 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -1717,6 +1717,10 @@ Kernel response contents:
PSE functions
``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` u32 power detection status of the
PoDL PSE.
+ ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` u32 Operational state of the PoE
+ PSE functions.
+ ``ETHTOOL_A_C33_PSE_PW_D_STATUS`` u32 power detection status of the
+ PoE PSE.
====================================== ====== =============================
When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` attribute identifies
@@ -1728,6 +1732,12 @@ aPoDLPSEAdminState. Possible values are:
.. kernel-doc:: include/uapi/linux/ethtool.h
:identifiers: ethtool_podl_pse_admin_state
+The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` implementing
+``IEEE 802.3-2022`` 30.9.1.1.2 aPSEAdminState.
+
+.. kernel-doc:: include/uapi/linux/ethtool.h
+ :identifiers: ethtool_c33_pse_admin_state
+
When set, the optional ``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` attribute identifies
the power detection status of the PoDL PSE. The status depend on internal PSE
state machine and automatic PD classification support. This option is
@@ -1737,6 +1747,12 @@ Possible values are:
.. kernel-doc:: include/uapi/linux/ethtool.h
:identifiers: ethtool_podl_pse_pw_d_status
+The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_PW_D_STATUS`` implementing
+``IEEE 802.3-2022`` 30.9.1.1.5 aPSEPowerDetectionStatus.
+
+.. kernel-doc:: include/uapi/linux/ethtool.h
+ :identifiers: ethtool_c33_pse_pw_d_status
+
PSE_SET
=======
@@ -1747,6 +1763,7 @@ Request contents:
====================================== ====== =============================
``ETHTOOL_A_PSE_HEADER`` nested request header
``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` u32 Control PoDL PSE Admin state
+ ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` u32 Control PSE Admin state
====================================== ====== =============================
When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used
@@ -1754,6 +1771,9 @@ to control PoDL PSE Admin functions. This option is implementing
``IEEE 802.3-2018`` 30.15.1.2.1 acPoDLPSEAdminControl. See
``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` for supported values.
+The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` implementing
+``IEEE 802.3-2022`` 30.9.1.2.1 acPSEAdminControl.
+
RSS_GET
=======
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index aef57a058f0d..a3bfc3d9644e 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -82,6 +82,10 @@ static int pse_reply_size(const struct ethnl_req_info *req_base,
len += nla_total_size(sizeof(u32)); /* _PODL_PSE_ADMIN_STATE */
if (st->podl_pw_status > 0)
len += nla_total_size(sizeof(u32)); /* _PODL_PSE_PW_D_STATUS */
+ if (st->c33_admin_state > 0)
+ len += nla_total_size(sizeof(u32)); /* _C33_PSE_ADMIN_STATE */
+ if (st->c33_pw_status > 0)
+ len += nla_total_size(sizeof(u32)); /* _C33_PSE_PW_D_STATUS */
return len;
}
@@ -103,6 +107,16 @@ static int pse_fill_reply(struct sk_buff *skb,
st->podl_pw_status))
return -EMSGSIZE;
+ if (st->c33_admin_state > 0 &&
+ nla_put_u32(skb, ETHTOOL_A_C33_PSE_ADMIN_STATE,
+ st->c33_admin_state))
+ return -EMSGSIZE;
+
+ if (st->c33_pw_status > 0 &&
+ nla_put_u32(skb, ETHTOOL_A_C33_PSE_PW_D_STATUS,
+ st->c33_pw_status))
+ return -EMSGSIZE;
+
return 0;
}
@@ -113,25 +127,18 @@ const struct nla_policy ethnl_pse_set_policy[ETHTOOL_A_PSE_MAX + 1] = {
[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL] =
NLA_POLICY_RANGE(NLA_U32, ETHTOOL_PODL_PSE_ADMIN_STATE_DISABLED,
ETHTOOL_PODL_PSE_ADMIN_STATE_ENABLED),
+ [ETHTOOL_A_C33_PSE_ADMIN_CONTROL] =
+ NLA_POLICY_RANGE(NLA_U32, ETHTOOL_C33_PSE_ADMIN_STATE_DISABLED,
+ ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED),
};
static int
ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
-{
- return !!info->attrs[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL];
-}
-
-static int
-ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
{
struct net_device *dev = req_info->dev;
- struct pse_control_config config = {};
struct nlattr **tb = info->attrs;
struct phy_device *phydev;
- /* this values are already validated by the ethnl_pse_set_policy */
- config.podl_admin_control = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
-
phydev = dev->phydev;
if (!phydev) {
NL_SET_ERR_MSG(info->extack, "No PHY is attached");
@@ -143,6 +150,39 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
return -EOPNOTSUPP;
}
+ if (tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL] &&
+ !(pse_has_podl(phydev->psec))) {
+ NL_SET_ERR_MSG_ATTR(info->extack,
+ tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL],
+ "setting PoDL PSE admin control not supported");
+ return -EOPNOTSUPP;
+ }
+ if (tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL] &&
+ !(pse_has_c33(phydev->psec))) {
+ NL_SET_ERR_MSG_ATTR(info->extack,
+ tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL],
+ "setting C33 PSE admin control not supported");
+ return -EOPNOTSUPP;
+ }
+
+ return 1;
+}
+
+static int
+ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
+{
+ struct net_device *dev = req_info->dev;
+ struct pse_control_config config = {};
+ struct nlattr **tb = info->attrs;
+ struct phy_device *phydev;
+
+ phydev = dev->phydev;
+ /* These values are already validated by the ethnl_pse_set_policy */
+ if (pse_has_podl(phydev->psec))
+ config.podl_admin_control = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
+ if (pse_has_c33(phydev->psec))
+ config.c33_admin_control = nla_get_u32(tb[ETHTOOL_A_C33_PSE_ADMIN_CONTROL]);
+
/* Return errno directly - PSE has no notification */
return pse_ethtool_set_config(phydev->psec, info->extack, &config);
}
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 02/17] of: property: Add fw_devlink support for pse parent
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
This allows fw_devlink to create device links between consumers of
a PSE and the supplier of the PSE.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch
---
drivers/of/property.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index a6358ee99b74..cc064151853e 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1252,6 +1252,7 @@ DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
DEFINE_SIMPLE_PROP(panel, "panel", NULL)
DEFINE_SIMPLE_PROP(msi_parent, "msi-parent", "#msi-cells")
DEFINE_SIMPLE_PROP(post_init_providers, "post-init-providers", NULL)
+DEFINE_SIMPLE_PROP(pses, "pses", "#pse-cells")
DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
@@ -1357,6 +1358,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
{ .parse_prop = parse_backlight, },
{ .parse_prop = parse_panel, },
{ .parse_prop = parse_msi_parent, },
+ { .parse_prop = parse_pses, },
{ .parse_prop = parse_gpio_compat, },
{ .parse_prop = parse_interrupts, },
{ .parse_prop = parse_regulators, },
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 07/17] netlink: specs: Modify pse attribute prefix
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Remove podl from the attribute prefix to prepare the support of PoE pse
netlink spec.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Add the ethtool auto generated code.
Changes in v3:
- Remove the ethtool auto generated code.
---
Documentation/netlink/specs/ethtool.yaml | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 197208f419dc..33e81fa189ca 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -878,17 +878,17 @@ attribute-sets:
type: nest
nested-attributes: header
-
- name: admin-state
+ name: podl-pse-admin-state
type: u32
- name-prefix: ethtool-a-podl-pse-
+ name-prefix: ethtool-a-
-
- name: admin-control
+ name: podl-pse-admin-control
type: u32
- name-prefix: ethtool-a-podl-pse-
+ name-prefix: ethtool-a-
-
- name: pw-d-status
+ name: podl-pse-pw-d-status
type: u32
- name-prefix: ethtool-a-podl-pse-
+ name-prefix: ethtool-a-
-
name: rss
attributes:
@@ -1571,9 +1571,9 @@ operations:
reply:
attributes: &pse
- header
- - admin-state
- - admin-control
- - pw-d-status
+ - podl-pse-admin-state
+ - podl-pse-admin-control
+ - podl-pse-pw-d-status
dump: *pse-get-op
-
name: pse-set
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 03/17] net: pse-pd: Rectify and adapt the naming of admin_cotrol member of struct pse_control_config
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
In commit 18ff0bcda6d1 ("ethtool: add interface to interact with Ethernet
Power Equipment"), the 'pse_control_config' structure was introduced,
housing a single member labeled 'admin_cotrol' responsible for maintaining
the operational state of the PoDL PSE functions.
A noticeable typographical error exists in the naming of this field
('cotrol' should be corrected to 'control'), which this commit aims to
rectify.
Furthermore, with upcoming extensions of this structure to encompass PoE
functionalities, the field is being renamed to 'podl_admin_state' to
distinctly indicate that this state is tailored specifically for PoDL."
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
drivers/net/pse-pd/pse_regulator.c | 8 ++++----
include/linux/pse-pd/pse.h | 4 ++--
net/ethtool/pse-pd.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/pse-pd/pse_regulator.c b/drivers/net/pse-pd/pse_regulator.c
index e2bf8306ca90..1dedf4de296e 100644
--- a/drivers/net/pse-pd/pse_regulator.c
+++ b/drivers/net/pse-pd/pse_regulator.c
@@ -31,10 +31,10 @@ pse_reg_ethtool_set_config(struct pse_controller_dev *pcdev, unsigned long id,
struct pse_reg_priv *priv = to_pse_reg(pcdev);
int ret;
- if (priv->admin_state == config->admin_cotrol)
+ if (priv->admin_state == config->podl_admin_control)
return 0;
- switch (config->admin_cotrol) {
+ switch (config->podl_admin_control) {
case ETHTOOL_PODL_PSE_ADMIN_STATE_ENABLED:
ret = regulator_enable(priv->ps);
break;
@@ -43,14 +43,14 @@ pse_reg_ethtool_set_config(struct pse_controller_dev *pcdev, unsigned long id,
break;
default:
dev_err(pcdev->dev, "Unknown admin state %i\n",
- config->admin_cotrol);
+ config->podl_admin_control);
ret = -ENOTSUPP;
}
if (ret)
return ret;
- priv->admin_state = config->admin_cotrol;
+ priv->admin_state = config->podl_admin_control;
return 0;
}
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index fb724c65c77b..199cf4ae3cf2 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -15,11 +15,11 @@ struct pse_controller_dev;
/**
* struct pse_control_config - PSE control/channel configuration.
*
- * @admin_cotrol: set PoDL PSE admin control as described in
+ * @podl_admin_control: set PoDL PSE admin control as described in
* IEEE 802.3-2018 30.15.1.2.1 acPoDLPSEAdminControl
*/
struct pse_control_config {
- enum ethtool_podl_pse_admin_state admin_cotrol;
+ enum ethtool_podl_pse_admin_state podl_admin_control;
};
/**
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index cc478af77111..aef57a058f0d 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -130,7 +130,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
struct phy_device *phydev;
/* this values are already validated by the ethnl_pse_set_policy */
- config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
+ config.podl_admin_control = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
phydev = dev->phydev;
if (!phydev) {
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 08/17] netlink: specs: Expand the pse netlink command with PoE interface
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Add the PoE pse attributes prefix to be able to use PoE interface.
Example usage:
./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-get \
--json '{"header":{"dev-name":"eth0"}}'
{'header': {'dev-index': 4, 'dev-name': 'eth0'},
'c33-pse-admin-state': 3,
'c33-pse-pw-d-status': 4}
./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-set \
--json '{"header":{"dev-name":"eth0"},
"c33-pse-admin-control":3}'
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Follow the "c33" PoE prefix naming change.
- Add the ethtool auto generated code.
Changes in v3:
- Remove the ethtool auto generated code.
---
Documentation/netlink/specs/ethtool.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 33e81fa189ca..beaab9f0017f 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -889,6 +889,18 @@ attribute-sets:
name: podl-pse-pw-d-status
type: u32
name-prefix: ethtool-a-
+ -
+ name: c33-pse-admin-state
+ type: u32
+ name-prefix: ethtool-a-
+ -
+ name: c33-pse-admin-control
+ type: u32
+ name-prefix: ethtool-a-
+ -
+ name: c33-pse-pw-d-status
+ type: u32
+ name-prefix: ethtool-a-
-
name: rss
attributes:
@@ -1574,6 +1586,9 @@ operations:
- podl-pse-admin-state
- podl-pse-admin-control
- podl-pse-pw-d-status
+ - c33-pse-admin-state
+ - c33-pse-admin-control
+ - c33-pse-pw-d-status
dump: *pse-get-op
-
name: pse-set
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 04/17] ethtool: Expand Ethernet Power Equipment with c33 (PoE) alongside PoDL
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
In the current PSE interface for Ethernet Power Equipment, support is
limited to PoDL. This patch extends the interface to accommodate the
objects specified in IEEE 802.3-2022 145.2 for Power sourcing
Equipment (PSE).
The following objects are now supported and considered mandatory:
- IEEE 802.3-2022 30.9.1.1.5 aPSEPowerDetectionStatus
- IEEE 802.3-2022 30.9.1.1.2 aPSEAdminState
- IEEE 802.3-2022 30.9.1.2.1 aPSEAdminControl
To avoid confusion between "PoDL PSE" and "PoE PSE", which have similar
names but distinct values, we have followed the suggestion of Oleksij
Rempel and Andrew Lunn to maintain separate naming schemes for each,
using c33 (clause 33) prefix for "PoE PSE".
You can find more details in the discussion threads here:
https://lore.kernel.org/netdev/20230912110637.GI780075@pengutronix.de/
https://lore.kernel.org/netdev/2539b109-72ad-470a-9dae-9f53de4f64ec@lunn.ch/
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Rename all the PoE variables and enum with a c33 prefix.
- Add documentation, thanks to Oleksij for having written one.
Changes in v3:
- Fix documentation build warning.
---
Documentation/networking/index.rst | 1 +
Documentation/networking/pse-pd/index.rst | 9 +++
Documentation/networking/pse-pd/introduction.rst | 73 ++++++++++++++++++++++++
include/linux/pse-pd/pse.h | 9 +++
include/uapi/linux/ethtool.h | 43 ++++++++++++++
include/uapi/linux/ethtool_netlink.h | 3 +
6 files changed, 138 insertions(+)
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 473d72c36d61..7664c0bfe461 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -93,6 +93,7 @@ Contents:
plip
ppp_generic
proc_net_tcp
+ pse-pd/index
radiotap-headers
rds
regulatory
diff --git a/Documentation/networking/pse-pd/index.rst b/Documentation/networking/pse-pd/index.rst
new file mode 100644
index 000000000000..18197bc7303d
--- /dev/null
+++ b/Documentation/networking/pse-pd/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Power Sourcing Equipment (PSE) Documentation
+============================================
+
+.. toctree::
+ :maxdepth: 2
+
+ introduction
diff --git a/Documentation/networking/pse-pd/introduction.rst b/Documentation/networking/pse-pd/introduction.rst
new file mode 100644
index 000000000000..e3d3faaef717
--- /dev/null
+++ b/Documentation/networking/pse-pd/introduction.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Power Sourcing Equipment (PSE) in IEEE 802.3 Standard
+=====================================================
+
+Overview
+--------
+
+Power Sourcing Equipment (PSE) is essential in networks for delivering power
+along with data over Ethernet cables. It usually refers to devices like
+switches and hubs that supply power to Powered Devices (PDs) such as IP
+cameras, VoIP phones, and wireless access points.
+
+PSE vs. PoDL PSE
+----------------
+
+PSE in the IEEE 802.3 standard generally refers to equipment that provides
+power alongside data over Ethernet cables, typically associated with Power over
+Ethernet (PoE).
+
+PoDL PSE, or Power over Data Lines PSE, specifically denotes PSEs operating
+with single balanced twisted-pair PHYs, as per Clause 104 of IEEE 802.3. PoDL
+is significant in contexts like automotive and industrial controls where power
+and data delivery over a single pair is advantageous.
+
+IEEE 802.3-2018 Addendums and Related Clauses
+---------------------------------------------
+
+Key addenda to the IEEE 802.3-2018 standard relevant to power delivery over
+Ethernet are as follows:
+
+- **802.3af (Approved in 2003-06-12)**: Known as PoE in the market, detailed in
+ Clause 33, delivering up to 15.4W of power.
+- **802.3at (Approved in 2009-09-11)**: Marketed as PoE+, enhancing PoE as
+ covered in Clause 33, increasing power delivery to up to 30W.
+- **802.3bt (Approved in 2018-09-27)**: Known as 4PPoE in the market, outlined
+ in Clause 33. Type 3 delivers up to 60W, and Type 4 up to 100W.
+- **802.3bu (Approved in 2016-12-07)**: Formerly referred to as PoDL, detailed
+ in Clause 104. Introduces Classes 0 - 9. Class 9 PoDL PSE delivers up to ~65W
+
+Kernel Naming Convention Recommendations
+----------------------------------------
+
+For clarity and consistency within the Linux kernel's networking subsystem, the
+following naming conventions are recommended:
+
+- For general PSE (PoE) code, use "c33_pse" key words. For example:
+ ``enum ethtool_c33_pse_admin_state c33_admin_control;``.
+ This aligns with Clause 33, encompassing various PoE forms.
+
+- For PoDL PSE - specific code, use "podl_pse". For example:
+ ``enum ethtool_podl_pse_admin_state podl_admin_control;`` to differentiate
+ PoDL PSE settings according to Clause 104.
+
+Summary of Clause 33: Data Terminal Equipment (DTE) Power via Media Dependent Interface (MDI)
+---------------------------------------------------------------------------------------------
+
+Clause 33 of the IEEE 802.3 standard defines the functional and electrical
+characteristics of Powered Device (PD) and Power Sourcing Equipment (PSE).
+These entities enable power delivery using the same generic cabling as for data
+transmission, integrating power with data communication for devices such as
+10BASE-T, 100BASE-TX, or 1000BASE-T.
+
+Summary of Clause 104: Power over Data Lines (PoDL) of Single Balanced Twisted-Pair Ethernet
+--------------------------------------------------------------------------------------------
+
+Clause 104 of the IEEE 802.3 standard delineates the functional and electrical
+characteristics of PoDL Powered Devices (PDs) and PoDL Power Sourcing Equipment
+(PSEs). These are designed for use with single balanced twisted-pair Ethernet
+Physical Layers. In this clause, 'PSE' refers specifically to PoDL PSE, and
+'PD' to PoDL PD. The key intent is to provide devices with a unified interface
+for both data and the power required to process this data over a single
+balanced twisted-pair Ethernet connection.
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 199cf4ae3cf2..be4e5754eb24 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -17,9 +17,12 @@ struct pse_controller_dev;
*
* @podl_admin_control: set PoDL PSE admin control as described in
* IEEE 802.3-2018 30.15.1.2.1 acPoDLPSEAdminControl
+ * @c33_admin_control: set PSE admin control as described in
+ * IEEE 802.3-2022 30.9.1.2.1 acPSEAdminControl
*/
struct pse_control_config {
enum ethtool_podl_pse_admin_state podl_admin_control;
+ enum ethtool_c33_pse_admin_state c33_admin_control;
};
/**
@@ -29,10 +32,16 @@ struct pse_control_config {
* functions. IEEE 802.3-2018 30.15.1.1.2 aPoDLPSEAdminState
* @podl_pw_status: power detection status of the PoDL PSE.
* IEEE 802.3-2018 30.15.1.1.3 aPoDLPSEPowerDetectionStatus:
+ * @c33_admin_state: operational state of the PSE
+ * functions. IEEE 802.3-2022 30.9.1.1.2 aPSEAdminState
+ * @c33_pw_status: power detection status of the PSE.
+ * IEEE 802.3-2022 30.9.1.1.5 aPSEPowerDetectionStatus:
*/
struct pse_control_status {
enum ethtool_podl_pse_admin_state podl_admin_state;
enum ethtool_podl_pse_pw_d_status podl_pw_status;
+ enum ethtool_c33_pse_admin_state c33_admin_state;
+ enum ethtool_c33_pse_pw_d_status c33_pw_status;
};
/**
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 11fc18988bc2..b2f7906c7c5b 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -752,6 +752,49 @@ enum ethtool_module_power_mode {
ETHTOOL_MODULE_POWER_MODE_HIGH,
};
+/**
+ * enum ethtool_c33_pse_admin_state - operational state of the PoDL PSE
+ * functions. IEEE 802.3-2022 30.9.1.1.2 aPSEAdminState
+ * @ETHTOOL_C33_PSE_ADMIN_STATE_UNKNOWN: state of PSE functions is unknown
+ * @ETHTOOL_C33_PSE_ADMIN_STATE_DISABLED: PSE functions are disabled
+ * @ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED: PSE functions are enabled
+ */
+enum ethtool_c33_pse_admin_state {
+ ETHTOOL_C33_PSE_ADMIN_STATE_UNKNOWN = 1,
+ ETHTOOL_C33_PSE_ADMIN_STATE_DISABLED,
+ ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED,
+};
+
+/**
+ * enum ethtool_c33_pse_pw_d_status - power detection status of the PSE.
+ * IEEE 802.3-2022 30.9.1.1.3 aPoDLPSEPowerDetectionStatus:
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_UNKNOWN: PSE status is unknown
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_DISABLED: "The enumeration \u201cdisabled\u201d
+ * indicates that the PSE State diagram is in the state DISABLED."
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_SEARCHING: "The enumeration \u201csearching\u201d
+ * indicates the PSE State diagram is in a state other than those
+ * listed."
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_DELIVERING: "The enumeration
+ * \u201cdeliveringPower\u201d indicates that the PSE State diagram is in the
+ * state POWER_ON."
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_TEST: "The enumeration \u201ctest\u201d indicates that
+ * the PSE State diagram is in the state TEST_MODE."
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_FAULT: "The enumeration \u201cfault\u201d indicates that
+ * the PSE State diagram is in the state TEST_ERROR."
+ * @ETHTOOL_C33_PSE_PW_D_STATUS_OTHERFAULT: "The enumeration \u201cotherFault\u201d
+ * indicates that the PSE State diagram is in the state IDLE due to
+ * the variable error_condition = true."
+ */
+enum ethtool_c33_pse_pw_d_status {
+ ETHTOOL_C33_PSE_PW_D_STATUS_UNKNOWN = 1,
+ ETHTOOL_C33_PSE_PW_D_STATUS_DISABLED,
+ ETHTOOL_C33_PSE_PW_D_STATUS_SEARCHING,
+ ETHTOOL_C33_PSE_PW_D_STATUS_DELIVERING,
+ ETHTOOL_C33_PSE_PW_D_STATUS_TEST,
+ ETHTOOL_C33_PSE_PW_D_STATUS_FAULT,
+ ETHTOOL_C33_PSE_PW_D_STATUS_OTHERFAULT,
+};
+
/**
* enum ethtool_podl_pse_admin_state - operational state of the PoDL PSE
* functions. IEEE 802.3-2018 30.15.1.1.2 aPoDLPSEAdminState
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 3f89074aa06c..3f32d360beb1 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -895,6 +895,9 @@ enum {
ETHTOOL_A_PODL_PSE_ADMIN_STATE, /* u32 */
ETHTOOL_A_PODL_PSE_ADMIN_CONTROL, /* u32 */
ETHTOOL_A_PODL_PSE_PW_D_STATUS, /* u32 */
+ ETHTOOL_A_C33_PSE_ADMIN_STATE, /* u32 */
+ ETHTOOL_A_C33_PSE_ADMIN_CONTROL, /* u32 */
+ ETHTOOL_A_C33_PSE_PW_D_STATUS, /* u32 */
/* add new constants above here */
__ETHTOOL_A_PSE_CNT,
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 09/17] MAINTAINERS: Add myself to pse networking maintainer
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
As I add support for PoE in PSE networking subsystem it seems legitimate
to be added to the maintainers.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ee2901581e1..e1180f6ae601 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17767,6 +17767,7 @@ F: net/psample
PSE NETWORK DRIVER
M: Oleksij Rempel <o.rempel@pengutronix.de>
+M: Kory Maincent <kory.maincent@bootlin.com>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/pse-pd/
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 27730 bytes --]
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
The Power Sourcing Equipment Power Interface (PSE PI) plays a pivotal role
in the architecture of Power over Ethernet (PoE) systems. It is essentially
a blueprint that outlines how one or multiple power sources are connected
to the eight-pin modular jack, commonly known as the Ethernet RJ45 port.
This connection scheme is crucial for enabling the delivery of power
alongside data over Ethernet cables.
This patch adds support for getting the PSE controller node through PSE PI
device subnode.
This supports adds a way to get the PSE PI id from the pse_pi devicetree
subnode of a PSE controller node simply by reading the reg property.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch.
Changes in v4:
- Add PSE PI documentation.
Changes in v5:
- Update PSE PI documentation.
Changes in v6:
- Add error messages.
- Add kdoc.
- Rename of_legacy to no_of_pse_pi.
- Create new function for readibility.
- Fix few nit.
---
Documentation/networking/pse-pd/index.rst | 1 +
Documentation/networking/pse-pd/pse-pi.rst | 302 +++++++++++++++++++++++++++++
drivers/net/pse-pd/pse_core.c | 256 ++++++++++++++++++++----
include/linux/pse-pd/pse.h | 38 +++-
4 files changed, 558 insertions(+), 39 deletions(-)
diff --git a/Documentation/networking/pse-pd/index.rst b/Documentation/networking/pse-pd/index.rst
index 18197bc7303d..de28a5aee316 100644
--- a/Documentation/networking/pse-pd/index.rst
+++ b/Documentation/networking/pse-pd/index.rst
@@ -7,3 +7,4 @@ Power Sourcing Equipment (PSE) Documentation
:maxdepth: 2
introduction
+ pse-pi
diff --git a/Documentation/networking/pse-pd/pse-pi.rst b/Documentation/networking/pse-pd/pse-pi.rst
new file mode 100644
index 000000000000..c4a50c670d9c
--- /dev/null
+++ b/Documentation/networking/pse-pd/pse-pi.rst
@@ -0,0 +1,302 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+PSE Power Interface (PSE PI) Documentation
+==========================================
+
+The Power Sourcing Equipment Power Interface (PSE PI) plays a pivotal role in
+the architecture of Power over Ethernet (PoE) systems. It is essentially a
+blueprint that outlines how one or multiple power sources are connected to the
+eight-pin modular jack, commonly known as the Ethernet RJ45 port. This
+connection scheme is crucial for enabling the delivery of power alongside data
+over Ethernet cables.
+
+Documentation and Standards
+---------------------------
+
+The IEEE 802.3 standard provides detailed documentation on the PSE PI.
+Specifically:
+
+- Section "33.2.3 PI pin assignments" covers the pin assignments for PoE
+ systems that utilize two pairs for power delivery.
+- Section "145.2.4 PSE PI" addresses the configuration for PoE systems that
+ deliver power over all four pairs of an Ethernet cable.
+
+PSE PI and Single Pair Ethernet
+-------------------------------
+
+Single Pair Ethernet (SPE) represents a different approach to Ethernet
+connectivity, utilizing just one pair of conductors for both data and power
+transmission. Unlike the configurations detailed in the PSE PI for standard
+Ethernet, which can involve multiple power sourcing arrangements across four or
+two pairs of wires, SPE operates on a simpler model due to its single-pair
+design. As a result, the complexities of choosing between alternative pin
+assignments for power delivery, as described in the PSE PI for multi-pair
+Ethernet, are not applicable to SPE.
+
+Understanding PSE PI
+--------------------
+
+The Power Sourcing Equipment Power Interface (PSE PI) is a framework defining
+how Power Sourcing Equipment (PSE) delivers power to Powered Devices (PDs) over
+Ethernet cables. It details two main configurations for power delivery, known
+as Alternative A and Alternative B, which are distinguished not only by their
+method of power transmission but also by the implications for polarity and data
+transmission direction.
+
+Alternative A and B Overview
+----------------------------
+
+- **Alternative A:** Utilizes RJ45 conductors 1, 2, 3 and 6. In either case of
+ networks 10/100BaseT or 1G/2G/5G/10GBaseT, the pairs used are carrying data.
+ The power delivery's polarity in this alternative can vary based on the MDI
+ (Medium Dependent Interface) or MDI-X (Medium Dependent Interface Crossover)
+ configuration.
+
+- **Alternative B:** Utilizes RJ45 conductors 4, 5, 7 and 8. In case of
+ 10/100BaseT network the pairs used are spare pairs without data and are less
+ influenced by data transmission direction. This is not the case for
+ 1G/2G/5G/10GBaseT network. Alternative B includes two configurations with
+ different polarities, known as variant X and variant S, to accommodate
+ different network requirements and device specifications.
+
+Table 145\u20133\u2014PSE Pinout Alternatives
+-----------------------------------
+
+The following table outlines the pin configurations for both Alternative A and
+Alternative B.
+
++------------+-------------------+-----------------+-----------------+-----------------+
+| Conductor | Alternative A | Alternative A | Alternative B | Alternative B |
+| | (MDI-X) | (MDI) | (X) | (S) |
++============+===================+=================+=================+=================+
+| 1 | Negative V | Positive V | - | - |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 2 | Negative V | Positive V | - | - |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 3 | Positive V | Negative V | - | - |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 4 | - | - | Negative V | Positive V |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 5 | - | - | Negative V | Positive V |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 6 | Positive V | Negative V | - | - |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 7 | - | - | Positive V | Negative V |
++------------+-------------------+-----------------+-----------------+-----------------+
+| 8 | - | - | Positive V | Negative V |
++------------+-------------------+-----------------+-----------------+-----------------+
+
+.. note::
+ - "Positive V" and "Negative V" indicate the voltage polarity for each pin.
+ - "-" indicates that the pin is not used for power delivery in that
+ specific configuration.
+
+PSE PI compatibilities
+----------------------
+
+The following table outlines the compatibility between the pinout alternative
+and the 1000/2.5G/5G/10GBaseT in the PSE 2 pairs connection.
+
++---------+---------------+---------------------+-----------------------+
+| Variant | Alternative | Power Feeding Type | Compatibility with |
+| | (A/B) | (Direct/Phantom) | 1000/2.5G/5G/10GBaseT |
++=========+===============+=====================+=======================+
+| 1 | A | Phantom | Yes |
++---------+---------------+---------------------+-----------------------+
+| 2 | B | Phantom | Yes |
++---------+---------------+---------------------+-----------------------+
+| 3 | B | Direct | No |
++---------+---------------+---------------------+-----------------------+
+
+.. note::
+ - "Direct" indicate a variant where the power is injected directly to pairs
+ without using magnetics in case of spare pairs.
+ - "Phantom" indicate power path over coils/magnetics as it is done for
+ Alternative A variant.
+
+In case of PSE 4 pairs, a PSE supporting only 10/100BaseT (which mean Direct
+Power on pinout Alternative B) is not compatible with a 4 pairs
+1000/2.5G/5G/10GBaseT.
+
+PSE Power Interface (PSE PI) Connection Diagram
+-----------------------------------------------
+
+The diagram below illustrates the connection architecture between the RJ45
+port, the Ethernet PHY (Physical Layer), and the PSE PI (Power Sourcing
+Equipment Power Interface), demonstrating how power and data are delivered
+simultaneously through an Ethernet cable. The RJ45 port serves as the physical
+interface for these connections, with each of its eight pins connected to both
+the Ethernet PHY for data transmission and the PSE PI for power delivery.
+
+.. code-block::
+
+ +--------------------------+
+ | |
+ | RJ45 Port |
+ | |
+ +--+--+--+--+--+--+--+--+--+ +-------------+
+ 1| 2| 3| 4| 5| 6| 7| 8| | |
+ | | | | | | | o-------------------+ |
+ | | | | | | o--|-------------------+ +<--- PSE 1
+ | | | | | o--|--|-------------------+ |
+ | | | | o--|--|--|-------------------+ |
+ | | | o--|--|--|--|-------------------+ PSE PI |
+ | | o--|--|--|--|--|-------------------+ |
+ | o--|--|--|--|--|--|-------------------+ +<--- PSE 2 (optional)
+ o--|--|--|--|--|--|--|-------------------+ |
+ | | | | | | | | | |
+ +--+--+--+--+--+--+--+--+--+ +-------------+
+ | |
+ | Ethernet PHY |
+ | |
+ +--------------------------+
+
+Simple PSE PI Configuration for Alternative A
+---------------------------------------------
+
+The diagram below illustrates a straightforward PSE PI (Power Sourcing
+Equipment Power Interface) configuration designed to support the Alternative A
+setup for Power over Ethernet (PoE). This implementation is tailored to provide
+power delivery through the data-carrying pairs of an Ethernet cable, suitable
+for either MDI or MDI-X configurations, albeit supporting one variation at a
+time.
+
+.. code-block::
+
+ +-------------+
+ | PSE PI |
+ 8 -----+ +-------------+
+ 7 -----+ Rail 1 |
+ 6 -----+------+----------------------+
+ 5 -----+ | |
+ 4 -----+ / Rail 2 | PSE 1
+ 3 -----+----´ +-------------+
+ 2 -----+----+---------´ |
+ 1 -----+---´ +-------------+
+ |
+ +-------------+
+
+In this configuration:
+
+- Pins 1 and 2, as well as pins 3 and 6, are utilized for power delivery in
+ addition to data transmission. This aligns with the standard wiring for
+ 10/100BaseT Ethernet networks where these pairs are used for data.
+- Rail 1 and Rail 2 represent the positive and negative voltage rails, with
+ Rail 1 connected to pins 1 and 2, and Rail 2 connected to pins 3 and 6.
+ More advanced PSE PI configurations may include integrated or external
+ switches to change the polarity of the voltage rails, allowing for
+ compatibility with both MDI and MDI-X configurations.
+
+More complex PSE PI configurations may include additional components, to support
+Alternative B, or to provide additional features such as power management, or
+additional power delivery capabilities such as 2-pair or 4-pair power delivery.
+
+.. code-block::
+
+ +-------------+
+ | PSE PI |
+ | +---+
+ 8 -----+--------+ | +-------------+
+ 7 -----+--------+ | Rail 1 |
+ 6 -----+--------+ +-----------------+
+ 5 -----+--------+ | |
+ 4 -----+--------+ | Rail 2 | PSE 1
+ 3 -----+--------+ +----------------+
+ 2 -----+--------+ | |
+ 1 -----+--------+ | +-------------+
+ | +---+
+ +-------------+
+
+Device Tree Configuration: Describing PSE PI Configurations
+-----------------------------------------------------------
+
+The necessity for a separate PSE PI node in the device tree is influenced by
+the intricacy of the Power over Ethernet (PoE) system's setup. Here are
+descriptions of both simple and complex PSE PI configurations to illustrate
+this decision-making process:
+
+**Simple PSE PI Configuration:**
+In a straightforward scenario, the PSE PI setup involves a direct, one-to-one
+connection between a single PSE controller and an Ethernet port. This setup
+typically supports basic PoE functionality without the need for dynamic
+configuration or management of multiple power delivery modes. For such simple
+configurations, detailing the PSE PI within the existing PSE controller's node
+may suffice, as the system does not encompass additional complexity that
+warrants a separate node. The primary focus here is on the clear and direct
+association of power delivery to a specific Ethernet port.
+
+**Complex PSE PI Configuration:**
+Contrastingly, a complex PSE PI setup may encompass multiple PSE controllers or
+auxiliary circuits that collectively manage power delivery to one Ethernet
+port. Such configurations might support a range of PoE standards and require
+the capability to dynamically configure power delivery based on the operational
+mode (e.g., PoE2 versus PoE4) or specific requirements of connected devices. In
+these instances, a dedicated PSE PI node becomes essential for accurately
+documenting the system architecture. This node would serve to detail the
+interactions between different PSE controllers, the support for various PoE
+modes, and any additional logic required to coordinate power delivery across
+the network infrastructure.
+
+**Guidance:**
+
+For simple PSE setups, including PSE PI information in the PSE controller node
+might suffice due to the straightforward nature of these systems. However,
+complex configurations, involving multiple components or advanced PoE features,
+benefit from a dedicated PSE PI node. This method adheres to IEEE 802.3
+specifications, improving documentation clarity and ensuring accurate
+representation of the PoE system's complexity.
+
+PSE PI Node: Essential Information
+----------------------------------
+
+The PSE PI (Power Sourcing Equipment Power Interface) node in a device tree can
+include several key pieces of information critical for defining the power
+delivery capabilities and configurations of a PoE (Power over Ethernet) system.
+Below is a list of such information, along with explanations for their
+necessity and reasons why they might not be found within a PSE controller node:
+
+1. **Powered Pairs Configuration**
+
+ - *Description:* Identifies the pairs used for power delivery in the
+ Ethernet cable.
+ - *Necessity:* Essential to ensure the correct pairs are powered according
+ to the board's design.
+ - *PSE Controller Node:* Typically lacks details on physical pair usage,
+ focusing on power regulation.
+
+2. **Polarity of Powered Pairs**
+
+ - *Description:* Specifies the polarity (positive or negative) for each
+ powered pair.
+ - *Necessity:* Critical for safe and effective power transmission to PDs.
+ - *PSE Controller Node:* Polarity management may exceed the standard
+ functionalities of PSE controllers.
+
+3. **PSE Cells Association**
+
+ - *Description:* Details the association of PSE cells with Ethernet ports or
+ pairs in multi-cell configurations.
+ - *Necessity:* Allows for optimized power resource allocation in complex
+ systems.
+ - *PSE Controller Node:* Controllers may not manage cell associations
+ directly, focusing instead on power flow regulation.
+
+4. **Support for PoE Standards**
+
+ - *Description:* Lists the PoE standards and configurations supported by the
+ system.
+ - *Necessity:* Ensures system compatibility with various PDs and adherence
+ to industry standards.
+ - *PSE Controller Node:* Specific capabilities may depend on the overall PSE
+ PI design rather than the controller alone. Multiple PSE cells per PI
+ do not necessarily imply support for multiple PoE standards.
+
+5. **Protection Mechanisms**
+
+ - *Description:* Outlines additional protection mechanisms, such as
+ overcurrent protection and thermal management.
+ - *Necessity:* Provides extra safety and stability, complementing PSE
+ controller protections.
+ - *PSE Controller Node:* Some protections may be implemented via
+ board-specific hardware or algorithms external to the controller.
+
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index fed006cbc185..5d1bf197c067 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -27,38 +27,174 @@ struct pse_control {
struct kref refcnt;
};
+static int of_load_single_pse_pi_pairset(struct device_node *node,
+ struct pse_pi *pi,
+ int pairset_num)
+{
+ struct device_node *pairset_np;
+ const char *name;
+ int ret;
+
+ ret = of_property_read_string_index(node, "pairset-names",
+ pairset_num, &name);
+ if (ret)
+ return ret;
+
+ if (!strcmp(name, "alternative-a")) {
+ pi->pairset[pairset_num].pinout = ALTERNATIVE_A;
+ } else if (!strcmp(name, "alternative-b")) {
+ pi->pairset[pairset_num].pinout = ALTERNATIVE_B;
+ } else {
+ pr_err("pse: wrong pairset-names value %s\n", name);
+ return -EINVAL;
+ }
+
+ pairset_np = of_parse_phandle(node, "pairsets", pairset_num);
+ if (!pairset_np)
+ return -ENODEV;
+
+ pi->pairset[pairset_num].np = pairset_np;
+
+ return 0;
+}
+
/**
- * of_pse_zero_xlate - dummy function for controllers with one only control
- * @pcdev: a pointer to the PSE controller device
- * @pse_spec: PSE line specifier as found in the device tree
- *
- * This static translation function is used by default if of_xlate in
- * :c:type:`pse_controller_dev` is not set. It is useful for all PSE
- * controllers with #pse-cells = <0>.
+ * of_load_pse_pi_pairset - load PSE PI pairsets pinout and polarity
+ * @node: a pointer of the device node
+ * @pi: a pointer of the PSE PI to fill
+ * @npairsets: the number of pairsets (1 or 2) used by the PI
*/
-static int of_pse_zero_xlate(struct pse_controller_dev *pcdev,
- const struct of_phandle_args *pse_spec)
+static int of_load_pse_pi_pairsets(struct device_node *node,
+ struct pse_pi *pi,
+ int npairsets)
{
- return 0;
+ int i, ret;
+
+ ret = of_property_count_strings(node, "pairset-names");
+ if (ret != npairsets) {
+ pr_err("pse: amount of pairsets and pairset-names is not equal %d != %d\n",
+ npairsets, ret);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < npairsets; i++) {
+ ret = of_load_single_pse_pi_pairset(node, pi, i);
+ if (ret)
+ goto out;
+ }
+
+ if (npairsets == 2 &&
+ pi->pairset[0].pinout == pi->pairset[1].pinout) {
+ pr_err("pse: two PI pairsets can not have identical pinout");
+ ret = -EINVAL;
+ }
+
+out:
+ /* If an error appears, release all the pairset device node kref */
+ if (ret) {
+ of_node_put(pi->pairset[0].np);
+ pi->pairset[0].np = NULL;
+ of_node_put(pi->pairset[1].np);
+ pi->pairset[1].np = NULL;
+ }
+
+ return ret;
+}
+
+static void pse_release_pis(struct pse_controller_dev *pcdev)
+{
+ int i;
+
+ for (i = 0; i <= pcdev->nr_lines; i++) {
+ of_node_put(pcdev->pi[i].pairset[0].np);
+ of_node_put(pcdev->pi[i].pairset[1].np);
+ of_node_put(pcdev->pi[i].np);
+ }
+ kfree(pcdev->pi);
}
/**
- * of_pse_simple_xlate - translate pse_spec to the PSE line number
+ * of_load_pse_pis - load all the PSE PIs
* @pcdev: a pointer to the PSE controller device
- * @pse_spec: PSE line specifier as found in the device tree
- *
- * This static translation function is used by default if of_xlate in
- * :c:type:`pse_controller_dev` is not set. It is useful for all PSE
- * controllers with 1:1 mapping, where PSE lines can be indexed by number
- * without gaps.
*/
-static int of_pse_simple_xlate(struct pse_controller_dev *pcdev,
- const struct of_phandle_args *pse_spec)
+static int of_load_pse_pis(struct pse_controller_dev *pcdev)
{
- if (pse_spec->args[0] >= pcdev->nr_lines)
- return -EINVAL;
+ struct device_node *np = pcdev->dev->of_node;
+ struct device_node *node, *pis;
+ int ret;
- return pse_spec->args[0];
+ if (!np)
+ return -ENODEV;
+
+ pis = of_get_child_by_name(np, "pse-pis");
+ if (!pis) {
+ /* no description of PSE PIs */
+ pcdev->no_of_pse_pi = true;
+ return 0;
+ }
+
+ pcdev->pi = kcalloc(pcdev->nr_lines, sizeof(*pcdev->pi), GFP_KERNEL);
+ if (!pcdev->pi)
+ return -ENOMEM;
+
+ for_each_child_of_node(pis, node) {
+ struct pse_pi pi = {0};
+ u32 id;
+
+ if (!of_node_name_eq(node, "pse-pi"))
+ continue;
+
+ ret = of_property_read_u32(node, "reg", &id);
+ if (ret) {
+ dev_err(pcdev->dev,
+ "can't get reg property for node '%pOF'",
+ node);
+ goto out;
+ }
+
+ if (id >= pcdev->nr_lines) {
+ dev_err(pcdev->dev,
+ "reg value (%u) is out of range (%u).\n",
+ id, pcdev->nr_lines);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (pcdev->pi[id].np) {
+ dev_err(pcdev->dev,
+ "other node with same reg value was already registered. %pOF : %pOF\n",
+ pcdev->pi[id].np, node);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = of_count_phandle_with_args(node, "pairsets", NULL);
+ /* npairsets is limited to value one or two */
+ if (ret == 1 || ret == 2) {
+ ret = of_load_pse_pi_pairsets(node, &pi, ret);
+ if (ret)
+ goto out;
+ } else if (ret != ENOENT) {
+ dev_err(pcdev->dev,
+ "error: wrong number of pairsets. Should be 1 or 2, got %d\n",
+ ret);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ of_node_get(node);
+ pi.np = node;
+ memcpy(&pcdev->pi[id], &pi, sizeof(pi));
+ }
+
+ of_node_put(pis);
+ return 0;
+
+out:
+ pse_release_pis(pcdev);
+ of_node_put(node);
+ of_node_put(pis);
+ return ret;
}
/**
@@ -67,16 +203,18 @@ static int of_pse_simple_xlate(struct pse_controller_dev *pcdev,
*/
int pse_controller_register(struct pse_controller_dev *pcdev)
{
- if (!pcdev->of_xlate) {
- if (pcdev->of_pse_n_cells == 0)
- pcdev->of_xlate = of_pse_zero_xlate;
- else if (pcdev->of_pse_n_cells == 1)
- pcdev->of_xlate = of_pse_simple_xlate;
- }
+ int ret;
mutex_init(&pcdev->lock);
INIT_LIST_HEAD(&pcdev->pse_control_head);
+ if (!pcdev->nr_lines)
+ pcdev->nr_lines = 1;
+
+ ret = of_load_pse_pis(pcdev);
+ if (ret)
+ return ret;
+
mutex_lock(&pse_list_mutex);
list_add(&pcdev->list, &pse_controller_list);
mutex_unlock(&pse_list_mutex);
@@ -91,6 +229,7 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
*/
void pse_controller_unregister(struct pse_controller_dev *pcdev)
{
+ pse_release_pis(pcdev);
mutex_lock(&pse_list_mutex);
list_del(&pcdev->list);
mutex_unlock(&pse_list_mutex);
@@ -203,8 +342,46 @@ pse_control_get_internal(struct pse_controller_dev *pcdev, unsigned int index)
return psec;
}
-struct pse_control *
-of_pse_control_get(struct device_node *node)
+/**
+ * of_pse_match_pi - Return the PSE PI id of the device node phandle
+ * @pcdev: a pointer to the PSE controller device
+ * @np: a pointer to the device node
+ */
+static int of_pse_match_pi(struct pse_controller_dev *pcdev,
+ struct device_node *np)
+{
+ int i;
+
+ for (i = 0; i <= pcdev->nr_lines; i++) {
+ if (pcdev->pi[i].np == np)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * psec_id_xlate - translate pse_spec to the PSE line number according
+ * to the number of pse-cells in case of no pse_pi node
+ * @pcdev: a pointer to the PSE controller device
+ * @pse_spec: PSE line specifier as found in the device tree
+ *
+ * Return 0 if #pse-cells = <0>. Return PSE line number otherwise.
+ */
+static int psec_id_xlate(struct pse_controller_dev *pcdev,
+ const struct of_phandle_args *pse_spec)
+{
+ if (!pcdev->of_pse_n_cells)
+ return 0;
+
+ if (pcdev->of_pse_n_cells > 1 ||
+ pse_spec->args[0] >= pcdev->nr_lines)
+ return -EINVAL;
+
+ return pse_spec->args[0];
+}
+
+struct pse_control *of_pse_control_get(struct device_node *node)
{
struct pse_controller_dev *r, *pcdev;
struct of_phandle_args args;
@@ -222,7 +399,14 @@ of_pse_control_get(struct device_node *node)
mutex_lock(&pse_list_mutex);
pcdev = NULL;
list_for_each_entry(r, &pse_controller_list, list) {
- if (args.np == r->dev->of_node) {
+ if (!r->no_of_pse_pi) {
+ ret = of_pse_match_pi(r, args.np);
+ if (ret >= 0) {
+ pcdev = r;
+ psec_id = ret;
+ break;
+ }
+ } else if (args.np == r->dev->of_node) {
pcdev = r;
break;
}
@@ -238,10 +422,12 @@ of_pse_control_get(struct device_node *node)
goto out;
}
- psec_id = pcdev->of_xlate(pcdev, &args);
- if (psec_id < 0) {
- psec = ERR_PTR(psec_id);
- goto out;
+ if (pcdev->no_of_pse_pi) {
+ psec_id = psec_id_xlate(pcdev, &args);
+ if (psec_id < 0) {
+ psec = ERR_PTR(psec_id);
+ goto out;
+ }
}
/* pse_list_mutex also protects the pcdev's pse_control list */
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 19589571157f..e7ac48ef9f95 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -64,6 +64,36 @@ struct device_node;
struct of_phandle_args;
struct pse_control;
+/* PSE PI pairset pinout can either be Alternative A or Alternative B */
+enum pse_pi_pairset_pinout {
+ ALTERNATIVE_A,
+ ALTERNATIVE_B,
+};
+
+/**
+ * struct pse_pi_pairset - PSE PI pairset entity describing the pinout
+ * alternative ant its phandle
+ *
+ * @pinout: description of the pinout alternative
+ * @np: device node pointer describing the pairset phandle
+ */
+struct pse_pi_pairset {
+ enum pse_pi_pairset_pinout pinout;
+ struct device_node *np;
+};
+
+/**
+ * struct pse_pi - PSE PI (Power Interface) entity as described in
+ * IEEE 802.3-2022 145.2.4
+ *
+ * @pairset: table of the PSE PI pinout alternative for the two pairset
+ * @np: device node pointer of the PSE PI node
+ */
+struct pse_pi {
+ struct pse_pi_pairset pairset[2];
+ struct device_node *np;
+};
+
/**
* struct pse_controller_dev - PSE controller entity that might
* provide multiple PSE controls
@@ -73,11 +103,11 @@ struct pse_control;
* @pse_control_head: head of internal list of requested PSE controls
* @dev: corresponding driver model device struct
* @of_pse_n_cells: number of cells in PSE line specifiers
- * @of_xlate: translation function to translate from specifier as found in the
- * device tree to id as given to the PSE control ops
* @nr_lines: number of PSE controls in this controller device
* @lock: Mutex for serialization access to the PSE controller
* @types: types of the PSE controller
+ * @pi: table of PSE PIs described in this controller device
+ * @of_legacy: flag set if the pse_pis devicetree node is not used
*/
struct pse_controller_dev {
const struct pse_controller_ops *ops;
@@ -86,11 +116,11 @@ struct pse_controller_dev {
struct list_head pse_control_head;
struct device *dev;
int of_pse_n_cells;
- int (*of_xlate)(struct pse_controller_dev *pcdev,
- const struct of_phandle_args *pse_spec);
unsigned int nr_lines;
struct mutex lock;
enum ethtool_pse_types types;
+ struct pse_pi *pi;
+ bool no_of_pse_pi;
};
#if IS_ENABLED(CONFIG_PSE_CONTROLLER)
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
PSE PI setup may encompass multiple PSE controllers or auxiliary circuits
that collectively manage power delivery to one Ethernet port.
Such configurations might support a range of PoE standards and require
the capability to dynamically configure power delivery based on the
operational mode (e.g., PoE2 versus PoE4) or specific requirements of
connected devices. In these instances, a dedicated PSE PI node becomes
essential for accurately documenting the system architecture. This node
would serve to detail the interactions between different PSE controllers,
the support for various PoE modes, and any additional logic required to
coordinate power delivery across the network infrastructure.
The old usage of "#pse-cells" is unsuficient as it carries only the PSE PI
index information.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch
Changes in v4:
- Remove $def
- Fix pairset-names item list
- Upgrade few properties description
- Update the commit message
Changes in v5:
- Fix yamllint error.
- Replace underscore by dash in properties names.
- Add polarity-supported property.
Changes in v6:
- Reorder the pairset pinout table documentation to shrink the lines size.
- Remove pairset and polarity as required fields.
- Add vpwr-supply regulator supply.
---
.../bindings/net/pse-pd/pse-controller.yaml | 102 ++++++++++++++++++++-
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
index 2d382faca0e6..03f7f215c162 100644
--- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
+++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
@@ -13,6 +13,7 @@ description: Binding for the Power Sourcing Equipment (PSE) as defined in the
maintainers:
- Oleksij Rempel <o.rempel@pengutronix.de>
+ - Kory Maincent <kory.maincent@bootlin.com>
properties:
$nodename:
@@ -22,11 +23,106 @@ properties:
description:
Used to uniquely identify a PSE instance within an IC. Will be
0 on PSE nodes with only a single output and at least 1 on nodes
- controlling several outputs.
+ controlling several outputs which are not described in the pse-pis
+ subnode. This property is deprecated, please use pse-pis instead.
enum: [0, 1]
-required:
- - "#pse-cells"
+ pse-pis:
+ type: object
+ description:
+ Overview of the PSE PIs provided by the controller.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ patternProperties:
+ "^pse-pi@[0-9a-f]+$":
+ type: object
+ description:
+ PSE PI for power delivery via pairsets, compliant with IEEE
+ 802.3-2022, Section 145.2.4. Each pairset comprises a positive and
+ a negative VPSE pair, adhering to the pinout configurations
+ detailed in the standard.
+ See Documentation/networking/pse-pd/pse-pi.rst for details.
+
+ properties:
+ reg:
+ description:
+ Address describing the PSE PI index.
+ maxItems: 1
+
+ "#pse-cells":
+ const: 0
+
+ pairset-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Names of the pairsets as per IEEE 802.3-2022, Section 145.2.4.
+ Valid values are "alternative-a" and "alternative-b". Each name
+ should correspond to a phandle in the 'pairset' property
+ pointing to the power supply for that pairset.
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - alternative-a
+ - alternative-b
+
+ pairsets:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ List of phandles, each pointing to the power supply for the
+ corresponding pairset named in 'pairset-names'. This property
+ aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
+ PSE Pinout Alternatives (as per IEEE 802.3-2022 Table 145\u20133)
+ |-----------|---------------|---------------|---------------|---------------|
+ | Conductor | Alternative A | Alternative A | Alternative B | Alternative B |
+ | | (MDI-X) | (MDI) | (X) | (S) |
+ |-----------|---------------|---------------|---------------|---------------|
+ | 1 | Negative VPSE | Positive VPSE | \u2014 | \u2014 |
+ | 2 | Negative VPSE | Positive VPSE | \u2014 | \u2014 |
+ | 3 | Positive VPSE | Negative VPSE | \u2014 | \u2014 |
+ | 4 | \u2014 | \u2014 | Negative VPSE | Positive VPSE |
+ | 5 | \u2014 | \u2014 | Negative VPSE | Positive VPSE |
+ | 6 | Positive VPSE | Negative VPSE | \u2014 | \u2014 |
+ | 7 | \u2014 | \u2014 | Positive VPSE | Negative VPSE |
+ | 8 | \u2014 | \u2014 | Positive VPSE | Negative VPSE |
+ minItems: 1
+ maxItems: 2
+
+ polarity-supported:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Polarity configuration supported by the PSE PI pairsets.
+ minItems: 1
+ maxItems: 4
+ items:
+ enum:
+ - MDI-X
+ - MDI
+ - X
+ - S
+
+ vpwr-supply:
+ description: Regulator power supply for the PSE PI.
+
+ required:
+ - reg
+ - "#pse-cells"
+
+oneOf:
+ - required:
+ - "#pse-cells"
+ - required:
+ - pse-pis
additionalProperties: true
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v6 12/17] net: pse-pd: Add support for setup_pi_matrix callback
From: Kory Maincent @ 2024-03-26 14:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King
Cc: Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project, Kory Maincent
In-Reply-To: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
Implement setup_pi_matrix callback to configure the PSE PI matrix. This
functionality is invoked before registering the PSE and following the core
parsing of the pse_pis devicetree subnode.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v3:
- New patch
---
drivers/net/pse-pd/pse_core.c | 6 ++++++
include/linux/pse-pd/pse.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 5d1bf197c067..78513bda5bbb 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -215,6 +215,12 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
if (ret)
return ret;
+ if (pcdev->ops->setup_pi_matrix) {
+ ret = pcdev->ops->setup_pi_matrix(pcdev);
+ if (ret)
+ return ret;
+ }
+
mutex_lock(&pse_list_mutex);
list_add(&pcdev->list, &pse_controller_list);
mutex_unlock(&pse_list_mutex);
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index e7ac48ef9f95..caa2e9bce3a3 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -49,6 +49,7 @@ struct pse_control_status {
*
* @ethtool_get_status: get PSE control status for ethtool interface
* @ethtool_set_config: set PSE control configuration over ethtool interface
+ * @setup_pi_matrix: setup PI matrix of the PSE controller
*/
struct pse_controller_ops {
int (*ethtool_get_status)(struct pse_controller_dev *pcdev,
@@ -57,6 +58,7 @@ struct pse_controller_ops {
int (*ethtool_set_config)(struct pse_controller_dev *pcdev,
unsigned long id, struct netlink_ext_ack *extack,
const struct pse_control_config *config);
+ int (*setup_pi_matrix)(struct pse_controller_dev *pcdev);
};
struct module;
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox