[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdVyJyOZCkLQgbDNC9bSWwF0ksLOvMG=96fH8dzmukE5g@mail.gmail.com>
Date: Fri, 1 Jul 2022 22:06:03 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Aidan MacDonald <aidanmacdonald.0x0@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Chen-Yu Tsai <wens@...e.org>,
Jonathan Cameron <jic23@...nel.org>,
Sebastian Reichel <sre@...nel.org>,
Lee Jones <lee.jones@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>, quic_gurus@...cinc.com,
Sebastian Reichel <sebastian.reichel@...labora.com>,
Michael Walle <michael@...le.cc>,
Randy Dunlap <rdunlap@...radead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-iio <linux-iio@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v4 12/15] pinctrl: Add AXP192 pin control driver
On Fri, Jul 1, 2022 at 5:36 PM Aidan MacDonald
<aidanmacdonald.0x0@...il.com> wrote:
> Andy Shevchenko <andy.shevchenko@...il.com> writes:
> > On Wed, Jun 29, 2022 at 4:30 PM Aidan MacDonald
> > <aidanmacdonald.0x0@...il.com> 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.
> so I'd prefer to stick with the current approach.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists