Received-SPF: pass (google.com: domain of linux-kernel+bounces-30564-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20230804104602.395892-1-ckeepax@opensource.cirrus.com>
 <20230804104602.395892-7-ckeepax@opensource.cirrus.com> <Zali4qxdegY7H6eY@surfacebook.localdomain>
 <aec96f5a-b759-48c7-a5ec-bafe3bfa5357@sirena.org.uk>
In-Reply-To: <aec96f5a-b759-48c7-a5ec-bafe3bfa5357@sirena.org.uk>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, 18 Jan 2024 22:46:28 +0200
Message-ID: <CAHp75Vd6JtW4ddbSPXUp6WgEdBJizjwnS-XZzwLcXWWLxFWp-w@mail.gmail.com>
Subject: Re: [PATCH v7 6/6] ASoC: cs42l43: Add support for the cs42l43
To: Mark Brown <broonie@kernel.org>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>, lee@kernel.org, robh+dt@kernel.org, 
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, 
	linus.walleij@linaro.org, vkoul@kernel.org, lgirdwood@gmail.com, 
	yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com, 
	pierre-louis.bossart@linux.intel.com, alsa-devel@alsa-project.org, 
	patches@opensource.cirrus.com, devicetree@vger.kernel.org, 
	linux-gpio@vger.kernel.org, linux-spi@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2024 at 8:11=E2=80=AFPM Mark Brown <broonie@kernel.org> wro=
te:
> On Thu, Jan 18, 2024 at 07:41:54PM +0200, andy.shevchenko@gmail.com wrote=
:
> > Fri, Aug 04, 2023 at 11:46:02AM +0100, Charles Keepax kirjoitti:
>
> > > +   unsigned int hs2 =3D 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[] =3D {
> > > +   "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 pos=
sible
> > values ranges in the HW).
> > If it's just a coincidence that there are 8 of them, perhaps other (log=
ical)
> > 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.

--=20
With Best Regards,
Andy Shevchenko