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 32D1DC77B75 for ; Fri, 5 May 2023 10:42:14 +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=2HHUD36nWtjluETIzLlfw3xm/7KfoOkSuGAEXny9kH8=; b=SxGdzX644TWZeZ W1aJmuSFYT0cRF39Al8xYGkL2jyngnQH8QvPFU2u0cb2VKFQH/Cb/YOMXAZmXP+mAsVzmgimMyJnv UENo0CMvPV4mFdD6RUTJpijEm68rl3HfspeIFBgZXLJy2u33eOPT4RWjnbeIT+1QZLCxUAfnBia3T 2tvO3x6FRr7YBS5tXsKnpfG82m7kMSaVNJ9+mPMKzGl3QVS6TrvHZXyJczfHWuAVLzp7ebrTN/35z uzVexVOYru6yrbmeUkl/7C5N7o4o+wYnJburGNk+PB0bmKTHzt5UioQl7v55CW22WiQDfHZPn9GIR bjmU5Rk8HPWeVoWOY6ng==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pussK-00AP3X-2p; Fri, 05 May 2023 10:41:20 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pussH-00AOyw-38 for linux-arm-kernel@lists.infradead.org; Fri, 05 May 2023 10:41:19 +0000 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-30771c68a9eso1110616f8f.2 for ; Fri, 05 May 2023 03:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1683283273; x=1685875273; 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=2Nq9FdkBIx7qSryTVXqkeom+1RISA8nreL8gl42Y7iA=; b=aRXM1GWidgf8Okv7zsy+p23RkW4A7VS9PvC9GNkHVM3zrKKuhdA2WkYNRci3aNhwti WS7qBTTCy31SYNrRXFqkRKGQU4QuBkK1BtB4cb+NwGYLXUFmKFtCdYhA1WHAzQODEYTT cHvO55vJwuUBRrbCbmHny5TfPxwFP6tFvsZzwDQ7agH8+f1z6d/Tx5jVq2PdmCLR14Cz el85dxokm3LC+zxDGH+INLa5KqWsBi7eLfkpWesxin9bQZBMlWxG4BTGwBaKIt6Sp/y6 RcRlTJynem2WpOKg7R8VDezVZAM/w8Y7smGK0K6mm2C8UThkycRNNcPJMgoQ23AIhWgA v5UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683283273; x=1685875273; 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=2Nq9FdkBIx7qSryTVXqkeom+1RISA8nreL8gl42Y7iA=; b=XdJzQfVOuygv7RjO8nxVanYYINK/HtQdCnIecCG55O2QhUpqU+d3+3mszUF4tKO/j0 AhGOvlINrxb69Y3udW01Wsrs2DNRhpq8KNHUIZTGolD/E51uVDA4rT66ZMuAApXCfjW/ RRdKM5Aa70A/FPvC2s7S98wsQVBb28sBvPESTaTWdiKxqyPZsxA/sATIrjwmYPvVon4s PlG9EzO5uiAoDtIV1ML6/xBqKekbZBOTOPCYFib+QCnknAgPpFnVOrb2fVMO/eCHeuW2 n+J5fVbgWRquxjotEgMBFY9o23DnZCcLI/hlGqJy5utO4ycn1JAmIelNfQP0Ys8Zz6Z/ fuVQ== X-Gm-Message-State: AC+VfDxaRfi7QA/BkGPKit+WPZYbmE+JqH5rCKLV2LQtbD5qgZChQGwq YPNfzdMrJb+jlBhtNTXq1IRrBg== X-Google-Smtp-Source: ACHHUZ5N1BYv2fq0cH1ZrnOoRhp0jMNO3Sek0h8iGuMTIFGDHe5roWYot3NxaGP4Kg3ciiwxq4JcMw== X-Received: by 2002:a5d:4c8c:0:b0:2f5:3dfd:f4d2 with SMTP id z12-20020a5d4c8c000000b002f53dfdf4d2mr1102918wrs.64.1683283272788; Fri, 05 May 2023 03:41:12 -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 f16-20020a5d6650000000b003062c0ef959sm1993670wrw.69.2023.05.05.03.41.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 May 2023 03:41:12 -0700 (PDT) Date: Fri, 5 May 2023 12:41:11 +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: <20230417124942.4305abfa@kernel.org> <20230502083244.19543d26@kernel.org> <20230503191643.12a6e559@kernel.org> <20230504090401.597a7a61@kernel.org> <20230504114421.51415018@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230504114421.51415018@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230505_034118_007448_F4CB6AE4 X-CRM114-Status: GOOD ( 20.81 ) 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 08:44:21PM CEST, kuba@kernel.org wrote: >On Thu, 4 May 2023 19:51:38 +0200 Jiri Pirko wrote: >> >> 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? > >Yup, that sounds good to me. > >> >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 > >Label sounds dangerously open ended, too. Would that be the SMA Well, every string is. And past RFCs of this patchset demonstrated guys did serialize a lot of stuff in strings. >connector label (i.e. front panel label)? Or also applicable to >internal pins? It'd be easier to talk details if we had the user >facing documentation that ships with these products. I think is is use case specific. Some of the pins face the user over physical port, they it is a front panel label. Others are internal names. I have no clue how to define and mainly enforce rules here. But as an example, if you have 2 pins of the same type, only difference is they are connected to front panel connector "A" and "B", this is the label you have to pass to the ID query. Do you see any other way? > >> <- 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? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel