[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vd6JtW4ddbSPXUp6WgEdBJizjwnS-XZzwLcXWWLxFWp-w@mail.gmail.com>
Date: Thu, 18 Jan 2024 22:46:28 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>, lee@...nel.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
linus.walleij@...aro.org, vkoul@...nel.org, lgirdwood@...il.com,
yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
pierre-louis.bossart@...ux.intel.com, alsa-devel@...a-project.org,
patches@...nsource.cirrus.com, devicetree@...r.kernel.org,
linux-gpio@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 6/6] ASoC: cs42l43: Add support for the cs42l43
On Thu, Jan 18, 2024 at 8:11 PM Mark Brown <broonie@...nel.org> wrote:
> On Thu, Jan 18, 2024 at 07:41:54PM +0200, andy.shevchenko@...il.com wrote:
> > Fri, Aug 04, 2023 at 11:46:02AM +0100, Charles Keepax kirjoitti:
>
> > > + unsigned int hs2 = 0x2 << CS42L43_HSDET_MODE_SHIFT;
>
> > BIT(1) ?
>
> Given that this is writing a value into a register field called "MODE"
> it seems very likely that it's an enumeration value rather than a
> bitmask (and similarly for all the other places where you're making
> similar comments). Please think a bit more about the code being
> commented on when making these minor stylistic comments.
I read a bit further and have given a comment about this as you put it
above that they are plain values.
Please, read my comments in full.
..
> > > +static const char * const cs42l43_jack_text[] = {
> > > + "None", "CTIA", "OMTP", "Headphone", "Line-Out",
> > > + "Line-In", "Microphone", "Optical",
>
> > Better to have this by power of 2 blocks (seems it's related to the possible
> > values ranges in the HW).
> > If it's just a coincidence that there are 8 of them, perhaps other (logical)
> > grouping is better?
>
> This is probably well within the realm of driver author taste...
No objection, just a question.
..
> > > + // Don't use devm as we need to get against the MFD device
>
> > This is weird...
>
> This is normal, the splitting into subdevices is often a purely Linux
> internal thing and not represented in the firmware description so
> external resources are linked to the top level.
I meant the weirdness of mixing devm_ with non-devm_ in a way that
->remove() can be broken to the extent of oopses or crashes.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists