lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ