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.129.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 A1FB22DE70E for ; Thu, 3 Jul 2025 10:45:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751539551; cv=none; b=XPIsoL/oz8+txqFHYSFqgs6lVb+0FOzaTOr7S2u5sY45DkIudVoFO7/ym24M/VgqWvHHqUrltKB3KLTDuaoXqB6NGLNwbMc/WBRBnNLWWtAYZSKKP9kOOG5HDRO2SnSXL5K+95bNHpxw7BKr0OSOf95NQMGHQSWm3dh7G1/iLag= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751539551; c=relaxed/simple; bh=fQE+5wsG11YS+T16ysk2VHcVH59OjcsASzwX63bw1bQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EGFv/+Ftfqv6FjbX248+YZJx5eQg6HBrIWs3wLVwqMlonWlspvnmtwKEJJJm9tQUGHruCGnpKwIByqSK2ubisdDFC24IkGfYp2CiV+sHBla3hsX5efQojcfv6zap4woXkPCZC6o6VgvE+4Fp3Cltoqvr/FRZNbfDzuoHYOgovOE= 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=jI/0cwde; arc=none smtp.client-ip=170.10.129.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="jI/0cwde" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751539548; 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=GUAC4unCPdf21xFptJklILQwlIlcc2Ln7uhZkroI42M=; b=jI/0cwderleVW45Hvc7KMMwUOvFodGu+6zarHRNL6q2+MTbWG1ZOglEKqrtSh85Ik+PQzH fqEt6dCbFA8DCzpdJDMTKyojRHE9VD8ZhEiAksQOUAbXskzn/lslLZd1VK2rqHVFO4hnCS ps8aMmO5RcWBJZkgumBZLr7GmoqLVJY= Received: from mx-prod-mc-04.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-615-hYeNvljEMjiFajHn7MFhSA-1; Thu, 03 Jul 2025 06:45:43 -0400 X-MC-Unique: hYeNvljEMjiFajHn7MFhSA-1 X-Mimecast-MFC-AGG-ID: hYeNvljEMjiFajHn7MFhSA_1751539541 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B9D5E190FBCC; Thu, 3 Jul 2025 10:45:39 +0000 (UTC) Received: from [10.45.226.37] (unknown [10.45.226.37]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CE83D18FFC66; Thu, 3 Jul 2025 10:45:32 +0000 (UTC) Message-ID: Date: Thu, 3 Jul 2025 12:45:31 +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 v12 07/14] dpll: zl3073x: Add clock_id field To: Jiri Pirko , Krzysztof Kozlowski Cc: netdev@vger.kernel.org, Vadim Fedorenko , Arkadiusz Kubalewski , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Prathosh Satish , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Jason Gunthorpe , Shannon Nelson , Dave Jiang , Jonathan Cameron , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Michal Schmidt , Petr Oros References: <20250629191049.64398-1-ivecera@redhat.com> <20250629191049.64398-8-ivecera@redhat.com> <4f2e040b-3761-441c-b8b1-3d6aa90c77fc@redhat.com> Content-Language: en-US From: Ivan Vecera In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 On 03. 07. 25 12:09 odp., Jiri Pirko wrote: > Wed, Jul 02, 2025 at 04:51:47PM +0200, ivecera@redhat.com wrote: >> On 02. 07. 25 2:01 odp., Jiri Pirko wrote: >>> Wed, Jul 02, 2025 at 01:43:38PM +0200, ivecera@redhat.com wrote: >>>> >>>> On 02. 07. 25 12:31 odp., Jiri Pirko wrote: >>>>> Sun, Jun 29, 2025 at 09:10:42PM +0200, ivecera@redhat.com wrote: >>>>>> Add .clock_id to zl3073x_dev structure that will be used by later >>>>>> commits introducing DPLL feature. The clock ID is required for DPLL >>>>>> device registration. >>>>>> >>>>>> To generate this ID, use chip ID read during device initialization. >>>>>> In case where multiple zl3073x based chips are present, the chip ID >>>>>> is shifted and lower bits are filled by an unique value - using >>>>>> the I2C device address for I2C connections and the chip-select value >>>>>> for SPI connections. >>>>> >>>>> You say that multiple chips may have the same chip ID? How is that >>>>> possible? Isn't it supposed to be unique? >>>>> I understand clock ID to be invariant regardless where you plug your >>>>> device. When you construct it from i2c address, sounds wrong. >>>> >>>> The chip id is not like serial number but it is like device id under >>>> PCI. So if you will have multiple chips with this chip id you have to >>>> distinguish somehow between them, this is the reason why I2C address >>>> is added into the final value. >>>> >>>> Anyway this device does not have any attribute that corresponds to >>>> clock id (as per our previous discussion) and it will be better to NOT >>>> require clock id from DPLL core side. >>> >>> Yes, better not to require it comparing to having it wrong. >> >> It looks that using clock_id==0 is safe from DPLL API point of view. >> The problem is if you will have multiple zl3073x based chips because >> the driver would call dpll_device_get(0 /* clock_id */, channel, module) >> >> For 1st chip (e.g. 2 channel) the driver will call: >> dpll_device_get(0, 0, module); >> dpll_device_get(0, 1, module); >> >> and for the second the same that is wrong. The clock_id would help to >> distinguish between them. >> >> Wouldn't it be better to use a random number for clock_id from the >> driver? > > I take my suggestion to not require it back, does not make sense. > > Clock id actually has a reason to exist from UAPI perspective. Checkout > dpll_device_find_from_nlattr(). The user passes CLOCK_ID attr (among > others) to obtain device by DPLL_CMD_DEVICE_ID_GET command. He expects > to get a result back from kernel regardless where the device is plugged > and across the reboots/rebinds. > > Clock id should be properly filled with static and device specific > value. If your chip can't be queried for it, I'm sure the embedded world > has a solution for such cases. It's similar to MAC of a NIC device. Yes, there are such cases and for such devices 'mac-address' property can be specified in the device tree. For our case I could extend the dpll device schema to include 'clock-id' or 'dpll-clock-id' 64bit property to allow specify clock ID for the devices that are unable to query this information from the hardware. Krzysztof, WDYT about it? Thanks, Ivan