From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8409D33A01F for ; Tue, 9 Sep 2025 12:51:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757422271; cv=none; b=TUsc6b7XKDi8RKXNTjHe9+OzrWKFrKo4n9N/++TCI3dnyq7P9syY3R042Dz775JmyRH7rXXOwhrn5o7aymgNzlRVxpp1iMt7JUy+ibUjRX5rKZ9f9p4I7njThs65RzR6zWr3KIeqmAjmNXEREN8vw0dYpnll5d8TsbrJ6MnF1eY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757422271; c=relaxed/simple; bh=p+uwnARHKaKFvBz9T0sBrH6GYywgAZuWie5pxf8XDMw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jysLovyOZCqJPWm5R0MYf8PlBzlDQcjIDrSLnaBduGiKhkUOHBdvugG0kPZzLkg5df6um7b8/JnhcIGdGXzbczB1WiNYXx+74775UWD7aF6pxlegxDXaL2ORZ3BkSsCPaaDPyN03Ue3S8Qh98YGdDpLAtrTRICcTXzAZpcKdKno= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gCjdrW6o; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gCjdrW6o" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1757422268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R2jnI7fNqw0lRQ0MgQ9fxhCAaCw81b8Cvio1UiytAs8=; b=gCjdrW6oiOqcW47IaJASXgee1nXKH1M5i2OlQioIKXp79wXBGktcdfxxZ6Zjx/FaopteJU Hy0qMrNKsSoA5g74z9pf3BmtBd+kF07+5ozMYP/Y+yX8dQ1kj0hdivSYy698Hu1t3PtdUo k/jmCYRw1N0zN8NsO8FVeIJZshOY748= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-WvhWlA-wNr28CHrF0BW4lg-1; Tue, 09 Sep 2025 08:51:05 -0400 X-MC-Unique: WvhWlA-wNr28CHrF0BW4lg-1 X-Mimecast-MFC-AGG-ID: WvhWlA-wNr28CHrF0BW4lg_1757422263 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 479B419560AB; Tue, 9 Sep 2025 12:51:03 +0000 (UTC) Received: from [10.43.2.187] (unknown [10.43.2.187]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BFA7E1800447; Tue, 9 Sep 2025 12:50:59 +0000 (UTC) Message-ID: <4dc015f7-63ad-4b44-8565-795648332ada@redhat.com> Date: Tue, 9 Sep 2025 14:50:58 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH net-next] dt-bindings: dpll: Add per-channel Ethernet reference property To: Rob Herring Cc: netdev@vger.kernel.org, mschmidt@redhat.com, poros@redhat.com, Andrew Lunn , Vadim Fedorenko , Arkadiusz Kubalewski , Jiri Pirko , Krzysztof Kozlowski , Conor Dooley , Prathosh Satish , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list References: <20250815144736.1438060-1-ivecera@redhat.com> <20250820211350.GA1072343-robh@kernel.org> <5e38e1b7-9589-49a9-8f26-3b186f54c7d5@redhat.com> Content-Language: en-US From: Ivan Vecera In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 On 09. 09. 25 12:49 dop., Rob Herring wrote: > On Fri, Sep 5, 2025 at 1:50 AM Ivan Vecera wrote: >> >> >> >> On 05. 09. 25 12:06 dop., Rob Herring wrote: >>> On Fri, Aug 29, 2025 at 8:29 AM Ivan Vecera wrote: >>>> ... >>>> >>>> Do you mean to add a property (e.g. dpll-channel or dpll-device) into >>>> net/network-class.yaml ? If so, yes, it would be possible, and the way >>>> I look at it now, it would probably be better. The DPLL driver can >>>> enumerate all devices across the system that has this specific property >>>> and check its value. >>> >>> Yes. Or into ethernet-controller.yaml. Is a DPLL used with wifi, >>> bluetooth, etc.? >> >> AFAIK no... ethernet-controller makes sense. >> >>>> >>>> See the proposal below... >>>> >>>> Thanks, >>>> Ivan >>>> >>>> --- >>>> Documentation/devicetree/bindings/dpll/dpll-device.yaml | 6 ++++++ >>>> Documentation/devicetree/bindings/net/network-class.yaml | 7 +++++++ >>>> 2 files changed, 13 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml >>>> b/Documentation/devicetree/bindings/dpll/dpll-device.yaml >>>> index fb8d7a9a3693f..560351df1bec3 100644 >>>> --- a/Documentation/devicetree/bindings/dpll/dpll-device.yaml >>>> +++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml >>>> @@ -27,6 +27,12 @@ properties: >>>> "#size-cells": >>>> const: 0 >>>> >>>> + "#dpll-cells": >>>> + description: | >>>> + Number of cells in a dpll specifier. The cell specifies the index >>>> + of the channel within the DPLL device. >>>> + const: 1 >>> >>> If it is 1 for everyone, then you don't need a property for it. The >>> question is whether it would need to vary. Perhaps some configuration >>> flags/info might be needed? Connection type or frequency looking at >>> the existing configuration setting? >> >> Connection type maybe... What I am trying to do is define a relationship >> between the network controller and the DPLL device, which together form >> a single entity from a use-case perspective (e.g., Ethernet uses an >> external DPLL device either to synchronize the recovered clock or to >> provide a SyncE signal synchronized with an external 1PPS source). >> >> 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. >> >> This approach seems quite complicated, as it would require searching >> through all buses, all connected devices, and checking each fwnode for a >> “dpll” property containing the given reference. I don’t think this would >> be the right solution. > > for_each_node_with_property() provides that. No, it's not efficient, > but I doubt it needs to be. As you'd only need to do it once. Yes, for_each_node_with_property() could be used but only for OF case. I would like to use firmware type agnostic interface to cover also ACPI systems where the zl3073x driver is/will be used. I'm not aware of similar functionality for fwnode... is it an option to write FW type agnostic macro for_each_fwnode_with_property() that would cover OF, ACPI, software_node...? >> I then came across graph bindings and ACPI graph extensions, which are >> widely used in the media and DRM subsystems to define relations between >> devices. Would this be an appropriate way to define a binding between an >> Ethernet controller and a DPLL device? > > Usually the graph is used to handle complex chains of devices and how > the data flows. I'm not sure that applies here. Agree. >> If so, what would such a binding roughly look like? I’m not very >> experienced in this area, so I would appreciate any guidance. >> >> If not, wouldn’t it be better to define the relation from the DPLL >> device to the network controller, as originally proposed? > > I have no idea really. I would think the DPLL is the provider and an > ethernet device is the consumer. And if the ethernet device is unused > (or disabled), then the DPLL connection associated with it is unused. > If that's the case, then I think the property belongs in the ethernet > node. From this point of view, this is true. DPLL is signal provider and ethernet controller its consumer. Or in other words the PHC in the NIC is driven by this DPLL OR the DPLL drives the PHC in this NIC. It depends on point of view. Thanks, Ivan