[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