When the port is connected at boot, there is not necessarily
an interrupt flagged in the interrupt status register, causing
the IRQ handler to bail out early without reading the state when
it is invoked directly from probe.
Add a flag that overrides the interrupt status register and reads
the state regardless during probe.
Fixes: 06bc4ca115cd ("extcon: Add driver for TI TUSB320")
Signed-off-by: Peter Rosin <[email protected]>
---
drivers/extcon/extcon-usbc-tusb320.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Hi!
This is basically a resend of v1, the patch has simply been adapted
to fit after the driver changes for type-c support.
Version 1 of the patch, with its brief "discussion", is here:
https://lore.kernel.org/lkml/[email protected]/
I cannot see how the patch can possibly affect detection of connector
changes *after* 'priv->initialized = true', so the comment from Chanwoo
Choi is still a mystery to me. The patch is about what happens *before*
'priv->initialized = true', i.e. when the IRQ handler is called directly
during probe. There is no change in behavior after the statement
'priv->initialized = true', and IRQs are handled exactly as before once
past that point.
Please look at this patch again.
Cheers,
Peter
diff --git a/drivers/extcon/extcon-usbc-tusb320.c b/drivers/extcon/extcon-usbc-tusb320.c
index 2a120d8d3c27..dc586e5e3c65 100644
--- a/drivers/extcon/extcon-usbc-tusb320.c
+++ b/drivers/extcon/extcon-usbc-tusb320.c
@@ -78,6 +78,7 @@ struct tusb320_priv {
struct typec_capability cap;
enum typec_port_type port_type;
enum typec_pwr_opmode pwr_opmode;
+ bool initialized;
};
static const char * const tusb_attached_states[] = {
@@ -323,7 +324,7 @@ static irqreturn_t tusb320_irq_handler(int irq, void *dev_id)
return IRQ_NONE;
}
- if (!(reg & TUSB320_REG9_INTERRUPT_STATUS))
+ if (priv->initialized && !(reg & TUSB320_REG9_INTERRUPT_STATUS))
return IRQ_NONE;
tusb320_extcon_irq_handler(priv, reg);
@@ -479,6 +480,8 @@ static int tusb320_probe(struct i2c_client *client,
*/
tusb320_irq_handler(client->irq, priv);
+ priv->initialized = true;
+
ret = devm_request_threaded_irq(priv->dev, client->irq, NULL,
tusb320_irq_handler,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
--
2.20.1
Hi,
On 22. 12. 13. 07:36, Peter Rosin wrote:
> When the port is connected at boot, there is not necessarily
> an interrupt flagged in the interrupt status register, causing
> the IRQ handler to bail out early without reading the state when
> it is invoked directly from probe.
>
> Add a flag that overrides the interrupt status register and reads
> the state regardless during probe.
>
> Fixes: 06bc4ca115cd ("extcon: Add driver for TI TUSB320")
> Signed-off-by: Peter Rosin <[email protected]>
> ---
> drivers/extcon/extcon-usbc-tusb320.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Hi!
>
> This is basically a resend of v1, the patch has simply been adapted
> to fit after the driver changes for type-c support.
>
> Version 1 of the patch, with its brief "discussion", is here:
> https://lore.kernel.org/lkml/[email protected]/
>
> I cannot see how the patch can possibly affect detection of connector
> changes *after* 'priv->initialized = true', so the comment from Chanwoo
> Choi is still a mystery to me. The patch is about what happens *before*
> 'priv->initialized = true', i.e. when the IRQ handler is called directly
> during probe. There is no change in behavior after the statement
> 'priv->initialized = true', and IRQs are handled exactly as before once
> past that point.
>
> Please look at this patch again.
>
> Cheers,
> Peter
>
> diff --git a/drivers/extcon/extcon-usbc-tusb320.c b/drivers/extcon/extcon-usbc-tusb320.c
> index 2a120d8d3c27..dc586e5e3c65 100644
> --- a/drivers/extcon/extcon-usbc-tusb320.c
> +++ b/drivers/extcon/extcon-usbc-tusb320.c
> @@ -78,6 +78,7 @@ struct tusb320_priv {
> struct typec_capability cap;
> enum typec_port_type port_type;
> enum typec_pwr_opmode pwr_opmode;
> + bool initialized;
> };
>
> static const char * const tusb_attached_states[] = {
> @@ -323,7 +324,7 @@ static irqreturn_t tusb320_irq_handler(int irq, void *dev_id)
> return IRQ_NONE;
> }
>
> - if (!(reg & TUSB320_REG9_INTERRUPT_STATUS))
> + if (priv->initialized && !(reg & TUSB320_REG9_INTERRUPT_STATUS))
> return IRQ_NONE;
>
> tusb320_extcon_irq_handler(priv, reg);
> @@ -479,6 +480,8 @@ static int tusb320_probe(struct i2c_client *client,
> */
> tusb320_irq_handler(client->irq, priv);
>
> + priv->initialized = true;
> +
> ret = devm_request_threaded_irq(priv->dev, client->irq, NULL,
> tusb320_irq_handler,
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
I think that if priv->initialized=true on probe step,
tusb32_irq_handler return the always IRQ_NONE
because priv->initialized is never changed to false.
Is it right to keep the 'priv->initialized=true' always?
--
Best Regards,
Samsung Electronics
Chanwoo Choi
Hi!
2023-01-10 at 15:14, Chanwoo Choi wrote:
> Hi,
>
> On 22. 12. 13. 07:36, Peter Rosin wrote:
>> When the port is connected at boot, there is not necessarily
>> an interrupt flagged in the interrupt status register, causing
>> the IRQ handler to bail out early without reading the state when
>> it is invoked directly from probe.
>>
>> Add a flag that overrides the interrupt status register and reads
>> the state regardless during probe.
>>
>> Fixes: 06bc4ca115cd ("extcon: Add driver for TI TUSB320")
>> Signed-off-by: Peter Rosin <[email protected]>
>> ---
>> drivers/extcon/extcon-usbc-tusb320.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> Hi!
>>
>> This is basically a resend of v1, the patch has simply been adapted
>> to fit after the driver changes for type-c support.
>>
>> Version 1 of the patch, with its brief "discussion", is here:
>> https://lore.kernel.org/lkml/[email protected]/
>>
>> I cannot see how the patch can possibly affect detection of connector
>> changes *after* 'priv->initialized = true', so the comment from Chanwoo
>> Choi is still a mystery to me. The patch is about what happens *before*
>> 'priv->initialized = true', i.e. when the IRQ handler is called directly
>> during probe. There is no change in behavior after the statement
>> 'priv->initialized = true', and IRQs are handled exactly as before once
>> past that point.
>>
>> Please look at this patch again.
>>
>> Cheers,
>> Peter
>>
>> diff --git a/drivers/extcon/extcon-usbc-tusb320.c b/drivers/extcon/extcon-usbc-tusb320.c
>> index 2a120d8d3c27..dc586e5e3c65 100644
>> --- a/drivers/extcon/extcon-usbc-tusb320.c
>> +++ b/drivers/extcon/extcon-usbc-tusb320.c
>> @@ -78,6 +78,7 @@ struct tusb320_priv {
>> struct typec_capability cap;
>> enum typec_port_type port_type;
>> enum typec_pwr_opmode pwr_opmode;
>> + bool initialized;
>> };
>>
>> static const char * const tusb_attached_states[] = {
>> @@ -323,7 +324,7 @@ static irqreturn_t tusb320_irq_handler(int irq, void *dev_id)
>> return IRQ_NONE;
>> }
>>
>> - if (!(reg & TUSB320_REG9_INTERRUPT_STATUS))
>> + if (priv->initialized && !(reg & TUSB320_REG9_INTERRUPT_STATUS))
>> return IRQ_NONE;
>>
>> tusb320_extcon_irq_handler(priv, reg);
>> @@ -479,6 +480,8 @@ static int tusb320_probe(struct i2c_client *client,
>> */
>> tusb320_irq_handler(client->irq, priv);
>>
>> + priv->initialized = true;
>> +
>> ret = devm_request_threaded_irq(priv->dev, client->irq, NULL,
>> tusb320_irq_handler,
>> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>
> I think that if priv->initialized=true on probe step,
> tusb32_irq_handler return the always IRQ_NONE
> because priv->initialized is never changed to false.
The new behavior is to never return early when priv->initialized is
false. When priv->initialized is true, the old behavior is retained
through the right hand side of the && operator.
> Is it right to keep the 'priv->initialized=true' always?
Yes.
However, this patch is no longer needed. I have since noticed that
the problem was later solved by Marek Vasut with
581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending")
which does pretty much the same thing as this patch, but with
force_update as a function argument (and inverted logic, so
"if (!forced_update && ...)" in the above if-test instead of
"if (priv->initialized && ...)".)
Cheers,
Peter