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 90D403F3285 for ; Thu, 6 Aug 2026 09:41:25 +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=1786009287; cv=none; b=YbDhvoIpcb+elFuTtrPrd06ICtBY9icmXrxJKTHoOT64pk8N4oLa99mRLzHFimohT6AjYlfVnHvol35Liz4sl1611z0eHSPx8RnIHJgD+jJqc+cIuYCM3dP8ANTH02LZpTRYgq5kmpm8+bHYO7wI5QO3Dbr8HcQbbIe0y8lSfjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786009287; c=relaxed/simple; bh=uJ1y5/CS5v2Ay70tM26cPgrpmyvQZ+ahXvKr9LMURok=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Chtcrj5ASrKGYbaq8rNPInn1JKdNujqy6tenzT82J6gLNQX+/2fEfJrvUxslcjTn3TXQD3hH2ILUs3WhI7zUr76Yc+cndb2TUg0YfXcxaS56jHvC16Vw5Sc3xedXsGZCrxDONu+Cmh+K4C/SJx59MN+eXb+nXiKHaE4/tt9pzCU= 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=KSEOSnZu; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=X4DoWIV1; 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="KSEOSnZu"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="X4DoWIV1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786009284; 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=/pXBA5d8ovqzrxLyC73uQmUReb3p2yg2U+QZG9FKHcg=; b=KSEOSnZuonW7bhgdjk/rLQZzOVEqqRrjKZIxm73Nog4TmXIMEOa3SKCNQ97bQtcABChche 4BCFerQGkS3kghNSv95LYKSmpv0KQWgxmPeEpG1hCkmILY1ov8MSqrJqwvsAi4saWEyyFy MS0En3a83D/MDOaeEniijp9zUf7LoIM= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-352-_IKIg8OlPQin3JvkSx-7yQ-1; Thu, 06 Aug 2026 05:41:23 -0400 X-MC-Unique: _IKIg8OlPQin3JvkSx-7yQ-1 X-Mimecast-MFC-AGG-ID: _IKIg8OlPQin3JvkSx-7yQ_1786009282 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-475e540a0ffso1197793f8f.3 for ; Thu, 06 Aug 2026 02:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786009282; x=1786614082; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=/pXBA5d8ovqzrxLyC73uQmUReb3p2yg2U+QZG9FKHcg=; b=X4DoWIV1CrZ/LAEx/JbFaX4axZXkj+sHYmXopEZctAi+PZiGoLknNfyBeA4Gylr8l8 kfuFiXEcCn4G30Q+sKB7XVrg/Gbqu79Qo4BAaHRywnJWYWkFaKD5cPQOom+ZChIgdiLF bhyRW+1Lcouj3ZxT9AlR6AzRcGym/is0YOSIzfjq43UE/miThs6PSXMZfrc7p8CYxbrW bY+P+nZvyb5sQSbeGhTwmnUHSArWQs37wPwEpHTpX0NnKnYLf6QEN1QLtYhKqool2WPl xK2GfQIjx+MD+yZq1jX+6zyWnQmAr6oGu7DQVzRTlkLJldKU6wrQWFl4WU1MVhWNkHgc 6qKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786009282; x=1786614082; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/pXBA5d8ovqzrxLyC73uQmUReb3p2yg2U+QZG9FKHcg=; b=lOoYpXRtxDeB3M5ivGyXwjc+dEcdhFA0NKzriJ5fknI61HcxKIfOf3F+FKFhqtCvej MeXX1DmTaYYm9MXMUut+mczVlL/AHPXaDyyUQTT2j+3QKvhCHiEFYZORhyrps+YdYAQ7 uUzt0/4TXr8EjsQSidYifjrMib3uwVLyRf5b3PPoqhUd+E9IefbPTAA91So807QgLBlo cnWj9fRUr6+WLnFuSX3U7Z3so/AtJOlul/X64we4GdPZVY0tnL5Bsl/u0mkaH9Iwhf2v VQxr38v/p6uul4p46rABj3P0F0SUXtowFBNcpUjlCKA7KAGOKUu9fpMyNpejNPRLgFm4 LddQ== X-Forwarded-Encrypted: i=1; AHgh+RoNrRtlufmh75lOo3Fwy/K+gunHDlLhTHLbCCM1NZBOzZovCRG7RNYn6n+NJg/GYSI1seX5imXybcpYHi0=@vger.kernel.org X-Gm-Message-State: AOJu0YxwNoo6zeohFfe0uY/fXeL9mjckP2P0+N71+3WoISrbr4PWDZ3w 8l5uLdZW/l7dprHcE1nWP9w7QIfKaf+1ndaFcNuFQ1X6nS63N126On5awRpCeqwRZalQhpf5e2f c2krpd0bEBaF7Yapg8/UEKHOwTFB52nX5JoS82Y99iJa7bEGcMqGOo/qbTpX8Ns3r9Q== X-Gm-Gg: AR+sD13sNsplcmPK+R+11998M7ByHpXgI80+Z1NATxyCYA3B0BGky0Ucx5emwBJq3/U X9z1oIjICJvha0zTUBC+oA1e1r/9oXB50XhZ/5XTN7EDY78QNJkf4gbXfDnEUYN2tQ2f28zVcZ/ KRMs1A+vAoGx9tGSnagvX0gP12VeGJ3AIGPmFAyZ+JZpVrpS5qPyXc3sc0UNMTs15IkTJVFVJGb LSKXUaEIxi6t1N52T7BhJIYvJ5D0+vvScGQico+3USpqipWFDbGubE15LxGtPHTkQRkoM8F+mmn zkfGmkOulvTY580m2f45utMXS0+FC2Nt0oa5T0pHnKU5HLesuN+xmOstEvLUArjYMrD7ZA11gNc CZ5/nIzB31oU7uoUvJ/vz0Mj55rVksrrSskJ1Cm3ESRsbGfQAd12dlG5RJWbAO+LSkYDdguVP+L I= X-Received: by 2002:adf:d006:0:b0:47f:9171:bca2 with SMTP id ffacd0b85a97d-47fec62a14amr17245707f8f.27.1786009281881; Thu, 06 Aug 2026 02:41:21 -0700 (PDT) X-Received: by 2002:adf:d006:0:b0:47f:9171:bca2 with SMTP id ffacd0b85a97d-47fec62a14amr17245608f8f.27.1786009281277; Thu, 06 Aug 2026 02:41:21 -0700 (PDT) Received: from [192.168.188.103] (ip239-44-231-195.pool-bba.aruba.it. [195.231.44.239]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47ff79a7258sm4789418f8f.3.2026.08.06.02.41.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2026 02:41:20 -0700 (PDT) Message-ID: <8b498be8-8b5b-49b0-b20b-71ca8cc277cf@redhat.com> Date: Thu, 6 Aug 2026 11:41:19 +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: [PATCH net-next v2 2/2] dpll: use pin owner's dpll ref for pin-level attribute setting To: Ivan Vecera , netdev@vger.kernel.org Cc: Arkadiusz Kubalewski , Jakub Kicinski , Jiri Pirko , Petr Oros , Prathosh Satish , Richard Cochran , Shuah Khan , Vadim Fedorenko , linux-kernel@vger.kernel.org References: <20260803120245.56046-1-ivecera@redhat.com> <20260803120245.56046-3-ivecera@redhat.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260803120245.56046-3-ivecera@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/3/26 2:02 PM, Ivan Vecera wrote: > Pin-level attributes (frequency, phase adjust, embedded sync, reference > sync) are properties of the pin itself, not of a particular DPLL device. > The get callbacks already use only the pin owner's DPLL reference > (via dpll_pin_own_dpll_ref_first()), but the set callbacks iterate over > all registered DPLL references and invoke the set operation on each one. > > This is redundant because a pin is a single physical entity — setting > its frequency or phase adjust once through the owner's ops is sufficient. > Calling set on every registered DPLL just results in duplicate HW writes > for drivers that share a pin across multiple DPLL devices (e.g. ice > registers each input pin with both the EEC and PPS DPLL, zl3073x > registers input pins with every DPLL channel). > > Simplify dpll_pin_freq_set(), dpll_pin_esync_set(), > dpll_pin_ref_sync_state_set() and dpll_pin_phase_adj_set() to call the > set callback only through the owner's DPLL reference, matching the > existing get-side behavior. This removes the xa_for_each iteration > loops, the now-unnecessary rollback logic, and several local variables. > > The -EOPNOTSUPP validation loop, which checked ops support across all > owner-matching references, is replaced with a direct check on the > single owner reference returned by dpll_pin_own_dpll_ref_first(). > > The documentation in dpll.rst is updated to reflect that pin-level > attributes are set through the pin owner's dpll reference only. > > No existing driver is affected: > - ptp_ocp and mlx5 register each pin with a single DPLL. > - ice registers input pins with two DPLLs (EEC and PPS) using > identical ops and pin_priv; the set callbacks address the HW by > pin index, not by DPLL, so the second call was a no-op. > - zl3073x registers input pins with every DPLL channel; the set > callbacks address HW by pin/ref ID regardless of DPLL. The > ref_sync_set callback was the only one with per-channel behavior, > addressed by the preceding patch. > > Signed-off-by: Ivan Vecera > --- > Documentation/driver-api/dpll.rst | 10 +- > drivers/dpll/dpll_netlink.c | 213 +++++++----------------------- > 2 files changed, 55 insertions(+), 168 deletions(-) > > diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst > index f83150917814e2..6fb50e53475c09 100644 > --- a/Documentation/driver-api/dpll.rst > +++ b/Documentation/driver-api/dpll.rst > @@ -116,8 +116,8 @@ Shared pins > A single pin object can be attached to multiple dpll devices. > Then there are two groups of configuration knobs: > > -1) Set on a pin - the configuration affects all dpll devices pin is > - registered to (i.e., ``DPLL_A_PIN_FREQUENCY``), > +1) Set on a pin - the configuration is performed through the pin owner's > + dpll reference only (i.e., ``DPLL_A_PIN_FREQUENCY``), I find the new text confusing; it seems to me that the pin configuration now affects a single DPLL. Sashiko nipa has several comments, please have a look: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803120245.56046-1-ivecera%40redhat.com and also please be aware of net-next commit c82ff94592fb. /P /P