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 55D11C77B78 for ; Thu, 4 May 2023 11:02:06 +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=nP11nNkh9F7d+yhs204QsF2UVZx88rM5qBD6dAtrgUQ=; b=2riIRPdjwE4oPT qvs8Jk3VTl2nhTM7ziY7CfSwPsgw0tJOtQjW1HtklbsJZ1xpEJ5fSOuIPcewdZisSN8Edzi13ZY4e JLW6SyMPqD4eJ9NxNC3gZZS7dPJv2wX81OsbkBgH4pEChbCJ2a63c7/v9C7sWVzvgOCpe70WEmuY5 gzgvXALxxnLSuVdwKctSTnQnEGkLMJhPLoHnAOFhtkqZ40wYgAmYsikKVY6ee8ClVNXiy+jjqcn6t hG2NiDaUABZtp3nJFDQ/k2xfvNJ9mM+u6TVGoUGn5IA9zsxAmaA6a404CbdcOinY2KxFYI4p2QcMS rM9B2J13JTdQoDW2yeVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1puWhi-007aaO-0p; Thu, 04 May 2023 11:00:54 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1puWhd-007aZP-0x for linux-arm-kernel@lists.infradead.org; Thu, 04 May 2023 11:00:53 +0000 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-3f1738d0d4cso2440035e9.1 for ; Thu, 04 May 2023 04:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1683198044; x=1685790044; 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=5AbvHIm13pUXGDUyW2ngqVKs0jOuzsuSmuOEczfa29c=; b=rvcyw62eFefV9eX4VUnpGOtV+I+5zhwnu4Lno69aVf/xs+EYJKgRhkngvEoo3IZh2M 6GrCE1Xho8iZKWj3nJNkMh3g9sclv743pjWidbmp6fTJZq7O0Vn1UdxDvu7qj2SNfyos BEJ2SN+c+U3+Z264N+jxVjOwtXM3AweOvEVDqTBmNRqeZ2SRFw5IBXf5qWxIxJH2/1yC a2ygRQx9hxj5I+ff/CidfG1l8VT9eV3/I49+ri9JZJeS3U3nUKVzffC33TR/mpxmirxB dyT3paIkXTvM0rLc82m+yd9Xg+ksGw+KuGOk6RbAw9+3OE9/FtcL5vr30e/uEiW2oTIa 87Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683198044; x=1685790044; 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=5AbvHIm13pUXGDUyW2ngqVKs0jOuzsuSmuOEczfa29c=; b=in+5zl9LtpNIscqUcWw0Cv+WVzuUp4Su6/PES9Vsja1Q3oAQarzTKzq0GWoBZfEgOv 14ss4lG83ec+k4XZWoBFt+rXdxgsSy6Spw7uR/0y1JBAewPBO0NmbOcd1QH3m0/w8TS1 31Ht/l4y4q2F59H6Rn9oy5cU6NwZuYTwrQM0P2rWE5a9ZCmYKUARm7B/uM1xmU/rWGPn FVIUxuaRkJqNM9gTYvmfp6tLZ6bJzTA+deIvfntW4XEzYO52VbmzR+NPxBDgOl8P5F3+ Vb76oBVRngqy86sjSxN5dmkDxatgZXumyl68A8bZphJNn1O/HKMzEc0ZmRaXr0wY8ozk oQuw== X-Gm-Message-State: AC+VfDws6l9t7wkHiwQvUdKasWVX6XHX8Ml30uD7ks0BZJKMR++7Hxid MrM1vap7lPbAcLcnruBvxzIdSg== X-Google-Smtp-Source: ACHHUZ7Xt8Q8wHgW0dOVY4B3WuZrnKey2oMRQtWw1LOL0mJs55ReMKmVqK6biI5XJRsg6qM0U0+naQ== X-Received: by 2002:a05:600c:214e:b0:3f1:7277:eaa with SMTP id v14-20020a05600c214e00b003f172770eaamr17156472wml.31.1683198044365; Thu, 04 May 2023 04:00:44 -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 m20-20020a7bce14000000b003f3195be0a0sm4560383wmc.31.2023.05.04.04.00.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 04:00:43 -0700 (PDT) Date: Thu, 4 May 2023 13:00:42 +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> <20230503191643.12a6e559@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230503191643.12a6e559@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230504_040049_575974_0EEBC860 X-CRM114-Status: GOOD ( 19.78 ) 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 Thu, May 04, 2023 at 04:16:43AM CEST, kuba@kernel.org wrote: >On Wed, 3 May 2023 09:56:57 +0200 Jiri Pirko wrote: >> >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. > >No scoped idx. That means, no index defined by a driver if I undestand you correctly, right? > >> 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? > >Sure, we don't _have_ to have an ID, but it seems go against normal >data normalization rules. And I don't see any harm in it. > >But you're asking for per-device "idx" and that's a no-go for me, >given already cited experience. > >The user space can look up the ID based on identifying information it >has. IMO it's better to support multiple different intelligible elements Do you mean fixed tuple or variable tuple? CMD_GET_ID -> DPLL_A_MODULE_NAME DPLL_A_CLOCK_ID <- DPLL_A_ID CMD_GET_PIN_ID -> DPLL_A_MODULE_NAME DPLL_A_CLOCK_ID <- DPLL_A_PIN_ID >than single integer index into which drivers will start encoding all >sort of info, using locally invented schemes. There could be multiple DPLL and pin instances for a single module/clock_id tuple we have to distinguish somehow. If the driver can't pass "index" of DPLL or a pin, how we distinguish them? Plus is is possible that 2 driver instances share the same dpll instance, then to get the dpll pointer reference, they do: INSTANCE A: dpll_0 = dpll_device_get(clock_id, 0, THIS_MODULE); dpll_1 = dpll_device_get(clock_id, 1, THIS_MODULE); INSTANCE B: dpll_0 = dpll_device_get(clock_id, 0, THIS_MODULE); dpll_1 = dpll_device_get(clock_id, 1, THIS_MODULE); My point is, event if we don't expose the index to the userspace, we need to have it internally. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel