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 A7C70C77B7C for ; Thu, 4 May 2023 11:15:37 +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=u6rvRDYIB4ApAHRsfh3oDdFzNs/HanphzKet6FlI9Yg=; b=rjvW/OKynB+19e /6Es+eulyYZfzCGUCs01HZvNmrm7Dtf9HelZI+L9jS+XJ060OA3gwkvQtrHuXmIShWOENzjOLs3or ASYEgko9S6X5TFFWBVxZ/ATHe2/xKnkPXHCxr1aR4iaz4iA63T8Idg5BzE2UZfU1DN85lk9qEZS+o TOxdqVN4V5uS3FEJIB6UBwujIZEjN6+Atyj9yi4guodw3DjVj5oZEcAQjbEUZEZyRFjynBnRH7PIE 3WJ1gkqFjPZrQFWZ22Sh1bU/v+udEn55Y2hgZPt88MyW9A/Rn0fRSc6CYCEGJsAAtNk+BxSMQ54Dl 2FNeJ6hmZTKbv7KONsaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1puWus-007cX9-1M; Thu, 04 May 2023 11:14:30 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1puWuq-007cWT-0t for linux-arm-kernel@lists.infradead.org; Thu, 04 May 2023 11:14:29 +0000 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-30639daee76so214071f8f.1 for ; Thu, 04 May 2023 04:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1683198865; x=1685790865; 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=PUa05Tm/5AD86rND95WZHUr+PT5uRa9QsOrn0+SQoe4=; b=FNrcp8eahY9HHQAPrOgE2l3jAoEftR2Qknbq5yzRzzIUIAFx3S8UYtGuYvyHSs3d1Q Wu23bwG/gQPhj19eBHus6zkVE8PogGJ48pXiWcVb7wzQ/O+UImiQfq/ug2TabGweL5Xr e/g7lIsR88buuDlgb/o9V8l0zZRrOHujpWoJKnvAZWrYlYrXlVhhMdNWY3LqFwgNbo04 edoAYMRQVGAiZOhQxa9biNJOTD4BlVf0wjMeWVrdzu2SYrKt9YRuNhtkiHT4jKPlRk7P NYaHV3lRr5axoeVEnnsavGi82lcY366W0bS8vpCJNUQtkROgPyXHEeKPfRDSpNt5y2m2 JTqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683198865; x=1685790865; 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=PUa05Tm/5AD86rND95WZHUr+PT5uRa9QsOrn0+SQoe4=; b=PwrRfwIUFGdcnNg4Y9edxhuKmwH9S/ZM701o8hQh4GtrvMz82wmeqo3oDNK4H9ugdo DhfenS1gEJ8+4kg9FuxDsq6py5r/0kN+DZ7eZJOnzbrljO8bETr4+cly3P5XCei4Cpxr TQqVoY7jto4at8iNUXG99zgfu4jUErZpiplC8/WRuuPBumRiuBDjsLsTAIPndTv8ka1z VcEdHObXVK9PwrTWWs/lBTbNNSzyoRt8Ejcp4w96DmZrb9f80f1DZVGLfI1dgIheofi1 VvwExat7MBaLkEvhA/DVv50SvW5TdXl+xDPewzjstW3DF5pyC7GcmcrwxX+ATwcWnxXj l/Yw== X-Gm-Message-State: AC+VfDw9QS8wqMtio5mz9qjV8qgxxuruYQvSQ4ob+OkmNq+Ld9sLdTm1 WiNPp2EsHWGP+bGZHR8P603q5w== X-Google-Smtp-Source: ACHHUZ5HJnCkhVQ11dRZ+saw0vpjw8c6PMeCja53U+LDrpNNXXiocrze1hQAaIb3Oks6llFH6BLBVw== X-Received: by 2002:a5d:558b:0:b0:306:3bf0:f1ec with SMTP id i11-20020a5d558b000000b003063bf0f1ecmr2498018wrv.7.1683198865228; Thu, 04 May 2023 04:14:25 -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 k9-20020a5d6e89000000b0030629536e64sm12715926wrz.30.2023.05.04.04.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 04:14:24 -0700 (PDT) Date: Thu, 4 May 2023 13:14:23 +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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230504_041428_313486_6668671D X-CRM114-Status: GOOD ( 20.57 ) 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 01:00:42PM CEST, jiri@resnulli.us wrote: >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 Sorry, I hit the send button by a mistake. I ment to add a question here: What is the next intelligible element to identify DPLL device here? > <- DPLL_A_ID > >CMD_GET_PIN_ID > -> DPLL_A_MODULE_NAME > DPLL_A_CLOCK_ID What is the next intelligible element to identify a pin here? > <- 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