The device might be described in the device tree but not connected to
the I2C bus. Update the status property so that the DRM panel logic
returns -ENODEV when someone tries to get the panel attached to this
DT node.

Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: Eric Anholt <e...@anholt.net>
---
Rob, Thierry,

I know this v3 is not following your recommendations (propagate the
error to the upper layer and let the code in drivers/{base,i2c}/ handle
the reprobing of devices that previously returned EPROBE_DEFER and the
deregistration of the device that has been marked disabled), but it
addresses the problem Eric was trying to solve in a simple and
non-invasive way.

I'm all for a clean solution, but I also know this sort of rework is
likely to take time, so I'd appreciate having this patch accepted
first.

Regards,

Boris

Changes in v3:
- Do not return -ENODEV when the touchscree detection fails, so that
  the DRM driver can be probed again and detect that the panel status
  is "failed"

Changes in v2:
- New commit
---
 .../drm/panel/panel-raspberrypi-touchscreen.c | 46 +++++++++++++++++--
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 2c9c9722734f..26b5576c07f9 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -358,6 +358,39 @@ static const struct drm_panel_funcs rpi_touchscreen_funcs 
= {
        .get_modes = rpi_touchscreen_get_modes,
 };
 
+static void rpi_touchscreen_set_status_fail(struct i2c_client *i2c)
+{
+       struct property *newprop;
+
+       newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
+       if (!newprop)
+               return;
+
+       newprop->name = kstrdup("status", GFP_KERNEL);
+       if (!newprop->name)
+               goto err;
+
+       newprop->value = kstrdup("fail", GFP_KERNEL);
+       if (!newprop->value)
+               goto err;
+
+       newprop->length = sizeof("fail");
+
+       if (of_update_property(i2c->dev.of_node, newprop))
+               goto err;
+
+       /* We intentionally leak the memory we allocate here, because the new
+        * OF property might live longer than the underlying dev, so no way
+        * we can use devm_kzalloc() here.
+        */
+       return;
+
+err:
+       kfree(newprop->value);
+       kfree(newprop->name);
+       kfree(newprop);
+}
+
 static int rpi_touchscreen_probe(struct i2c_client *i2c,
                                 const struct i2c_device_id *id)
 {
@@ -376,14 +409,13 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
        if (!ts)
                return -ENOMEM;
 
-       i2c_set_clientdata(i2c, ts);
-
        ts->i2c = i2c;
 
        ver = rpi_touchscreen_i2c_read(ts, REG_ID);
        if (ver < 0) {
+               rpi_touchscreen_set_status_fail(i2c);
                dev_err(dev, "Atmel I2C read failed: %d\n", ver);
-               return -ENODEV;
+               return 0;
        }
 
        switch (ver) {
@@ -391,10 +423,13 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
        case 0xc3: /* ver 2 */
                break;
        default:
+               rpi_touchscreen_set_status_fail(i2c);
                dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
-               return -ENODEV;
+               return 0;
        }
 
+       i2c_set_clientdata(i2c, ts);
+
        /* Turn off at boot, so we can cleanly sequence powering on. */
        rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
 
@@ -435,6 +470,9 @@ static int rpi_touchscreen_remove(struct i2c_client *i2c)
 {
        struct rpi_touchscreen *ts = i2c_get_clientdata(i2c);
 
+       if (!ts)
+               return 0;
+
        mipi_dsi_detach(ts->dsi);
 
        drm_panel_remove(&ts->base);
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to