[net-next,06/12] net: ethtool: Add PSE new port priority support feature

Commit Message

Kory Maincent Oct. 2, 2024, 4:28 p.m. UTC

From: Kory Maincent (Dent Project) <[e-mail]>

This patch expands the status information provided by ethtool for PSE c33
with current port priority and max port priority. It also adds a call to
pse_ethtool_set_prio() to configure the PSE port priority.

Signed-off-by: Kory Maincent <[e-mail]>
---
 Documentation/networking/ethtool-netlink.rst | 16 ++++++++++++++++
 include/uapi/linux/ethtool_netlink.h         |  2 ++
 net/ethtool/pse-pd.c                         | 18 ++++++++++++++++++
 3 files changed, 36 insertions(+)

Comments

Andrew Lunn Oct. 2, 2024, 11:37 p.m. UTC | #1

On Wed, Oct 02, 2024 at 06:28:02PM +0200, Kory Maincent wrote:
> From: Kory Maincent (Dent Project) <[e-mail]>
> 
> This patch expands the status information provided by ethtool for PSE c33
> with current port priority and max port priority. It also adds a call to
> pse_ethtool_set_prio() to configure the PSE port priority.
> 
> Signed-off-by: Kory Maincent <[e-mail]>

Reviewed-by: Andrew Lunn <[e-mail]>

    Andrew

Oleksij Rempel Oct. 5, 2024, 6:26 a.m. UTC | #2

On Wed, Oct 02, 2024 at 06:28:02PM +0200, Kory Maincent wrote:
> From: Kory Maincent (Dent Project) <[e-mail]>
> 
> This patch expands the status information provided by ethtool for PSE c33
> with current port priority and max port priority. It also adds a call to
> pse_ethtool_set_prio() to configure the PSE port priority.
> 
> Signed-off-by: Kory Maincent <[e-mail]>
> ---
>  Documentation/networking/ethtool-netlink.rst | 16 ++++++++++++++++
>  include/uapi/linux/ethtool_netlink.h         |  2 ++
>  net/ethtool/pse-pd.c                         | 18 ++++++++++++++++++
>  3 files changed, 36 insertions(+)
> 
> diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
> index 295563e91082..15208429a973 100644
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -1763,6 +1763,10 @@ Kernel response contents:
>                                                        limit of the PoE PSE.
>    ``ETHTOOL_A_C33_PSE_PW_LIMIT_RANGES``       nested  Supported power limit
>                                                        configuration ranges.
> +  ``ETHTOOL_A_C33_PSE_PRIO_MAX``                 u32  priority maximum configurable
> +                                                      on the PoE PSE
> +  ``ETHTOOL_A_C33_PSE_PRIO``                     u32  priority of the PoE PSE
> +                                                      currently configured
>    ==========================================  ======  =============================
>  
>  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` attribute identifies
> @@ -1836,6 +1840,12 @@ identifies the C33 PSE power limit ranges through
>  If the controller works with fixed classes, the min and max values will be
>  equal.
>  
> +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute identifies
> +the C33 PSE maximum priority value.
> +
> +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> +identifies the currently configured C33 PSE priority.
> +
>  PSE_SET
>  =======
>  
> @@ -1849,6 +1859,8 @@ Request contents:
>    ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL``        u32  Control PSE Admin state
>    ``ETHTOOL_A_C33_PSE_AVAIL_PWR_LIMIT``      u32  Control PoE PSE available
>                                                    power limit
> +  ``ETHTOOL_A_C33_PSE_PRIO``                 u32  Control priority of the
> +                                                  PoE PSE
>    ======================================  ======  =============================
>  
>  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used
> @@ -1871,6 +1883,10 @@ various existing products that document power consumption in watts rather than
>  classes. If power limit configuration based on classes is needed, the
>  conversion can be done in user space, for example by ethtool.
>  
> +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> +control the C33 PSE priority. Allowed priority value are between zero
> +and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.
 
We need to introduce a new attribute to effectively manage PSE priorities. With
the addition of the `ETHTOOL_A_C33_PSE_PRIO` attribute for setting priorities,
it's important to know which PSE controller or domain each port belongs to.

Initially, we might consider using a PSE controller index, such as
`ETHTOOL_A_PSE_CONTROLLER_ID`, to identify the specific PSE controller
associated with each port.

However, using just the PSE controller index is too limiting. Here's why:

- Typical PSE controllers handle priorities only within themselves. They
usually can't manage prioritization across different controllers unless they
are part of the same power domain. In systems where multiple PSE controllers
cooperate—either directly or through software mechanisms like the regulator
framework—controllers might share power domains or manage priorities together.
This means priorities are not confined to individual controllers but are
relevant within shared power domains.

- As systems become more complex, with controllers that can work together,
relying solely on a controller index won't accommodate these cooperative
scenarios.

To address these issues, we should use a power domain identifier instead. I
suggest introducing a new attribute called `ETHTOOL_A_PSE_POWER_DOMAIN_ID`.

- It specifies the power domain to which each port belongs, ensuring that
priorities are managed correctly within that domain.

- It accommodates systems where controllers cooperate and share power
resources, allowing for proper coordination of priorities across controllers
within the same power domain.

- It provides flexibility for future developments where controllers might work
together in new ways, preventing limitations that would arise from using a
strict controller index.

However, to provide comprehensive information, it would be beneficial to use
both attributes:

- `ETHTOOL_A_PSE_CONTROLLER_ID` to identify the specific PSE controller
associated with each port.

- `ETHTOOL_A_PSE_POWER_DOMAIN_ID` to specify the power domain to which each
port belongs.

Regards,
Oleksij

Kory Maincent Oct. 7, 2024, 9:30 a.m. UTC | #3

On Sat, 5 Oct 2024 08:26:36 +0200
Oleksij Rempel <[e-mail]> wrote:

> >  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is
> > used @@ -1871,6 +1883,10 @@ various existing products that document power
> > consumption in watts rather than classes. If power limit configuration
> > based on classes is needed, the conversion can be done in user space, for
> > example by ethtool. 
> > +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> > +control the C33 PSE priority. Allowed priority value are between zero
> > +and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.  
>  
> We need to introduce a new attribute to effectively manage PSE priorities.
> With the addition of the `ETHTOOL_A_C33_PSE_PRIO` attribute for setting
> priorities, it's important to know which PSE controller or domain each port
> belongs to.
> 
> Initially, we might consider using a PSE controller index, such as
> `ETHTOOL_A_PSE_CONTROLLER_ID`, to identify the specific PSE controller
> associated with each port.
> 
> However, using just the PSE controller index is too limiting. Here's why:
> 
> - Typical PSE controllers handle priorities only within themselves. They
> usually can't manage prioritization across different controllers unless they
> are part of the same power domain. In systems where multiple PSE controllers
> cooperate—either directly or through software mechanisms like the regulator
> framework—controllers might share power domains or manage priorities together.
> This means priorities are not confined to individual controllers but are
> relevant within shared power domains.
> 
> - As systems become more complex, with controllers that can work together,
> relying solely on a controller index won't accommodate these cooperative
> scenarios.
> 
> To address these issues, we should use a power domain identifier instead. I
> suggest introducing a new attribute called `ETHTOOL_A_PSE_POWER_DOMAIN_ID`.
> 
> - It specifies the power domain to which each port belongs, ensuring that
> priorities are managed correctly within that domain.
> 
> - It accommodates systems where controllers cooperate and share power
> resources, allowing for proper coordination of priorities across controllers
> within the same power domain.
> 
> - It provides flexibility for future developments where controllers might work
> together in new ways, preventing limitations that would arise from using a
> strict controller index.
> 
> However, to provide comprehensive information, it would be beneficial to use
> both attributes:
> 
> - `ETHTOOL_A_PSE_CONTROLLER_ID` to identify the specific PSE controller
> associated with each port.
> 
> - `ETHTOOL_A_PSE_POWER_DOMAIN_ID` to specify the power domain to which each
> port belongs.

Currently the priority is managed by the PSE controller so the port is the only
information needed. The user interface is ethtool, and I don't see why he would
need such things like controller id or power domain id. Instead, it could be
managed by the PSE core depending on the power domains described in the
devicetree. The user only wants to know if he can allow a specific power budget
on a Ethernet port and configure port priority in case of over power-budget
event.

I don't have hardware with several PSE controllers. Is there already such
hardware existing in the market?
This seems like an interesting idea but I think it would belong in another patch
series.
Still, it is good to talk about it for future development idea.

Regards,

Oleksij Rempel Oct. 7, 2024, 2:10 p.m. UTC | #4

On Mon, Oct 07, 2024 at 11:30:26AM +0200, Kory Maincent wrote:
> On Sat, 5 Oct 2024 08:26:36 +0200
> Oleksij Rempel <[e-mail]> wrote:
> 
> > >  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is
> > > used @@ -1871,6 +1883,10 @@ various existing products that document power
> > > consumption in watts rather than classes. If power limit configuration
> > > based on classes is needed, the conversion can be done in user space, for
> > > example by ethtool. 
> > > +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> > > +control the C33 PSE priority. Allowed priority value are between zero
> > > +and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.  
> >  
> > We need to introduce a new attribute to effectively manage PSE priorities.
> > With the addition of the `ETHTOOL_A_C33_PSE_PRIO` attribute for setting
> > priorities, it's important to know which PSE controller or domain each port
> > belongs to.
> > 
> > Initially, we might consider using a PSE controller index, such as
> > `ETHTOOL_A_PSE_CONTROLLER_ID`, to identify the specific PSE controller
> > associated with each port.
> > 
> > However, using just the PSE controller index is too limiting. Here's why:
> > 
> > - Typical PSE controllers handle priorities only within themselves. They
> > usually can't manage prioritization across different controllers unless they
> > are part of the same power domain. In systems where multiple PSE controllers
> > cooperate—either directly or through software mechanisms like the regulator
> > framework—controllers might share power domains or manage priorities together.
> > This means priorities are not confined to individual controllers but are
> > relevant within shared power domains.
> > 
> > - As systems become more complex, with controllers that can work together,
> > relying solely on a controller index won't accommodate these cooperative
> > scenarios.
> > 
> > To address these issues, we should use a power domain identifier instead. I
> > suggest introducing a new attribute called `ETHTOOL_A_PSE_POWER_DOMAIN_ID`.
> > 
> > - It specifies the power domain to which each port belongs, ensuring that
> > priorities are managed correctly within that domain.
> > 
> > - It accommodates systems where controllers cooperate and share power
> > resources, allowing for proper coordination of priorities across controllers
> > within the same power domain.
> > 
> > - It provides flexibility for future developments where controllers might work
> > together in new ways, preventing limitations that would arise from using a
> > strict controller index.
> > 
> > However, to provide comprehensive information, it would be beneficial to use
> > both attributes:
> > 
> > - `ETHTOOL_A_PSE_CONTROLLER_ID` to identify the specific PSE controller
> > associated with each port.
> > 
> > - `ETHTOOL_A_PSE_POWER_DOMAIN_ID` to specify the power domain to which each
> > port belongs.
> 
> Currently the priority is managed by the PSE controller so the port is the only
> information needed. The user interface is ethtool, and I don't see why he would
> need such things like controller id or power domain id. Instead, it could be
> managed by the PSE core depending on the power domains described in the
> devicetree. The user only wants to know if he can allow a specific power budget
> on a Ethernet port and configure port priority in case of over power-budget
> event.

Budget is important but different topic. If user do not know how much
the budget is, there is nothing usable user can configure. Imagine you
do not know how much money can spend and the only way to find it out is
by baying things.

But, budget is the secondary topic withing context of this patch set.
The primer topic here is the prioritization, so the information user
need to know it the context: do A has higher prio in relation to B? Do A
and B actually in the same domain?


> I don't have hardware with several PSE controllers. Is there already such
> hardware existing in the market?

Please correct me if i'm wrong, but in case of pd692x0 based devices,
every manager (for example PD69208M) is own power domain. There are
following limiting factors:
                          PI 1
                   L4    /
		 PD69208M - PI 2
              L3 //      \
 L1      L2     //        PI 3
PSU ============'
                \\        PI 4
                 \\      /
		 PD69208M - PI 5
                         \
			  PI 6

L1 - limits defined by Power Supply Unit
L2 - Limits defined by main supply rail ob PCB
L3 - Limits defined by rail attached to one specific manager
L4 - Limits defined by manager. In case of PD69208M it is Max 0.627A
(for all or per port?)

Assuming PSU provides enough budget to covert Max supported current for
every manager, then the limiting factor is actual manager. It means,
setting prio for PI 4 in relation to PI 1 makes no real sense, because
it is in different power domain.

User will not understand why devices fail to provide enough power by
attaching two device to one domain and not failing by attaching to
different domains. Except we provide this information to the user space.

Regards,
Oleksij

Kory Maincent Oct. 8, 2024, 10:23 a.m. UTC | #5

On Mon, 7 Oct 2024 16:10:33 +0200
Oleksij Rempel <[e-mail]> wrote:

> > 
> > Currently the priority is managed by the PSE controller so the port is the
> > only information needed. The user interface is ethtool, and I don't see why
> > he would need such things like controller id or power domain id. Instead,
> > it could be managed by the PSE core depending on the power domains
> > described in the devicetree. The user only wants to know if he can allow a
> > specific power budget on a Ethernet port and configure port priority in
> > case of over power-budget event.  
> 
> Budget is important but different topic. If user do not know how much
> the budget is, there is nothing usable user can configure. Imagine you
> do not know how much money can spend and the only way to find it out is
> by baying things.

Yes I agree, but I thought this could be done at the driver level specified in
the power limit ranges for now.
I don't really know the Power Domain API but I don't think it can currently
support what you are expecting for PSE. Maybe through the regulator API, or
something specific to PSE API.
Maybe we should define the power domain PSE concept as it seems something PSE
specific.

> But, budget is the secondary topic withing context of this patch set.
> The primer topic here is the prioritization, so the information user
> need to know it the context: do A has higher prio in relation to B? Do A
> and B actually in the same domain?
> 
> 
> > I don't have hardware with several PSE controllers. Is there already such
> > hardware existing in the market?  
> 
> Please correct me if i'm wrong, but in case of pd692x0 based devices,
> every manager (for example PD69208M) is own power domain. There are
> following limiting factors:
>                           PI 1
>                    L4    /
> 		 PD69208M - PI 2
>               L3 //      \
>  L1      L2     //        PI 3
> PSU ============'
>                 \\        PI 4
>                  \\      /
> 		 PD69208M - PI 5
>                          \
> 			  PI 6
> 
> L1 - limits defined by Power Supply Unit
> L2 - Limits defined by main supply rail ob PCB
> L3 - Limits defined by rail attached to one specific manager
> L4 - Limits defined by manager. In case of PD69208M it is Max 0.627A
> (for all or per port?)

Should the rail really have an impact on power limit? I am not a hardware
designer but having limit defined by the rails seems the best way to create
magic smoke.
Don't know how you find this 0.627A value but it seems a bit low. Port current
limit is 1300mA according to the datasheet.

I first though that hardware should support all ports being powered at the same
time. Indeed this might not be the case be and there is a command to configure
the power bank (PD69208M) power limit.
 
> Assuming PSU provides enough budget to covert Max supported current for
> every manager, then the limiting factor is actual manager. It means,
> setting prio for PI 4 in relation to PI 1 makes no real sense, because
> it is in different power domain.

In fact it does for our case as the PD692x0 consider all the ports in the same
power domain. There is no mention of port priority per PD69208M.
We can only get PD69208M events and status.

> User will not understand why devices fail to provide enough power by
> attaching two device to one domain and not failing by attaching to
> different domains. Except we provide this information to the user space.

What you are explaining seems neat on the paper but I don't know the best way
to implement it. It needs more brainstorming.

Regards,

Kory Maincent Oct. 8, 2024, 12:56 p.m. UTC | #6

On Tue, 8 Oct 2024 12:23:00 +0200
Kory Maincent <[e-mail]> wrote:

> On Mon, 7 Oct 2024 16:10:33 +0200
> Oleksij Rempel <[e-mail]> wrote:
> 
> > User will not understand why devices fail to provide enough power by
> > attaching two device to one domain and not failing by attaching to
> > different domains. Except we provide this information to the user space.
> 
> What you are explaining seems neat on the paper but I don't know the best way
> to implement it. It needs more brainstorming.

Is it ok for you if we go further with this patch series and continue talking
about PSE power domain alongside?
It should not be necessary to be supported with port priority as the two PSE
supported controller can behave autonomously on a power domain.
I hope I will have time in the project to add its support when we will have a
more precise idea of how.

Regards,

Oleksij Rempel Oct. 8, 2024, 3:01 p.m. UTC | #7

On Tue, Oct 08, 2024 at 02:56:17PM +0200, Kory Maincent wrote:
> On Tue, 8 Oct 2024 12:23:00 +0200
> Kory Maincent <[e-mail]> wrote:
> 
> > On Mon, 7 Oct 2024 16:10:33 +0200
> > Oleksij Rempel <[e-mail]> wrote:
> > 
> > > User will not understand why devices fail to provide enough power by
> > > attaching two device to one domain and not failing by attaching to
> > > different domains. Except we provide this information to the user space.
> > 
> > What you are explaining seems neat on the paper but I don't know the best way
> > to implement it. It needs more brainstorming.
> 
> Is it ok for you if we go further with this patch series and continue talking
> about PSE power domain alongside?
> It should not be necessary to be supported with port priority as the two PSE
> supported controller can behave autonomously on a power domain.
> I hope I will have time in the project to add its support when we will have a
> more precise idea of how.

Ok.

Oleksij Rempel Oct. 8, 2024, 4:31 p.m. UTC | #8

On Wed, Oct 02, 2024 at 06:28:02PM +0200, Kory Maincent wrote:
> From: Kory Maincent (Dent Project) <[e-mail]>
...
>  PSE_SET
>  =======
>  
> @@ -1849,6 +1859,8 @@ Request contents:
>    ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL``        u32  Control PSE Admin state
>    ``ETHTOOL_A_C33_PSE_AVAIL_PWR_LIMIT``      u32  Control PoE PSE available
>                                                    power limit
> +  ``ETHTOOL_A_C33_PSE_PRIO``                 u32  Control priority of the
> +                                                  PoE PSE
>    ======================================  ======  =============================
>  
>  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used
> @@ -1871,6 +1883,10 @@ various existing products that document power consumption in watts rather than
>  classes. If power limit configuration based on classes is needed, the
>  conversion can be done in user space, for example by ethtool.
>  
> +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> +control the C33 PSE priority. Allowed priority value are between zero
> +and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.
 
Please extend the documentation with expected system behavior: the
meaning of lowest and highest values, power up and shutdown behaviors,
etc.

Patch

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 295563e91082..15208429a973 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -1763,6 +1763,10 @@  Kernel response contents:
                                                       limit of the PoE PSE.
   ``ETHTOOL_A_C33_PSE_PW_LIMIT_RANGES``       nested  Supported power limit
                                                       configuration ranges.
+  ``ETHTOOL_A_C33_PSE_PRIO_MAX``                 u32  priority maximum configurable
+                                                      on the PoE PSE
+  ``ETHTOOL_A_C33_PSE_PRIO``                     u32  priority of the PoE PSE
+                                                      currently configured
   ==========================================  ======  =============================
 
 When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` attribute identifies
@@ -1836,6 +1840,12 @@  identifies the C33 PSE power limit ranges through
 If the controller works with fixed classes, the min and max values will be
 equal.
 
+When set, the optional ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute identifies
+the C33 PSE maximum priority value.
+
+When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
+identifies the currently configured C33 PSE priority.
+
 PSE_SET
 =======
 
@@ -1849,6 +1859,8 @@  Request contents:
   ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL``        u32  Control PSE Admin state
   ``ETHTOOL_A_C33_PSE_AVAIL_PWR_LIMIT``      u32  Control PoE PSE available
                                                   power limit
+  ``ETHTOOL_A_C33_PSE_PRIO``                 u32  Control priority of the
+                                                  PoE PSE
   ======================================  ======  =============================
 
 When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used
@@ -1871,6 +1883,10 @@  various existing products that document power consumption in watts rather than
 classes. If power limit configuration based on classes is needed, the
 conversion can be done in user space, for example by ethtool.
 
+When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
+control the C33 PSE priority. Allowed priority value are between zero
+and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.
+
 RSS_GET
 =======
 
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 283305f6b063..874a4bca2e19 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -970,6 +970,8 @@  enum {
 	ETHTOOL_A_C33_PSE_EXT_SUBSTATE,		/* u32 */
 	ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT,	/* u32 */
 	ETHTOOL_A_C33_PSE_PW_LIMIT_RANGES,	/* nest - _C33_PSE_PW_LIMIT_* */
+	ETHTOOL_A_C33_PSE_PRIO_MAX,		/* u32 */
+	ETHTOOL_A_C33_PSE_PRIO,			/* u32 */
 
 	/* add new constants above here */
 	__ETHTOOL_A_PSE_CNT,
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index a0705edca22a..439739eaf2ed 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -109,6 +109,9 @@  static int pse_reply_size(const struct ethnl_req_info *req_base,
 		len += st->c33_pw_limit_nb_ranges *
 		       (nla_total_size(0) +
 			nla_total_size(sizeof(u32)) * 2);
+	if (st->c33_prio_max)
+		/* _C33_PSE_PRIO_MAX + _C33_PSE_PRIO */
+		len += nla_total_size(sizeof(u32)) * 2;
 
 	return len;
 }
@@ -198,6 +201,11 @@  static int pse_fill_reply(struct sk_buff *skb,
 	    pse_put_pw_limit_ranges(skb, st))
 		return -EMSGSIZE;
 
+	if (st->c33_prio_max > 0 &&
+	    (nla_put_u32(skb, ETHTOOL_A_C33_PSE_PRIO_MAX, st->c33_prio_max) ||
+	     nla_put_u32(skb, ETHTOOL_A_C33_PSE_PRIO, st->c33_prio)))
+		return -EMSGSIZE;
+
 	return 0;
 }
 
@@ -219,6 +227,7 @@  const struct nla_policy ethnl_pse_set_policy[ETHTOOL_A_PSE_MAX + 1] = {
 		NLA_POLICY_RANGE(NLA_U32, ETHTOOL_C33_PSE_ADMIN_STATE_DISABLED,
 				 ETHTOOL_C33_PSE_ADMIN_STATE_ENABLED),
 	[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT] = { .type = NLA_U32 },
+	[ETHTOOL_A_C33_PSE_PRIO] = { .type = NLA_U32 },
 };
 
 static int
@@ -267,6 +276,15 @@  ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 	if (ret)
 		return ret;
 
+	if (tb[ETHTOOL_A_C33_PSE_PRIO]) {
+		unsigned int prio;
+
+		prio = nla_get_u32(tb[ETHTOOL_A_C33_PSE_PRIO]);
+		ret = pse_ethtool_set_prio(phydev->psec, info->extack, prio);
+		if (ret)
+			return ret;
+	}
+
 	if (tb[ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT]) {
 		unsigned int pw_limit;