From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id ABD89C77B7F for ; Wed, 3 May 2023 07:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UVzKbQYEvLSU45eRB78AeCLasqrlQIvfyQe1WpRerdo=; b=GSi0PqXhVZk79Z 6Eni2uwTGXsb8ojAo+zE5IfjptRSXXEcQBD7y5IGCUIgLHPj4BASzlbaXLBX/3vhlKxIqKIvw8GYS U03MZe6mT0eyTmdp8AXrCNc1TEkiP3DbwgStDVY7FITDoGIIE+piU3sfeKq6tbrWc9ST9dvl7nvt0 mokOZPoCSHzrIDJll+TAvMpafa5peKYngfrNAClsuy1Ne4fCZy0T6ZWBvbJgW7zx6mJwQjLa6Ja8u zdVUVC+47zzAiKdzgX1cnYV0ffzv83sHOiEQhykLkzkmUn0Fyu9s8W86i7bGLf++nfVkjUfk2Wbcm 5Ty1azOxMygQ/okwm5Sw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pu7MH-003j8S-2K; Wed, 03 May 2023 07:57:05 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pu7ME-003j7m-2Y for linux-arm-kernel@lists.infradead.org; Wed, 03 May 2023 07:57:04 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-50bc4bc2880so5316078a12.2 for ; Wed, 03 May 2023 00:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1683100619; x=1685692619; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pcYFfZqejHZcwp6Yf370vPWTJUqUejy/+clrmToxzqI=; b=olDiilzCabAGiFawMWw7motGsETub6lHxM/WovTgYKHi1YXDv/jO0fLpvUPxuI6SEY AnJmrxUvXv74KkirN14i5EkJD0o/00UrFAs12SeFh0qIFrPGsbycIoSXNCo8DUVB/Fej SH1mxGk1GfOWpqzCsKZSRcxVnPEcLEPDccLXVaS0Sp+EEkrt5z61aKH23a7Fv8pqdDVL +6zDalgXJBKwh0eoXNcwLGPomF+uen0Zx0CqOjGOdDbn2u4gsy7Hj3UMqDNpzUG1bV34 D8ADLZTOPFVd/TEJO1P+5ptI5y0v9z+ipJx5bfJIu74uSUa7mCQYT8sprl7AzZy2WWOS m8ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683100619; x=1685692619; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pcYFfZqejHZcwp6Yf370vPWTJUqUejy/+clrmToxzqI=; b=OZvEU7SYZBAmiT8yVS58iy5kLZr+xk48GeALWNlfhmq7Gx0bSAhhhHZWULzY9I3wOT 0ZHFWA/F1ud1zBIy+27UnI0JvWG48tRrrKQjbT98NZxb544zgpD1oMcPjj0KPdlDI/3d Saohac1LV7VoxG8qDHR4x5cALt9+JnJkdYdgOQzafZuu3dYW3TdsL08pKVxKtvyo0sqv hxMKqnzX2qntn55hiV0DBLPV6R3slNgqcobFHCiTSNI7KUOCntJJdf9FOroScWyFwFtQ 2zRmObIyTKPhFpSEWdRw2U+Y7WxOusWxdxd1i/WLIiDb67hXQV9mFfGLalhGLcGGdjvW 8e6Q== X-Gm-Message-State: AC+VfDyodymSHKkaE4F6t4M2Mev6+3rm2v31lziOo5WStqaqMIMcuqVk PPwto14xzZf7bsMNLBMkUYi4GQ== X-Google-Smtp-Source: ACHHUZ75tPCKlOQ/bn/9cUaJxhFluM9jLzpY4mk18g4A1GcSnQv350qD16SCW+v0l8wSswuicKZcUg== X-Received: by 2002:a17:907:9724:b0:962:582d:89d7 with SMTP id jg36-20020a170907972400b00962582d89d7mr2527333ejc.38.1683100619256; Wed, 03 May 2023 00:56:59 -0700 (PDT) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id g22-20020a170906595600b0094ed3abc937sm16841404ejr.82.2023.05.03.00.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 May 2023 00:56:58 -0700 (PDT) Date: Wed, 3 May 2023 09:56:57 +0200 From: Jiri Pirko To: Jakub Kicinski Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , poros , mschmidt , "netdev@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, "linux-clk@vger.kernel.org" , "Olech, Milena" , "Michalik, Michal" Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions Message-ID: References: <20230403111812.163b7d1d@kernel.org> <20230410153149.602c6bad@kernel.org> <20230417124942.4305abfa@kernel.org> <20230502083244.19543d26@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230502083244.19543d26@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230503_005702_833180_08BE6989 X-CRM114-Status: GOOD ( 16.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Adding back the cclist stripped due to Claws bug. Tue, May 02, 2023 at 05:32:44PM CEST, kuba@kernel.org wrote: >On Tue, 2 May 2023 10:52:57 +0200 Jiri Pirko wrote: >> >> Index internal within a single instance. Like Intel guys, they have 1 >> >> clock wired up with multiple DPLLs. The driver gives every DPLL index. >> >> This is internal, totally up to the driver decision. Similar concept to >> >> devlink port index. >> > >> >devlink port index ended up as a pretty odd beast with drivers encoding >> >various information into it, using locally grown schemes. >> > >> >Hard no on doing that in dpll, it should not be exposed to the user. >> >> So you say to have ID fully dynamic and non deterministic? I'm lost a >> bit. > >Yup, non-deterministic, just a cyclic ID allocated by the core starting >from 1. Finding the right device / pin needs to be done via >informational attributes not making assumptions about the ID. Okay. When netdev will have pin ID in the RT netlink message (as it is done in RFCv7), it is easy to get the pin/dpll for netdev. No problem there. However, for non-SyncE usecase, how do you imagine scripts to work? I mean, the script have to obtain dpll/pin ID by deterministic module_name/clock_id/idx tuple. There are 2 options to do that: 1) dump all dplls/pins and do lookup in userspace 2) get a dpll/pin according to given module_name/clock_id/idx tuple The first approach is not very nice. The currently pushed RFCv7 of the patchset does not support 2) Now if we add support for 2), we basically use module_name/clock_id/idx as a handle for "get cmd". My point is, why can't we use it for "set cmd" as well and avoid the ID entirely? What am I missing here? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel