Some other drivers may be waiting for our extcon to show-up, exiting their
probe methods with -EPROBE_DEFER until we show up.

These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to wait for the initial
processing of the id-pin to complete before exiting probe() with 0, which
will cause devices waiting on the defered probe to get reprobed.

This fixes a race where the initial work might still be running while other
drivers were already calling extcon_get_state().

Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
Changes in v2:
-Add Fixes tag

Changes in v3:
-Fix oops on probe by scheduling the work too early

Changes in v4:
-Ugh sorry about this, but we cannot call extcon_set_state() before
 extcon_dev_register() at all because before registration the cable array
 is not yet allocated. Instead wait for the initial processing of the
 id-pin to complete before exiting probe().
---
 drivers/extcon/extcon-intel-int3496.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-intel-int3496.c 
b/drivers/extcon/extcon-intel-int3496.c
index c8691b5a9cb0..191e99f06a9a 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -153,8 +153,9 @@ static int int3496_probe(struct platform_device *pdev)
                return ret;
        }
 
-       /* queue initial processing of id-pin */
+       /* process id-pin so that we start with the right status */
        queue_delayed_work(system_wq, &data->work, 0);
+       flush_delayed_work(&data->work);
 
        platform_set_drvdata(pdev, data);
 
-- 
2.14.3

Reply via email to