i2c: Remove unnecessary call to irq_find_mapping

PATCH Applied Charles Keepax 4 participants 16 messages Oct 19, 2018 – Jan 10, 2019

Subsystems (2)

I2C subsystem host drivers I2C

lore

Share & tools

lore

Charles Keepax

author

2018-10-19 08:59 UTC #0 lore raw

PATCH 1/2 i2c: Remove unnecessary call to irq_find_mapping

irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq.

Signed-off-by Charles Keepax <[email protected]>

---
 drivers/i2c/i2c-core-base.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drivers/i2c/i2c-core-base.c +1 -4

index dc78aa7369def..656f0a6fe3adf 100644
@@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
 	if (client->flags & I2C_CLIENT_TEN)
 		return -EINVAL;
 
-	irq = irq_find_mapping(adap->host_notify_domain, client->addr);
-	if (!irq)
-		irq = irq_create_mapping(adap->host_notify_domain,
-					 client->addr);
+	irq = irq_create_mapping(adap->host_notify_domain, client->addr);
 
 	return irq > 0 ? irq : -ENXIO;
 }

Signature · 1 line

2.11.0

Charles Keepax

author

2018-10-19 08:59 UTC #1 lore raw

PATCH 2/2 i2c: Clear client->irq in i2c_device_remove

The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.

Signed-off-by Charles Keepax <[email protected]>

---
 drivers/i2c/i2c-core-base.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/i2c/i2c-core-base.c +2 -0

index 656f0a6fe3adf..28460f6a60cc1 100644
@@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev)
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
 
+	client->irq = 0;
+
 	return status;
 }

Signature · 1 line

2.11.0

Wolfram Sang

2018-10-28 22:31 UTC #2 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 8 lines · Charles Keepax

The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.
Signed-off-by Charles Keepax <[email protected]>

Adding Benjamin here again. Also, should there be a Fixes: tag?

Quoted 20 lines

---
 drivers/i2c/i2c-core-base.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/i2c/i2c-core-base.c +2 -0

index 656f0a6fe3adf..28460f6a60cc1 100644
@@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev)
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
 
+	client->irq = 0;
+
 	return status;
 }

Signature · 1 line

2.11.0

Benjamin Tissoires

2018-10-29 10:15 UTC #3 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 9 lines · Wolfram Sang

Quoted 7 lines · Charles Keepax
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.

Quoted 3 lines

Quoted 1 line
Signed-off-by Charles Keepax <[email protected]>
Adding Benjamin here again. Also, should there be a Fixes: tag?

Not sure if the circumstances are preventing me to think straight, but how can you reprobe the i2c_device?
And in all cases, for the Host notify part, having the IRQ already set shouldn't be an issue.

So for the host notify case, this patch is fine, not entirely sure about the acpi or OF part of it.

Cheers,
Benjamin

Quoted 21 lines

---
 drivers/i2c/i2c-core-base.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/i2c/i2c-core-base.c +2 -1

index 656f0a6fe3adf..28460f6a60cc1 100644
@@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev)
      dev_pm_clear_wake_irq(&client->dev);
      device_init_wakeup(&client->dev, false);
 
+     client->irq = 0;
+
      return status;
 }
 
--

2.11.0

Charles Keepax

author

2018-10-30 11:51 UTC #4 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 10 lines · Benjamin Tissoires

Quoted 9 lines · Wolfram Sang
Quoted 7 lines · Charles Keepax
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Charles Keepax <[email protected]>
Adding Benjamin here again. Also, should there be a Fixes: tag?
Not sure if the circumstances are preventing me to think straight, but how can you reprobe the i2c_device?

You just head into /sys/bus/i2c/drivers/<the_driver> and use the unbind file to remove the driver. You can then probe the driver again using the bind file.

Quoted 2 lines

And in all cases, for the Host notify part, having the IRQ already set shouldn't be an issue.

To be clear this isn't a theoretical issue this is something I can replicate very easily. The problem comes in when you unbind both the I2C device and the device that is providing its IRQ. In my case the I2C device is a speaker amp and the device providing IRQs is an audio CODEC.

When the device providing the IRQ is unbound it will delete the IRQ mapping. For the I2C device to acquire its IRQ something needs to recreate that mapping, this would normally happen (in a DT system) as a result of the of_irq_get/_by_name. But as client->irq is already set this doesn't happen, causing the I2C device to fail probe because it couldn't locate its IRQ.

I can provide some stack traces or something if that would help to clarify the issue?

Thanks,
Charles

Benjamin Tissoires

Reviewed-by

2018-10-30 14:34 UTC #5 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 14 lines · Charles Keepax

Quoted 12 lines · Benjamin Tissoires
Quoted 11 lines · Wolfram Sang
Quoted 8 lines · Charles Keepax
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.
Signed-off-by Charles Keepax <[email protected]>

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
Adding Benjamin here again. Also, should there be a Fixes: tag?
Not sure if the circumstances are preventing me to think straight, but how can you reprobe the i2c_device?
You just head into /sys/bus/i2c/drivers/<the_driver> and use the unbind file to remove the driver. You can then probe the driver again using the bind file.

Right... not sure why I haven't seen that one yesterday

Quoted 10 lines

Quoted 3 lines
And in all cases, for the Host notify part, having the IRQ already set shouldn't be an issue.
To be clear this isn't a theoretical issue this is something I can replicate very easily. The problem comes in when you unbind both the I2C device and the device that is providing its IRQ. In my case the I2C device is a speaker amp and the device providing IRQs is an audio CODEC.

Quoted 6 lines

When the device providing the IRQ is unbound it will delete the IRQ mapping. For the I2C device to acquire its IRQ something needs to recreate that mapping, this would normally happen (in a DT system) as a result of the of_irq_get/_by_name. But as client->irq is already set this doesn't happen, causing the I2C device to fail probe because it couldn't locate its IRQ.

Right. I completely missed the fact that the driver of the IRQ could be reset during the period the device is unbound.
That's a pretty strong case for this patch.

Quoted 3 lines

I can provide some stack traces or something if that would help to clarify the issue?

No, that's fine. Now I get this, and I totally agree with the approach:

Reviewed-by Benjamin Tissoires <[email protected]>

Cheers,
Benjamin

Wolfram Sang

2018-10-30 14:55 UTC #6 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 4 lines

No, that's fine. Now I get this, and I totally agree with the approach:
Reviewed-by Benjamin Tissoires <[email protected]>

Thanks! If one of you could provide me with a Fixes tag (for this. or both patches?), that would be most helpful.

Charles Keepax

author

2018-10-31 09:52 UTC #7 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 8 lines · Wolfram Sang

Quoted 4 lines
No, that's fine. Now I get this, and I totally agree with the approach:
Reviewed-by Benjamin Tissoires <[email protected]>
Thanks! If one of you could provide me with a Fixes tag (for this. or both patches?), that would be most helpful.

It's a bit of a long chain and fairly tricky to say exactly when the bug was introduced but I think this is probably the closest match:

Fixes 2fd36c552649 ("i2c: core: Map OF IRQ at probe time")

I suspect the process of unbinding/rebinding would have also not worked before that commit but it would have not worked for different reasons.

Thanks,
Charles

Wolfram Sang

2018-10-31 09:59 UTC #8 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 6 lines

It's a bit of a long chain and fairly tricky to say exactly when the bug was introduced but I think this is probably the closest match:
Fixes 2fd36c552649 ("i2c: core: Map OF IRQ at probe time")

Thank you for checking! Then, I'll just leave it and cc stable so it can be applied as long as it fits.

Wolfram Sang

Applied

2018-10-31 23:35 UTC #9 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

In reply to Charles Keepax

Quoted 8 lines · Charles Keepax

The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.
Signed-off-by Charles Keepax <[email protected]>

Applied to for-current, thanks!

Yauhen Kharuzhy

2019-01-09 21:47 UTC #10 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

In reply to Charles Keepax

Quoted 6 lines · Charles Keepax

The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.

Hi.

I found driver i2c/busses/i2c-cht-wc.c which instantiates I2C device (battery charger) and passes IRQ to driver not using standard I2C IRQ mapping code. So if we reprobe I2C device (by reloading I2C device driver module or by manipulations with sysfs), we get invalid IRQ number for client:

adap->client_irq = irq_create_mapping(adap->irq_domain, 0);
...
irq_set_chip_data(adap->client_irq, adap); irq_set_chip_and_handler(adap->client_irq, &adap->irqchip, handle_simple_irq);
...
board_info.irq = adap->client_irq;
adap->client = i2c_new_device(&adap->adapter, &board_info);

adap->client->irq will be reset after device removing here.

Any advice to fix this? Maybe move initial i2c_client->irq value to new field like client->init_irq and copy it to client->irq at probing, for example?

Quoted 20 lines

Signed-off-by Charles Keepax <[email protected]>

Reviewed-by Benjamin Tissoires <[email protected]>

---
 drivers/i2c/i2c-core-base.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/i2c/i2c-core-base.c +2 -0

index 656f0a6fe3adf..28460f6a60cc1 100644
@@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev)
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
 
+	client->irq = 0;
+
 	return status;
 }

Signature · 1 line

Yauhen Kharuzhy

Charles Keepax

author

2019-01-10 13:32 UTC #11 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 24 lines · Yauhen Kharuzhy

Quoted 6 lines · Charles Keepax
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.
Hi.
I found driver i2c/busses/i2c-cht-wc.c which instantiates I2C device (battery charger) and passes IRQ to driver not using standard I2C IRQ mapping code. So if we reprobe I2C device (by reloading I2C device driver module or by manipulations with sysfs), we get invalid IRQ number for client:
adap->client_irq = irq_create_mapping(adap->irq_domain, 0);
...
irq_set_chip_data(adap->client_irq, adap); irq_set_chip_and_handler(adap->client_irq, &adap->irqchip, handle_simple_irq);
...
board_info.irq = adap->client_irq;
adap->client = i2c_new_device(&adap->adapter, &board_info);

Quoted 6 lines

adap->client->irq will be reset after device removing here.
Any advice to fix this? Maybe move initial i2c_client->irq value to new field like client->init_irq and copy it to client->irq at probing, for example?

Could you be a little more specific here, are you saying if you reprobe the battery charger device or if you reprobe the I2C controller itself?

Apologies but I am having a little difficulty working out the path through which the IRQ is not reinitialised. As I would have through the battery chargers probe would have reset up the IRQ then the core would pick it up again from there.

Thanks,
Charles

Yauhen Kharuzhy

2019-01-10 20:35 UTC #12 lore raw

Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

Quoted 28 lines · Charles Keepax

Quoted 27 lines · Yauhen Kharuzhy
Quoted 6 lines · Charles Keepax
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again.
Hi.
I found driver i2c/busses/i2c-cht-wc.c which instantiates I2C device (battery charger) and passes IRQ to driver not using standard I2C IRQ mapping code. So if we reprobe I2C device (by reloading I2C device driver module or by manipulations with sysfs), we get invalid IRQ number for client:
adap->client_irq = irq_create_mapping(adap->irq_domain, 0);
...
irq_set_chip_data(adap->client_irq, adap); irq_set_chip_and_handler(adap->client_irq, &adap->irqchip, handle_simple_irq);
...
board_info.irq = adap->client_irq;
adap->client = i2c_new_device(&adap->adapter, &board_info);
adap->client->irq will be reset after device removing here.

Quoted 7 lines

Quoted 3 lines
Any advice to fix this? Maybe move initial i2c_client->irq value to new field like client->init_irq and copy it to client->irq at probing, for example?
Could you be a little more specific here, are you saying if you reprobe the battery charger device or if you reprobe the I2C controller itself?

If I reprobe the battery charger.

Quoted 5 lines

Apologies but I am having a little difficulty working out the path through which the IRQ is not reinitialised. As I would have through the battery chargers probe would have reset up the IRQ then the core would pick it up again from there.

No, this I2C bus driver(i2c-cht-wc) pass the IRQ to charger not throuth ACPI of OF but by initializing of board_info.irq field, so I2C subsystem cannot reinitialize irq automatically.

I am not sure if this is right path for IRQ initialization and maybe should be changed for this driver.

Quoted 3 lines

Thanks,
Charles

Signature · 1 line

Yauhen Kharuzhy

Wolfram Sang

2018-10-28 22:30 UTC #13 lore raw

In reply to Charles Keepax

Quoted 5 lines · Charles Keepax

irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq.
Signed-off-by Charles Keepax <[email protected]>

Adding Benjamin to recipients. He wrote that code.

Quoted 23 lines

---
 drivers/i2c/i2c-core-base.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drivers/i2c/i2c-core-base.c +1 -4

index dc78aa7369def..656f0a6fe3adf 100644
@@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
 	if (client->flags & I2C_CLIENT_TEN)
 		return -EINVAL;
 
-	irq = irq_find_mapping(adap->host_notify_domain, client->addr);
-	if (!irq)
-		irq = irq_create_mapping(adap->host_notify_domain,
-					 client->addr);
+	irq = irq_create_mapping(adap->host_notify_domain, client->addr);
 
 	return irq > 0 ? irq : -ENXIO;
 }

Signature · 1 line

2.11.0

Benjamin Tissoires

Reviewed-by

2018-10-29 10:13 UTC #14 lore raw

Quoted 9 lines · Wolfram Sang

Quoted 5 lines · Charles Keepax
irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq.
Signed-off-by Charles Keepax <[email protected]>
Adding Benjamin to recipients. He wrote that code.

Yep, definitely looking good. For completeness, I just tested it on the t450s, and it works fine.

This one is

Reviewed-by Benjamin Tissoires <[email protected]>

Cheers,
Benjamin

Quoted 24 lines

---
 drivers/i2c/i2c-core-base.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drivers/i2c/i2c-core-base.c +1 -5

index dc78aa7369def..656f0a6fe3adf 100644
@@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
      if (client->flags & I2C_CLIENT_TEN)
              return -EINVAL;
 
-     irq = irq_find_mapping(adap->host_notify_domain, client->addr);
-     if (!irq)
-             irq = irq_create_mapping(adap->host_notify_domain,
-                                      client->addr);
+     irq = irq_create_mapping(adap->host_notify_domain, client->addr);
 
      return irq > 0 ? irq : -ENXIO;
 }
--

2.11.0

Wolfram Sang

Applied

2018-10-31 23:34 UTC #15 lore raw

In reply to Charles Keepax

Quoted 5 lines · Charles Keepax

irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq.
Signed-off-by Charles Keepax <[email protected]>

Applied to for-current, thanks!