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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F33DEB64DD for ; Thu, 15 Jun 2023 16:31:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231948AbjFOQbS (ORCPT ); Thu, 15 Jun 2023 12:31:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230452AbjFOQbQ (ORCPT ); Thu, 15 Jun 2023 12:31:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A6AF273E; Thu, 15 Jun 2023 09:31:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C9CE760DEC; Thu, 15 Jun 2023 16:31:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CEB9C433C0; Thu, 15 Jun 2023 16:31:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686846674; bh=Ba6+TbNKPkyuZQ8mwf62Wv9MAIIfwgYKhkFTTivsGpQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=s1YJtKsSZsgntvLLc+qrvnOVQQhDVyH3F6XUy3g5A8+lB7tkTdRFI3SfmMEPNnk2d 2q/dbjFtLd1Aw2jP+9DEG5DJr+pqhO9oDZB/uxcF2Ag9SPFFqhMyVQOcLNBowYe5zE otSbSVgQYUBwvuzaplXlDGaeztZq8Uko8zjAPxzcNLaAZap71zfoM3uM+IZH1ZzGpk vPiyDB406693Cd8DuiuW4R/DhvKZALJwoZQCJLhn4SPvDUpPFajLkjjW1WNATWQwYc WuAgp2ARLHo4SUDQG+4m8QjslVw+NgoWgQbe3ToSAEf0a5zxmY9gHkzcOCCx4XjFwy yuZSApgamUczQ== Date: Thu, 15 Jun 2023 09:31:11 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: "Kubalewski, Arkadiusz" , "vadfed@meta.com" , "jonathan.lemon@gmail.com" , "pabeni@redhat.com" , "corbet@lwn.net" , "davem@davemloft.net" , "edumazet@google.com" , "vadfed@fb.com" , "Brandeburg, Jesse" , "Nguyen, Anthony L" , "M, Saeed" , "leon@kernel.org" , "richardcochran@gmail.com" , "sj@kernel.org" , "javierm@redhat.com" , "ricardo.canuelo@collabora.com" , "mst@redhat.com" , "tzimmermann@suse.de" , "Michalik, Michal" , "gregkh@linuxfoundation.org" , "jacek.lawrynowicz@linux.intel.com" , "airlied@redhat.com" , "ogabbay@kernel.org" , "arnd@arndb.de" , "nipun.gupta@amd.com" , "axboe@kernel.dk" , "linux@zary.sk" , "masahiroy@kernel.org" , "benjamin.tissoires@redhat.com" , "geert+renesas@glider.be" , "Olech, Milena" , "kuniyu@amazon.com" , "liuhangbin@gmail.com" , "hkallweit1@gmail.com" , "andy.ren@getcruise.com" , "razor@blackwall.org" , "idosch@nvidia.com" , "lucien.xin@gmail.com" , "nicolas.dichtel@6wind.com" , "phil@nwl.cc" , "claudiajkang@gmail.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "linux-rdma@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , poros , mschmidt , "linux-clk@vger.kernel.org" , "vadim.fedorenko@linux.dev" Subject: Re: [RFC PATCH v8 01/10] dpll: documentation on DPLL subsystem interface Message-ID: <20230615093111.0ee762e4@kernel.org> In-Reply-To: References: <20230609121853.3607724-1-arkadiusz.kubalewski@intel.com> <20230609121853.3607724-2-arkadiusz.kubalewski@intel.com> <20230612154329.7bd2d52f@kernel.org> <20230613093801.735cd341@kernel.org> <20230614121514.0d038aa3@kernel.org> <20230614122348.3e9b7e42@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 15 Jun 2023 12:18:28 +0200 Jiri Pirko wrote: > Yeah, that is what we had originally. This just pushes out the > different attr selection from the nest one level up to the actualy > nesting attribute. Oh no, no extra nesting. Let me try to fake up the output: 'pin': [{ {'clock-id': 282574471561216, 'module-name': 'ice', 'pin-dpll-caps': 4, 'pin-id': 13, 'parent-device': [{'pin-id': 2, 'pin-state': 'connected'}, {'pin-id': 3, 'pin-state': 'disconnected'}], 'parent-pin': [{'id': 0, 'pin-direction': 'input'}, {'id': 1, 'pin-direction': 'input'}], 'pin-type': 'synce-eth-port'} }] > One downside of this is you will have 2 arrays of parent objects, > one per parent type. Current code neatly groups them into a single array. > > I guess this is a matter of personal preference, I'm fine either way. Yeah, could be.