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 4E6B3C77B78 for ; Thu, 4 May 2023 17:52:49 +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=S6GbJ3bU01z3Lr+kCq0v1XYABPNtU9hH9WRZDGfTlYM=; b=Ncbwz4QxeL/hN/ pX4AS4gBhAon+3rSDwDTvTDyk4FQY5JojGEVmWAJxmpoVs58Rsf8ojhXExVcmqW5FfhYVfhe/DbJA pUtokYzLseG8oKd2POy2oGI0feE7NS78y1YDutpPHgsUcfGCW3RI/tWEY7I1JQ6JuJETm0EreYwa/ vDEjAVDWjBsy5AF0RAR8zcIIs6aKs9kI3BJ8fJWe4wuYDKm4nXQsycWK/dHH8JiDXsfgrzDSTyeqJ VcSFdbDe4Kzr59qanIBBwlmV2rGsdLr3FWHG4WNmVzULxTRRiA15TkH17klr/oFR8cMN3DT3adwtx 7xutZyNdgcK/BjyKIKUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pud7P-008Sxm-0x; Thu, 04 May 2023 17:51:51 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pud7I-008SxF-35 for linux-arm-kernel@lists.infradead.org; Thu, 04 May 2023 17:51:47 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2a8c30ac7e3so9734781fa.1 for ; Thu, 04 May 2023 10:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1683222701; x=1685814701; 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=O45EJsoDq0FqmHnerFViZl2wgrujScPaI15rEDqYMNE=; b=uFlPsO8rOXvRxLzCv8wu8QfDcuqRrwfKuf1HallJvCJGOewFVvgFbHzxus9dZORTyM dI/tqMDT+drHp2aGr0LMvK0AjH9nMQKVEpN70NfP0/9zVCT7EZDZnVLFAPqNYM0qGjWH kNnbG1xtu7iWY5T/O6JkdvO3xxRG0EvdrI4sSXknRaLDsUmPTX0pgBIK1IfFBSW+kdsY nyMUaSYyqM5Olpv8RHQtMW4qTBkYjFtsyAzXVnpFMpzVlR3i/awvRa6SJ67n6fazIIgr CndOZAOkaKFUG6yu4hSltD/I70enaaPBKq1BGP2jPyLunGzVa4GXVn4s1a1s6ForQW1/ 2NHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683222701; x=1685814701; 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=O45EJsoDq0FqmHnerFViZl2wgrujScPaI15rEDqYMNE=; b=MEBjhthl6cBD7VNjEKmeQXuNHrqD1NuYj1TSY6HRbIX9CDaqdM1IDFF8eTHsca/Pa7 M34Y/kRfxFnKn+HK6hwue81rmOlamwqbrIaYBLLC1i2ExB3uk3e5CX57GPHPeF/R7UEc CDxKaklzEqvF8eXNUEONmhkzWbzqVOPgpr412PSnCmfaExcgGQF7oe1C9XAcFGi8CQPh XWDw+qjEErtSOPiEK8ma0Fy4q7Gf6l5cwJqN2jBUplb41/qD69jtxI6gdQ/lk5e0bzQ2 3NZ3UPzuf8yv8etz5kWi9Eaa+4G/FdUfPO+vPUFPZ3FlKc/I3xrqqNWzdsOKJlqjXZJO 9ElQ== X-Gm-Message-State: AC+VfDwphb3vW6u116xfxWBe7OlhKdQJbVGr4IM9UizOrLGzg4wrH6xj 21lDj/UgvE/rbrF4yOjkBK26zQ== X-Google-Smtp-Source: ACHHUZ7OfjupDiodfS/3ZFemfNnPjusNOrEf4cKdOHZtq3CRyMql0W2cUpmGdNjebY8nBN9KSOf/MA== X-Received: by 2002:a2e:2403:0:b0:2a7:7259:9587 with SMTP id k3-20020a2e2403000000b002a772599587mr1111040ljk.46.1683222701245; Thu, 04 May 2023 10:51:41 -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 i3-20020a2e9403000000b002a8b5310642sm6707037ljh.5.2023.05.04.10.51.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 10:51:40 -0700 (PDT) Date: Thu, 4 May 2023 19:51:38 +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: <20230410153149.602c6bad@kernel.org> <20230417124942.4305abfa@kernel.org> <20230502083244.19543d26@kernel.org> <20230503191643.12a6e559@kernel.org> <20230504090401.597a7a61@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230504090401.597a7a61@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230504_105145_219981_F41CA955 X-CRM114-Status: GOOD ( 28.71 ) 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 06:04:01PM CEST, kuba@kernel.org wrote: >On Thu, 4 May 2023 13:00:42 +0200 Jiri Pirko 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: >> >> 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? > >Yes, my suggestion did not include a scoped index with no >globally defined semantics. Okay, makes sense. Devlink port index didn't end up well :/ > >> >> 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 > >> What is the next intelligible element to identify DPLL device here? > >I don't know. We can always add more as needed. >We presuppose that the devices are identifiable, so whatever info >is used to identify them goes here. Allright. So in case of ptp_ocp and mlx5, module_name and clock_id are enough. In case of ice, DPLL_A_TYPE, attr is the one to make distinction between the 2 dpll instances there So for now, we can have: CMD_GET_ID -> DPLL_A_MODULE_NAME DPLL_A_CLOCK_ID DPLL_A_TYPE <- DPLL_A_ID if user passes a subset which would not provide a single match, we error out with -EINVAL and proper exack message. Makes sense? > >> <- 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? > >Same answer. Could be a name of the pin according to ASIC docs. >Could be the ball name for a BGA package. Anything that's meaningful. Okay, for pin, the type and label would probably do: CMD_GET_PIN_ID -> DPLL_A_MODULE_NAME DPLL_A_CLOCK_ID DPLL_A_PIN_TYPE DPLL_A_PIN_LABEL <- DPLL_A_PIN_ID Again, if user passes a subset which would not provide a single match, we error out with -EINVAL and proper exack message. If there is only one pin for example, user query of DPLL_A_MODULE_NAME and DPLL_A_CLOCK_ID would do return a single match. No need to pass anything else. I think this could work with both ice and ptp_ocp, correct guys? For mlx5, I will have 2 or more pins with same module name, clock id and type. For these SyncE pins the label does not really make sense. But I don't have to query, because the PIN_ID is going to be exposed for netdev over RT netlink. Clicks. Makes sense? > >My point is that we don't want a field simply called "index". Because >then for one vendor it will mean Ethernet port, for another SMA >connector number and for the third pin of the package. Those are >different attributes. Got you and agree. > >> <- 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. > >That's fine, I guess. I'd prefer driver matching to be the same as user >space matching to force driver authors to have the same perspective as >the user. But a "driver coookie" not visible to user space it probably >fine. Allright, lets leave them for now. As internal kernel API, could be changed in the future if needed. Arkadiusz, Vadim, are you following this? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel