netdev - Re: [PATCH net-next] net: phy: add phylib-internal.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5a1c646d-1e02-4980-8cf5-4a3dfc670836@gmail.com>
Date: Wed, 19 Feb 2025 18:29:24 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
 Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: add phylib-internal.h

On 19.02.2025 14:35, Andrew Lunn wrote:
> On Wed, Feb 19, 2025 at 07:37:52AM +0100, Heiner Kallweit wrote:
>> On 18.02.2025 23:43, Heiner Kallweit wrote:
>>> This patch is a starting point for moving phylib-internal
>>> declarations to a private header file.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>>> ---
>>>  drivers/net/phy/phy-c45.c          |  1 +
>>>  drivers/net/phy/phy-core.c         |  3 ++-
>>>  drivers/net/phy/phy.c              |  2 ++
>>>  drivers/net/phy/phy_device.c       |  2 ++
>>>  drivers/net/phy/phy_led_triggers.c |  2 ++
>>>  drivers/net/phy/phylib-internal.h  | 25 +++++++++++++++++++++++++
>>>  include/linux/phy.h                | 13 -------------
>>>  7 files changed, 34 insertions(+), 14 deletions(-)
>>>  create mode 100644 drivers/net/phy/phylib-internal.h
> 
> Maybe we should discuss a little where we are going with this...
> 
> I like the idea, we want to limit the scope of some functions so they
> don't get abused. MAC drivers are the main abusers here, they should
> have a small set of methods they can use.
> 
> If you look at some other subsystems they have a header for consumers,
> and a header for providers. include/linux/gpio/{consumer|driver}.h,
> clk-provider.h and clk.h, etc.
> 
> Do we want include/linux/phy.h to contain the upper API for phylib,
> which MAC drivers can use? Should phylib-internal.h be just the
> internal API between parts of the core? There will be another header
> which has everything a PHY driver needs for the lower interface of
> phylib?
> 
> Is this what you are thinking?
> 
Exactly. Not sure in which category phylink would fall: part of core,
or similar to a PHY driver?

> 	Andrew
Heiner