mbox series

[net,v2,0/3] Limit devicetree parameters to hardware capability

Message ID 20250121044138.2883912-1-hayashi.kunihiko@socionext.com (mailing list archive)
Headers show
Series Limit devicetree parameters to hardware capability | expand

Message

Kunihiko Hayashi Jan. 21, 2025, 4:41 a.m. UTC
This series includes patches that checks the devicetree properties,
the number of MTL queues and FIFO size values, and if these specified
values exceed the value contained in the hardware capabilities, limit to
the values from the capabilities.

And this sets hardware capability values if FIFO sizes are not specified
and removes redundant lines.

Changes since v1:
- Move the check for FIFO size and MTL queues to initializing phase
- Move zero check lines to initializing phase
- Use hardware capabilities instead of defined values
- Add warning messages if the values exceeds
- Add Fixes: lines

Kunihiko Hayashi (3):
  net: stmmac: Limit the number of MTL queues to hardware capability
  net: stmmac: Limit FIFO size by hardware capability
  net: stmmac: Specify hardware capability value when FIFO size isn't
    specified

 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 43 +++++++++++++------
 1 file changed, 30 insertions(+), 13 deletions(-)

Comments

Russell King (Oracle) Jan. 21, 2025, 10:25 a.m. UTC | #1
On Tue, Jan 21, 2025 at 01:41:35PM +0900, Kunihiko Hayashi wrote:
> This series includes patches that checks the devicetree properties,
> the number of MTL queues and FIFO size values, and if these specified
> values exceed the value contained in the hardware capabilities, limit to
> the values from the capabilities.
> 
> And this sets hardware capability values if FIFO sizes are not specified
> and removes redundant lines.

I think you also indeed to explain why (and possibly understand) - if
there are hardware capabilities that describe these parameters - it has
been necessary to have them in firmware as well.

There are two scenarios I can think of why these would be duplicated:

1. firmware/platform capabilities are there to correct wrong values
   provided by the hardware.
2. firmware/platform capabilities are there to reduce the parameters
   below hardware maximums.

Which it is affects whether your patch is correct or not, and thus needs
to be mentioned.

Finally, as you are submitting to the net tree, you really need to
describe what has regressed in the driver. To me, this looks like a new
"feature" to validate parameters against the hardware.

Please answer these points in this email thread. Please also include
the explanation in future postings.

Thanks.