linux-kernel - Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet reference property

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: <nj6wipqud7gnaiuvj6cl4sum7zfyp7jdvjb63op6ff4ruz7rjx@5rtkshsuxojl>
Date: Tue, 16 Sep 2025 11:31:02 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Andrew Lunn <andrew@...n.ch>, Rob Herring <robh@...nel.org>, 
	netdev@...r.kernel.org, mschmidt@...hat.com, poros@...hat.com, 
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Prathosh Satish <Prathosh.Satish@...rochip.com>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet
 reference property

Wed, Sep 10, 2025 at 02:51:33PM +0200, ivecera@...hat.com wrote:
>On 09. 09. 25 3:50 odp., Andrew Lunn wrote:
>> > > > Yesterday I was considering the implementation from the DPLL driver's
>> > > > perspective and encountered a problem when the relation is defined from
>> > > > the Ethernet controller's perspective. In that case, it would be
>> > > > necessary to enumerate all devices that contain a “dpll” property whose
>> > > > value references this DPLL device.
>> > > 
>> > > Why is that?
>> > 
>> > Because the DPLL driver has to find a mac-address of the ethernet
>> > controller to generate clock identity that is used for DPLL device
>> > registration.
>> 
>> Maybe this API is the wrong way around? Maybe what you want is that
>> the MAC driver says to the DPLL driver: hey, you are my clock
>> provider, here is an ID to use, please start providing me a clock?
>
>Yes, this could be fine but there is a problem because clock id is part
>of DPLL device and pins registration and it is not possible to change
>the clock id without full de-re-registration. I have provided in zl3073x
>a user to change the clock id via devlink but it means that the driver
>has to unregister all dpll devices and pins and register them under
>different clock id.
>
>> So it is the MAC driver which will follow the phandle, and then make a
>> call to bind the dpll to the MAC, and then provide it with the ID?
>
>In fact that would be enough to expose from the DPLL core a function
>to change clock id of the existing DPLL devices.
>
>E.g.
>
>int dpll_clock_id_change(struct module *module, u64 clock_id,
>			 u64 new_clock_id)
>{
>	struct dpll_device *dpll_pos;
>	struct dpll_pin *pin_pos;
>	unsigned long i;
>
>	mutex_lock(&dpll_lock);
>	/* Change clock_id of all devices registered by given module
>	 * with given clock_id.
>	 */
>	xa_for_each(&dpll_device_xa, i, dpll_pos) {
>		if (dpll->clock_id == clock_id &&
>		    dpll->module == module)
>			dpll_pos->clock_id = new_clock_id;
>		}
>	}
>	/* Change clock_id of all pins registered by given module
>	 * with given clock_id.
>	 */
>	xa_for_each(&dpll_pin_xa, i, pos) {
>		if (pin_pos->clock_id == clock_id &&
>		    pin_pos->module == module) {
>			pos->clock_id = new_clock_id;
>		}
>	}
>	mutex_unlock(&dpll_lock);
>}
>
>With this, the standalone DPLL driver can register devices and pins with
>arbitrary clock_id and then the MAC driver can change it.
>
>Thoughts?

The clock_id in dpll is basically a property. It is not used in uapi
(other then for show and obtaining the device id). So if you introduce
a mean the change this property, I don't see a problem with that.


>
>Thanks,
>Ivan
>