alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
* [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

* [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 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 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 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: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: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

* 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).