linux-kernel - [PATCH v2] extcon: usbc-tusb320: make sure the state is initialized on probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2022 23:36:13 +0100
From:   Peter Rosin <peda@...ntia.se>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Michael Auchter <michael.auchter@...com>
Subject: [PATCH v2] extcon: usbc-tusb320: make sure the state is initialized
 on probe

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 <peda@...ntia.se>
---
 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/ab1ad93b-4d39-8863-9704-da779fc4c426@axentia.se/

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