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 A5893C433EF for ; Sat, 2 Jul 2022 19:21:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229534AbiGBTV6 (ORCPT ); Sat, 2 Jul 2022 15:21:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbiGBTV5 (ORCPT ); Sat, 2 Jul 2022 15:21:57 -0400 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF6A9DFBF; Sat, 2 Jul 2022 12:21:54 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id r14so1927802wrg.1; Sat, 02 Jul 2022 12:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version; bh=ShPrvMVvs0iuePdOh13YlEW0US0KOGLiiTqD4zGCiNY=; b=h+Qdn99o3gPmJiMNYJ8IJgMULL3Pew0pTISs4L2CeQQnyvSsIZ8aznyCoGBS9BGYi2 FxoO0AWZPRTt6nxQGAahmwr7IMbhBVnRJnEMhHkqtBMLFQqsvvwM4Y+V7FeGyZOeeYBl mU9ZNByXO/UBhWkBUwLVlvM3AZ9KDIVq3CgNvYnaAkQPdPJXkC7mWyoTOb6y3VVcwhZK gpUYPWYZA5ChcrdsKSH7aQlCviSaRTFlOtm51v28waZ83qHW/aOEV30Sr/+RCL4Dxrdg T0V+G3YJHKHvZascKcwihEUX5TYVWMoK5B1QPlLHldc0QlJrbWuKZQ72ONJF7YtLldPs TZLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=ShPrvMVvs0iuePdOh13YlEW0US0KOGLiiTqD4zGCiNY=; b=rqeYQ0D/XcZ5vRXDdiJR9ByRan5mx9TANWyWLU+XkC9SdYH/AmwxN5R5HKrAzonOk8 Ol/DLlZz4fv8zcBaeqXhkx4P+Zjq9KQHj2yP2az6sac04jCxA/durDumvKuip+iWpXEY p2PEQCdh+ZdeG9YL7Th8CVcaD3EvevEnJorNB/wt0LVfi4l1AVXTnodEbo9FqPcL/b5i BTKk9boaJE2QgkeTuuClKcaiMpv2GrClA4C1Y/Mzx+pLmPh11B6oOTFe+iFl3Bf4l4S9 PmkJk5FKH4KH1qcK4dMM8b+Hpz35tOrzRq+GQSV7Fyf7dki+75ILJcIBn+zoSIrqm2BU F/qQ== X-Gm-Message-State: AJIora8zXiEqmlA5WPZGBkY2Z8/WGMDHjyP98oatXj5na517CwUowOJG MNUVzdqQBVb7Ov6aP3C5DaA= X-Google-Smtp-Source: AGRyM1tg3/+hgf9pDL8NRFCAQ4YOA7tn10T6UX7ijpnLqcxSD9+RqrDkEV/swdnxAMA8gwuref6OPw== X-Received: by 2002:adf:ed41:0:b0:210:20a5:26c2 with SMTP id u1-20020adfed41000000b0021020a526c2mr18660614wro.603.1656789712614; Sat, 02 Jul 2022 12:21:52 -0700 (PDT) Received: from localhost (92.40.203.19.threembb.co.uk. [92.40.203.19]) by smtp.gmail.com with ESMTPSA id y15-20020a5d4acf000000b0021b9c520953sm25806153wrs.64.2022.07.02.12.21.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Jul 2022 12:21:52 -0700 (PDT) References: <20220629143046.213584-1-aidanmacdonald.0x0@gmail.com> <20220629143046.213584-13-aidanmacdonald.0x0@gmail.com> From: Aidan MacDonald To: Andy Shevchenko Cc: Linus Walleij , Bartosz Golaszewski , Rob Herring , Krzysztof Kozlowski , Chen-Yu Tsai , Jonathan Cameron , Sebastian Reichel , Lee Jones , Liam Girdwood , Mark Brown , Lars-Peter Clausen , quic_gurus@quicinc.com, Sebastian Reichel , Michael Walle , Randy Dunlap , "open list:GPIO SUBSYSTEM" , devicetree , Linux Kernel Mailing List , linux-iio , Linux PM Subject: Re: [PATCH v4 12/15] pinctrl: Add AXP192 pin control driver In-reply-to: Date: Sat, 02 Jul 2022 20:22:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Andy Shevchenko writes: > On Fri, Jul 1, 2022 at 5:36 PM Aidan MacDonald > wrote: >> Andy Shevchenko writes: >> > On Wed, Jun 29, 2022 at 4:30 PM Aidan MacDonald >> > wrote: > > ... > >> >> +struct axp192_pctl_function { >> >> + const char *name; >> >> + /* Mux value written to the control register to select the function (-1 if unsupported) */ >> >> + const u8 *muxvals; >> >> + const char * const *groups; >> >> + unsigned int ngroups; >> >> +}; >> > >> > Can it be replaced by struct function_desc? >> > https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/pinmux.h#L130 >> >> That'd work, but using the generic infrastructure doesn't allow me to >> simplify anything -- I can eliminate three trivial functions, but the >> generic code is higher overhead (extra allocations, radix trees, ...) > > I really don't see how it gets into extra allocations. Either way you > have a pointer to opaque data or in your current code it's called > muxvals. Other fields seem 1:1 what is in struct function_desc. The > code will be probably the same. > > I.o.w. I'm talking of eliminating data type, and not about simplifying > the code by fully switching to generic infrastructure. struct function_desc is hidden behind an #ifdef, so I can't use it without enabling the generic pinmux helpers. It doesn't make a lot of sense to enable them if they're not going to be used. More generally, why would I use a type from an API I'm not using just because it happens to look like a type I defined locally? That would be misleading. Given that the code is the same either way, a local type is preferable because it clearly communicates that I'm not using the generic API, and guarantees that the type isn't referenced elsewhere.