* [PATCH v1 0/2] Use ACPI_COMPANION macro to obtain acpi_device in cs35l41_hda @ 2022-11-24 11:07 Stefan Binding 2022-11-24 11:07 ` [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c Stefan Binding 2022-11-24 11:07 ` [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties Stefan Binding 0 siblings, 2 replies; 9+ messages in thread From: Stefan Binding @ 2022-11-24 11:07 UTC (permalink / raw) To: Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Hans de Goede, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, Stefan Binding, linux-kernel, platform-driver-x86 Currently, in cs35l41_hda driver, we use acpi_dev_get_first_match_dev to obtain the acpi_device used to obtain the properties and gpios. It is better to use the ACPI_COMPANION macro to do this, since it guarentees that we get the correct acpi_device for the device. However, the cs35l41_hda driver uses the serial-multi-instantiate driver to enumerate, and whilst the ACPI_CONPANION macro works with spi, it does not work with i2c. This is fixed by setting the fwnode for i2c. Stefan Binding (2): platform/x86: serial-multi-instantiate: Set fwnode for i2c ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties .../platform/x86/serial-multi-instantiate.c | 1 + sound/pci/hda/cs35l41_hda.c | 50 ++++++++----------- 2 files changed, 22 insertions(+), 29 deletions(-) -- 2.34.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c 2022-11-24 11:07 [PATCH v1 0/2] Use ACPI_COMPANION macro to obtain acpi_device in cs35l41_hda Stefan Binding @ 2022-11-24 11:07 ` Stefan Binding 2022-11-24 11:35 ` Andy Shevchenko 2022-11-24 11:47 ` Hans de Goede 2022-11-24 11:07 ` [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties Stefan Binding 1 sibling, 2 replies; 9+ messages in thread From: Stefan Binding @ 2022-11-24 11:07 UTC (permalink / raw) To: Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Hans de Goede, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, Stefan Binding, linux-kernel, platform-driver-x86 This allows the i2c driver to obtain the ACPI_COMPANION. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> --- drivers/platform/x86/serial-multi-instantiate.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/platform/x86/serial-multi-instantiate.c b/drivers/platform/x86/serial-multi-instantiate.c index 5362f1a7b77c..15ef2f3c442e 100644 --- a/drivers/platform/x86/serial-multi-instantiate.c +++ b/drivers/platform/x86/serial-multi-instantiate.c @@ -194,6 +194,7 @@ static int smi_i2c_probe(struct platform_device *pdev, struct smi *smi, strscpy(board_info.type, inst_array[i].type, I2C_NAME_SIZE); snprintf(name, sizeof(name), "%s-%s.%d", dev_name(dev), inst_array[i].type, i); board_info.dev_name = name; + board_info.fwnode = acpi_fwnode_handle(adev); ret = smi_get_irq(pdev, adev, &inst_array[i]); if (ret < 0) -- 2.34.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c 2022-11-24 11:07 ` [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c Stefan Binding @ 2022-11-24 11:35 ` Andy Shevchenko 2022-11-24 11:51 ` Hans de Goede 2022-11-24 11:47 ` Hans de Goede 1 sibling, 1 reply; 9+ messages in thread From: Andy Shevchenko @ 2022-11-24 11:35 UTC (permalink / raw) To: Stefan Binding Cc: alsa-devel, Rafael J . Wysocki, linux-kernel, Dmitry Torokhov, Takashi Iwai, Mark Gross, Hans de Goede, patches, platform-driver-x86 On Thu, Nov 24, 2022 at 1:07 PM Stefan Binding <sbinding@opensource.cirrus.com> wrote: > > This allows the i2c driver to obtain the ACPI_COMPANION. As far as I get how it's done in the SPI case the real fix should lie among i2c_acpi_new_device_by_fwnode(), right? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c 2022-11-24 11:35 ` Andy Shevchenko @ 2022-11-24 11:51 ` Hans de Goede 0 siblings, 0 replies; 9+ messages in thread From: Hans de Goede @ 2022-11-24 11:51 UTC (permalink / raw) To: Andy Shevchenko, Stefan Binding Cc: alsa-devel, Rafael J . Wysocki, linux-kernel, Dmitry Torokhov, Takashi Iwai, Mark Gross, patches, platform-driver-x86 Hi, On 11/24/22 12:35, Andy Shevchenko wrote: > On Thu, Nov 24, 2022 at 1:07 PM Stefan Binding > <sbinding@opensource.cirrus.com> wrote: >> >> This allows the i2c driver to obtain the ACPI_COMPANION. > > As far as I get how it's done in the SPI case the real fix should lie > among i2c_acpi_new_device_by_fwnode(), right? Eventually maybe, but not for the initial change. It is complicated, making this change has side-effects and we want to limit those side-effects to only i2c-clients instantiated from serial-multi-instantiate for now, see my other reply to this patch. I do believe that we eventually want to make this change, to easily give drivers access to all sorts of info (e.g. _DSM methods) from the matching ACPI fw-node, but as I said it is complicated... Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c 2022-11-24 11:07 ` [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c Stefan Binding 2022-11-24 11:35 ` Andy Shevchenko @ 2022-11-24 11:47 ` Hans de Goede 2022-11-24 12:01 ` Hans de Goede 1 sibling, 1 reply; 9+ messages in thread From: Hans de Goede @ 2022-11-24 11:47 UTC (permalink / raw) To: Stefan Binding, Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, linux-kernel, platform-driver-x86 Hi Stefan, On 11/24/22 12:07, Stefan Binding wrote: > This allows the i2c driver to obtain the ACPI_COMPANION. > > Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> > --- > drivers/platform/x86/serial-multi-instantiate.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/platform/x86/serial-multi-instantiate.c b/drivers/platform/x86/serial-multi-instantiate.c > index 5362f1a7b77c..15ef2f3c442e 100644 > --- a/drivers/platform/x86/serial-multi-instantiate.c > +++ b/drivers/platform/x86/serial-multi-instantiate.c > @@ -194,6 +194,7 @@ static int smi_i2c_probe(struct platform_device *pdev, struct smi *smi, > strscpy(board_info.type, inst_array[i].type, I2C_NAME_SIZE); > snprintf(name, sizeof(name), "%s-%s.%d", dev_name(dev), inst_array[i].type, i); > board_info.dev_name = name; > + board_info.fwnode = acpi_fwnode_handle(adev); > > ret = smi_get_irq(pdev, adev, &inst_array[i]); > if (ret < 0) I'm afraid that making this change is not as straight forward as it looks. I know that I have tried to do this in the past and it failed. IIRC there were 3 problems: 1. I was expecting this to also allow the driver for the instantiated i2c-client to be able to bind using an acpi_match_table but that unfortunately does not work. acpi_match_table matches only work for the first physical_node linked under /sys/bus/acpi/devices/xxxx:xx/physical_node and that is the platform device to which serial-multi-instantiate.c binds. The i2c_client becomes the second physical node. Note this is not really an issue, just something to be aware of. 2. This causes the i2c-core to use the first IRQ resource in the ACPI fwnode as client->irq for any clients for which we do not set an IRQ when instantiating. Which may very well be wrong. Sometimes that IRQ is only valid for the first i2c-client which we instantiate; and not for the others! And sometimes it is a problem because it may point to an irqchip for which we never wrote a driver leading to all probes of the i2c-client failing with -EPROBE_DEFER, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1d84bb95364ed604015c2b788caaf3dbca0262f Note that patch has been reverted since that specific -EPROBE_DEFER issue has been solved by making the ACPI core instantiate a platform_device instead of an i2c_client (in this case we did not need the actual i2c_client at all). The current i2c-core code has a (!client-irq) test guarding its code of trying to use the first ACPI fwnode IRQ resource. So we could disable this by setting client->irq = -ENOENT in serial-multi-instantiate.c when (inst->flags & IRQ_RESOURCE_TYPE) == IRQ_RESOURCE_NONE). But that will introduce a new problem. Many i2c-drivers check if there is an IRQ for them to use by doing: "if (client->irq) request_irq(client->irq, ...)" but then with error checking/so setting client->irq to -ENOENT will cause the request_irq to fail, leading the probe to fail. So before you can write a patch setting client->irq = -ENOENT when (inst->flags & IRQ_RESOURCE_TYPE) == IRQ_RESOURCE_NONE), you would first need to patch all i2c-drivers for clients instantiated through serial-multi-instantiate.c changing: if (client->irq) { ... } to: if (client->irq > 0) { ... } Note this is not as bad as it sounds, since there are only a few drivers for clients instantiated by serial-multi-instantiate.c . 3. Some drivers may check for an ACPI companion device and then change their behavior. So all drivers for clients instantiated through serial-multi-instantiate.c will need to be audited for this (and a summary of this audit needs to be added to the commit msg). Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c 2022-11-24 11:47 ` Hans de Goede @ 2022-11-24 12:01 ` Hans de Goede 0 siblings, 0 replies; 9+ messages in thread From: Hans de Goede @ 2022-11-24 12:01 UTC (permalink / raw) To: Stefan Binding, Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, linux-kernel, platform-driver-x86 Hi, On 11/24/22 12:47, Hans de Goede wrote: > Hi Stefan, > > On 11/24/22 12:07, Stefan Binding wrote: >> This allows the i2c driver to obtain the ACPI_COMPANION. >> >> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> >> --- >> drivers/platform/x86/serial-multi-instantiate.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/platform/x86/serial-multi-instantiate.c b/drivers/platform/x86/serial-multi-instantiate.c >> index 5362f1a7b77c..15ef2f3c442e 100644 >> --- a/drivers/platform/x86/serial-multi-instantiate.c >> +++ b/drivers/platform/x86/serial-multi-instantiate.c >> @@ -194,6 +194,7 @@ static int smi_i2c_probe(struct platform_device *pdev, struct smi *smi, >> strscpy(board_info.type, inst_array[i].type, I2C_NAME_SIZE); >> snprintf(name, sizeof(name), "%s-%s.%d", dev_name(dev), inst_array[i].type, i); >> board_info.dev_name = name; >> + board_info.fwnode = acpi_fwnode_handle(adev); >> >> ret = smi_get_irq(pdev, adev, &inst_array[i]); >> if (ret < 0) > > I'm afraid that making this change is not as straight forward as it looks. > > I know that I have tried to do this in the past and it failed. > > IIRC there were 3 problems: > > 1. I was expecting this to also allow the driver for the instantiated > i2c-client to be able to bind using an acpi_match_table but that > unfortunately does not work. acpi_match_table matches only work for > the first physical_node linked under > /sys/bus/acpi/devices/xxxx:xx/physical_node and that is the platform > device to which serial-multi-instantiate.c binds. The i2c_client becomes > the second physical node. Note this is not really an issue, > just something to be aware of. > > > 2. This causes the i2c-core to use the first IRQ resource in the ACPI > fwnode as client->irq for any clients for which we do not set an > IRQ when instantiating. Which may very well be wrong. Sometimes that > IRQ is only valid for the first i2c-client which we instantiate; and > not for the others! And sometimes it is a problem because it may > point to an irqchip for which we never wrote a driver leading to > all probes of the i2c-client failing with -EPROBE_DEFER, see: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1d84bb95364ed604015c2b788caaf3dbca0262f > > Note that patch has been reverted since that specific -EPROBE_DEFER > issue has been solved by making the ACPI core instantiate a > platform_device instead of an i2c_client (in this case we > did not need the actual i2c_client at all). > > The current i2c-core code has a (!client-irq) test guarding its > code of trying to use the first ACPI fwnode IRQ resource. > > So we could disable this by setting client->irq = -ENOENT in > serial-multi-instantiate.c when (inst->flags & IRQ_RESOURCE_TYPE) == > IRQ_RESOURCE_NONE). But that will introduce a new problem. Many > i2c-drivers check if there is an IRQ for them to use by doing: > "if (client->irq) request_irq(client->irq, ...)" but then with > error checking/so setting client->irq to -ENOENT will cause > the request_irq to fail, leading the probe to fail. > > So before you can write a patch setting client->irq = -ENOENT > when (inst->flags & IRQ_RESOURCE_TYPE) == IRQ_RESOURCE_NONE), > you would first need to patch all i2c-drivers for clients > instantiated through serial-multi-instantiate.c changing: > > if (client->irq) { > ... > } > > to: > > if (client->irq > 0) { > ... > } > > Note this is not as bad as it sounds, since there are only > a few drivers for clients instantiated by serial-multi-instantiate.c . Possibly a nicer way to fix this would be to make the i2c-core change client->irq to 0 if it is -ENOENT before calling the i2c_driver's probe method, thus fixing things centrally for all i2c-drivers without needing to audit/patch them all. Specifically in: drivers/i2c/i2c-core-base.c: i2c_device_probe() change: if (!client->irq) { ... } to: if (!client->irq) { ... } else if (client->irq == -ENOENT) { client->irq = 0; /* Drivers expect 0 for "no-IRQ" */ } And maybe as Andy suggested, handle at least the IRQ in i2c_acpi_new_device_by_fwnode() by adding something like that there: /* Disable the i2c-core attempting to get an IRQ from ACPI itself */ if (!board_info->irq) board_info->irq= -ENOENT; I also agree with Andy that setting board_info->fw_node would be done there ideally too. But then you would need to extend the audit of impacted drivers mentioned below to also include drivers for i2c-clients instantiated through other code-paths calling i2c_acpi_new_device_by_fwnode() (of which there are not many, but there are a few others). > 3. Some drivers may check for an ACPI companion device and then > change their behavior. So all drivers for clients instantiated > through serial-multi-instantiate.c will need to be audited for > this (and a summary of this audit needs to be added to the commit > msg). Regards, Hans ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties 2022-11-24 11:07 [PATCH v1 0/2] Use ACPI_COMPANION macro to obtain acpi_device in cs35l41_hda Stefan Binding 2022-11-24 11:07 ` [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c Stefan Binding @ 2022-11-24 11:07 ` Stefan Binding 2022-11-24 11:40 ` Andy Shevchenko 2022-11-24 12:05 ` Hans de Goede 1 sibling, 2 replies; 9+ messages in thread From: Stefan Binding @ 2022-11-24 11:07 UTC (permalink / raw) To: Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Hans de Goede, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, Stefan Binding, linux-kernel, platform-driver-x86 Currently the driver finds the acpi_device used to read certain properties using the HID, however, this is not necessary, as the acpi_device can be obtained from the device itself. With the ACPI_COMPANION correctly set, we can also simplify how we obtain the reset gpio. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> --- sound/pci/hda/cs35l41_hda.c | 50 ++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 29 deletions(-) diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c index e5f0549bf06d..50cbbcce4946 100644 --- a/sound/pci/hda/cs35l41_hda.c +++ b/sound/pci/hda/cs35l41_hda.c @@ -1214,16 +1214,15 @@ static int cs35l41_get_speaker_id(struct device *dev, int amp_index, * And devm functions expect that the device requesting the resource has the correct * fwnode. */ -static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, struct device *physdev, int id, - const char *hid) +static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, int id, const char *hid) { struct cs35l41_hw_cfg *hw_cfg = &cs35l41->hw_cfg; /* check I2C address to assign the index */ cs35l41->index = id == 0x40 ? 0 : 1; cs35l41->channel_index = 0; - cs35l41->reset_gpio = gpiod_get_index(physdev, NULL, 0, GPIOD_OUT_HIGH); - cs35l41->speaker_id = cs35l41_get_speaker_id(physdev, 0, 0, 2); + cs35l41->reset_gpio = gpiod_get_index(cs35l41->dev, NULL, 0, GPIOD_OUT_HIGH); + cs35l41->speaker_id = cs35l41_get_speaker_id(cs35l41->dev, 0, 0, 2); hw_cfg->spk_pos = cs35l41->index; hw_cfg->gpio2.func = CS35L41_INTERRUPT; hw_cfg->gpio2.valid = true; @@ -1255,39 +1254,36 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i struct cs35l41_hw_cfg *hw_cfg = &cs35l41->hw_cfg; u32 values[HDA_MAX_COMPONENTS]; struct acpi_device *adev; - struct device *physdev; + const char *sub; char *property; size_t nval; int i, ret; - adev = acpi_dev_get_first_match_dev(hid, NULL, -1); + adev = ACPI_COMPANION(cs35l41->dev); if (!adev) { - dev_err(cs35l41->dev, "Failed to find an ACPI device for %s\n", hid); + dev_err(cs35l41->dev, "Failed to find an ACPI device for %s\n", + dev_name(cs35l41->dev)); return -ENODEV; } - physdev = get_device(acpi_get_first_physical_node(adev)); - acpi_dev_put(adev); - - sub = acpi_get_subsystem_id(ACPI_HANDLE(physdev)); + sub = acpi_get_subsystem_id(ACPI_HANDLE(cs35l41->dev)); if (IS_ERR(sub)) sub = NULL; cs35l41->acpi_subsystem_id = sub; property = "cirrus,dev-index"; - ret = device_property_count_u32(physdev, property); - if (ret <= 0) { - ret = cs35l41_no_acpi_dsd(cs35l41, physdev, id, hid); - goto err_put_physdev; - } + ret = device_property_count_u32(cs35l41->dev, property); + if (ret <= 0) + return cs35l41_no_acpi_dsd(cs35l41, id, hid); + if (ret > ARRAY_SIZE(values)) { ret = -EINVAL; goto err; } nval = ret; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret) goto err; @@ -1307,11 +1303,10 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i /* To use the same release code for all laptop variants we can't use devm_ version of * gpiod_get here, as CLSA010* don't have a fully functional bios with an _DSD node */ - cs35l41->reset_gpio = fwnode_gpiod_get_index(acpi_fwnode_handle(adev), "reset", cs35l41->index, - GPIOD_OUT_LOW, "cs35l41-reset"); + cs35l41->reset_gpio = gpiod_get_index(cs35l41->dev, "reset", cs35l41->index, GPIOD_OUT_LOW); property = "cirrus,speaker-position"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret) goto err; hw_cfg->spk_pos = values[cs35l41->index]; @@ -1322,41 +1317,41 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i cs35l41->channel_index++; property = "cirrus,gpio1-func"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret) goto err; hw_cfg->gpio1.func = values[cs35l41->index]; hw_cfg->gpio1.valid = true; property = "cirrus,gpio2-func"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret) goto err; hw_cfg->gpio2.func = values[cs35l41->index]; hw_cfg->gpio2.valid = true; property = "cirrus,boost-peak-milliamp"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret == 0) hw_cfg->bst_ipk = values[cs35l41->index]; else hw_cfg->bst_ipk = -1; property = "cirrus,boost-ind-nanohenry"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret == 0) hw_cfg->bst_ind = values[cs35l41->index]; else hw_cfg->bst_ind = -1; property = "cirrus,boost-cap-microfarad"; - ret = device_property_read_u32_array(physdev, property, values, nval); + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); if (ret == 0) hw_cfg->bst_cap = values[cs35l41->index]; else hw_cfg->bst_cap = -1; - cs35l41->speaker_id = cs35l41_get_speaker_id(physdev, cs35l41->index, nval, -1); + cs35l41->speaker_id = cs35l41_get_speaker_id(cs35l41->dev, cs35l41->index, nval, -1); if (hw_cfg->bst_ind > 0 || hw_cfg->bst_cap > 0 || hw_cfg->bst_ipk > 0) hw_cfg->bst_type = CS35L41_INT_BOOST; @@ -1364,14 +1359,11 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i hw_cfg->bst_type = CS35L41_EXT_BOOST; hw_cfg->valid = true; - put_device(physdev); return 0; err: dev_err(cs35l41->dev, "Failed property %s: %d\n", property, ret); -err_put_physdev: - put_device(physdev); return ret; } -- 2.34.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties 2022-11-24 11:07 ` [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties Stefan Binding @ 2022-11-24 11:40 ` Andy Shevchenko 2022-11-24 12:05 ` Hans de Goede 1 sibling, 0 replies; 9+ messages in thread From: Andy Shevchenko @ 2022-11-24 11:40 UTC (permalink / raw) To: Stefan Binding Cc: alsa-devel, Rafael J . Wysocki, linux-kernel, Dmitry Torokhov, Takashi Iwai, Mark Gross, Hans de Goede, patches, platform-driver-x86 On Thu, Nov 24, 2022 at 1:07 PM Stefan Binding <sbinding@opensource.cirrus.com> wrote: > > Currently the driver finds the acpi_device used to read certain > properties using the HID, however, this is not necessary, as the > acpi_device can be obtained from the device itself. > > With the ACPI_COMPANION correctly set, we can also simplify how ACPI companion device > we obtain the reset gpio. GPIO ... The idea seems to be an improvement to me. Thanks. But I have side question, are you going to address the https://bugzilla.kernel.org/show_bug.cgi?id=215993 P.S. It would be nice if you have an account there, so I can reassign that to you. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties 2022-11-24 11:07 ` [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties Stefan Binding 2022-11-24 11:40 ` Andy Shevchenko @ 2022-11-24 12:05 ` Hans de Goede 1 sibling, 0 replies; 9+ messages in thread From: Hans de Goede @ 2022-11-24 12:05 UTC (permalink / raw) To: Stefan Binding, Andy Shevchenko, Dmitry Torokhov, Rafael J . Wysocki, Mark Gross, Jaroslav Kysela, Takashi Iwai Cc: patches, alsa-devel, linux-kernel, platform-driver-x86 Hi, On 11/24/22 12:07, Stefan Binding wrote: > Currently the driver finds the acpi_device used to read certain > properties using the HID, however, this is not necessary, as the > acpi_device can be obtained from the device itself. > > With the ACPI_COMPANION correctly set, we can also simplify how > we obtain the reset gpio. Typically when you write "also do ..." in a commit message that is a hint to yourself that it might be better to split the commit into 2 commits which each do only 1 thing, for easier review. But e.g. also to easier see what is going on if a bisect points out the commit as being the first bad one. So once the issues with patch 1/2 are resolved, please consider splitting this patch into 2 smaller patches. Regards, Hans > > Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> > --- > sound/pci/hda/cs35l41_hda.c | 50 ++++++++++++++++--------------------- > 1 file changed, 21 insertions(+), 29 deletions(-) > > diff --git a/sound/pci/hda/cs35l41_hda.c b/sound/pci/hda/cs35l41_hda.c > index e5f0549bf06d..50cbbcce4946 100644 > --- a/sound/pci/hda/cs35l41_hda.c > +++ b/sound/pci/hda/cs35l41_hda.c > @@ -1214,16 +1214,15 @@ static int cs35l41_get_speaker_id(struct device *dev, int amp_index, > * And devm functions expect that the device requesting the resource has the correct > * fwnode. > */ > -static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, struct device *physdev, int id, > - const char *hid) > +static int cs35l41_no_acpi_dsd(struct cs35l41_hda *cs35l41, int id, const char *hid) > { > struct cs35l41_hw_cfg *hw_cfg = &cs35l41->hw_cfg; > > /* check I2C address to assign the index */ > cs35l41->index = id == 0x40 ? 0 : 1; > cs35l41->channel_index = 0; > - cs35l41->reset_gpio = gpiod_get_index(physdev, NULL, 0, GPIOD_OUT_HIGH); > - cs35l41->speaker_id = cs35l41_get_speaker_id(physdev, 0, 0, 2); > + cs35l41->reset_gpio = gpiod_get_index(cs35l41->dev, NULL, 0, GPIOD_OUT_HIGH); > + cs35l41->speaker_id = cs35l41_get_speaker_id(cs35l41->dev, 0, 0, 2); > hw_cfg->spk_pos = cs35l41->index; > hw_cfg->gpio2.func = CS35L41_INTERRUPT; > hw_cfg->gpio2.valid = true; > @@ -1255,39 +1254,36 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i > struct cs35l41_hw_cfg *hw_cfg = &cs35l41->hw_cfg; > u32 values[HDA_MAX_COMPONENTS]; > struct acpi_device *adev; > - struct device *physdev; > + > const char *sub; > char *property; > size_t nval; > int i, ret; > > - adev = acpi_dev_get_first_match_dev(hid, NULL, -1); > + adev = ACPI_COMPANION(cs35l41->dev); > if (!adev) { > - dev_err(cs35l41->dev, "Failed to find an ACPI device for %s\n", hid); > + dev_err(cs35l41->dev, "Failed to find an ACPI device for %s\n", > + dev_name(cs35l41->dev)); > return -ENODEV; > } > > - physdev = get_device(acpi_get_first_physical_node(adev)); > - acpi_dev_put(adev); > - > - sub = acpi_get_subsystem_id(ACPI_HANDLE(physdev)); > + sub = acpi_get_subsystem_id(ACPI_HANDLE(cs35l41->dev)); > if (IS_ERR(sub)) > sub = NULL; > cs35l41->acpi_subsystem_id = sub; > > property = "cirrus,dev-index"; > - ret = device_property_count_u32(physdev, property); > - if (ret <= 0) { > - ret = cs35l41_no_acpi_dsd(cs35l41, physdev, id, hid); > - goto err_put_physdev; > - } > + ret = device_property_count_u32(cs35l41->dev, property); > + if (ret <= 0) > + return cs35l41_no_acpi_dsd(cs35l41, id, hid); > + > if (ret > ARRAY_SIZE(values)) { > ret = -EINVAL; > goto err; > } > nval = ret; > > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret) > goto err; > > @@ -1307,11 +1303,10 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i > /* To use the same release code for all laptop variants we can't use devm_ version of > * gpiod_get here, as CLSA010* don't have a fully functional bios with an _DSD node > */ > - cs35l41->reset_gpio = fwnode_gpiod_get_index(acpi_fwnode_handle(adev), "reset", cs35l41->index, > - GPIOD_OUT_LOW, "cs35l41-reset"); > + cs35l41->reset_gpio = gpiod_get_index(cs35l41->dev, "reset", cs35l41->index, GPIOD_OUT_LOW); > > property = "cirrus,speaker-position"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret) > goto err; > hw_cfg->spk_pos = values[cs35l41->index]; > @@ -1322,41 +1317,41 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i > cs35l41->channel_index++; > > property = "cirrus,gpio1-func"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret) > goto err; > hw_cfg->gpio1.func = values[cs35l41->index]; > hw_cfg->gpio1.valid = true; > > property = "cirrus,gpio2-func"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret) > goto err; > hw_cfg->gpio2.func = values[cs35l41->index]; > hw_cfg->gpio2.valid = true; > > property = "cirrus,boost-peak-milliamp"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret == 0) > hw_cfg->bst_ipk = values[cs35l41->index]; > else > hw_cfg->bst_ipk = -1; > > property = "cirrus,boost-ind-nanohenry"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret == 0) > hw_cfg->bst_ind = values[cs35l41->index]; > else > hw_cfg->bst_ind = -1; > > property = "cirrus,boost-cap-microfarad"; > - ret = device_property_read_u32_array(physdev, property, values, nval); > + ret = device_property_read_u32_array(cs35l41->dev, property, values, nval); > if (ret == 0) > hw_cfg->bst_cap = values[cs35l41->index]; > else > hw_cfg->bst_cap = -1; > > - cs35l41->speaker_id = cs35l41_get_speaker_id(physdev, cs35l41->index, nval, -1); > + cs35l41->speaker_id = cs35l41_get_speaker_id(cs35l41->dev, cs35l41->index, nval, -1); > > if (hw_cfg->bst_ind > 0 || hw_cfg->bst_cap > 0 || hw_cfg->bst_ipk > 0) > hw_cfg->bst_type = CS35L41_INT_BOOST; > @@ -1364,14 +1359,11 @@ static int cs35l41_hda_read_acpi(struct cs35l41_hda *cs35l41, const char *hid, i > hw_cfg->bst_type = CS35L41_EXT_BOOST; > > hw_cfg->valid = true; > - put_device(physdev); > > return 0; > > err: > dev_err(cs35l41->dev, "Failed property %s: %d\n", property, ret); > -err_put_physdev: > - put_device(physdev); > > return ret; > } ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-11-24 12:06 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-11-24 11:07 [PATCH v1 0/2] Use ACPI_COMPANION macro to obtain acpi_device in cs35l41_hda Stefan Binding 2022-11-24 11:07 ` [PATCH v1 1/2] platform/x86: serial-multi-instantiate: Set fwnode for i2c Stefan Binding 2022-11-24 11:35 ` Andy Shevchenko 2022-11-24 11:51 ` Hans de Goede 2022-11-24 11:47 ` Hans de Goede 2022-11-24 12:01 ` Hans de Goede 2022-11-24 11:07 ` [PATCH v1 2/2] ALSA: hda: cs35l41: Use ACPI_COMPANION to read acpi properties Stefan Binding 2022-11-24 11:40 ` Andy Shevchenko 2022-11-24 12:05 ` Hans de Goede
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).