On Thu, Jan 13, 2022 at 6:53 PM Lucas tanure
<tanureal@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On 1/6/22 12:29, Andy Shevchenko wrote:
> > On Fri, Dec 17, 2021 at 5:45 PM Lucas Tanure
> > <tanureal@xxxxxxxxxxxxxxxxxxxxx> wrote:
...
> >> + * Device CLSA0100 doesn't have _DSD so a gpiod_get by the label reset won't work.
> >
> > So, you need to add mapping tables and switch to regular APIs, tell
> > me, why it won't work.
> I will submit a patch series to fix most of the issues you pointed out.
Thanks!
> The part about how the driver access the ACPI table is going to be
> improved later if possible.
> The laptop has already shipped and doesn't have a _DSD node, so the
> driver needs to read the reset GPIO from a hard coded index inside a
> node that contains more than one cs35l41.
We have a lot of cases like this, hint: `git grep -n -w
devm_acpi_dev_add_driver_gpios`.
...
> >> +int cs35l41_hda_probe(struct device *dev, const char *device_name, int id, int irq,
> >> + struct regmap *regmap)
> >
> >> + if (IS_ERR(regmap))
> >> + return PTR_ERR(regmap);
> >
> > Why?
> It is up to the I2C/SPI module to create the regmap and provide to the
> main module. If that fails the main module can't continue.
So, this is band-aiding the issue, which is in the caller. Caller
shouldn't call this function without the regmap being ready-to-use.
...
> >> + {"CLSA0100", 0 },
> >> + {"CSC3551", 0 },
> >
> > I believe these IDs are officially allocated by the Cirrus Logic, right?
> CLSA010* is not a valid id for Cirrus Logic, but the Bios is already in
> production, so we must support it.
> CSC3551 is a valid id for Cirrus Logic.
Thank you for elaborating. Can we be sure that there won't be any
abuse of ACPI specification in the future (meaning all IDs will follow
the ACPI/PNP registries and be allocated by certain vendor)?
--
With Best Regards,
Andy Shevchenko
