[prev in list] [next in list] [prev in thread] [next in thread]
List: alsa-devel
Subject: Re: [PATCH v6 07/10] hda: cs35l41: Add support for CS35L41 in HDA systems
From: Andy Shevchenko <andy.shevchenko () gmail ! com>
Date: 2022-10-31 14:34:14
Message-ID: CAHp75VfwqsiiRM-=BGii45-kX_6v4CHxDMTgwPnG5SBwu6655w () mail ! gmail ! com
[Download RAW message or body]
On Mon, Oct 31, 2022 at 7:38 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Jan 06, 2022 at 02:29:58PM +0200, Andy Shevchenko wrote:
> > On Fri, Dec 17, 2021 at 5:45 PM Lucas Tanure
> > <tanureal@opensource.cirrus.com> wrote:
...
> > > + cs35l41->reset_gpio = fwnode_gpiod_get_index(&adev->fwnode, "reset", cs35l41->index,
> >
> > Please, do not dereference fwnode pointers.
> > Also, why can't you use the device instead of fwnode?
>
> We are doing "acpi_dev_put(adev);" a few lines above, so using adev in
> the call to fwnode_gpiod_get_index() is technically use-after-free,
> isn't it?
Right, but I believe this is in response to the author and not to me.
> Also, why can't we do
>
> cs35l41->reset_gpio = gpiod_get_index(acpi_dev, "reset",
> cs35l41->index,
> GPIOD_OUT_LOW);
>
> since acpi_dev is device structure corresponding to adev and we are
> getting the rest of the properties from it?
I remembered that I have also stumbled over that, but IIRC the point
here is that ACPI tables might be broken (since the multi-instance
device is a gray area to begin with). So we need clarification from
Cirrus to understand what the cases they want to cover with this
twisted code to get a GPIO.
> I saw downthread that there was supposed to be a patch addressing
> several issues raised by Andy, was it ever submitted?
--
With Best Regards,
Andy Shevchenko
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic