linux-kernel - Re: [PATCH v1 06/11] ti948: Reconfigure in the alive check when device returns

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8aed947d-91ae-c67b-9911-9365bf80aac3@codethink.co.uk>
Date:   Fri, 12 Jul 2019 13:43:21 +0100
From:   Michael Drake <michael.drake@...ethink.co.uk>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Andrzej Hajda <a.hajda@...sung.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...ts.codethink.co.uk,
        Patrick Glaser <pglaser@...la.com>, Nate Case <ncase@...la.com>
Subject: Re: [PATCH v1 06/11] ti948: Reconfigure in the alive check when
 device returns

Hi Laurent,

On 11/06/2019 19:10, Laurent Pinchart wrote:
> Hi Michael,
> 
> Thank you for the patch.

My pleasure, and thank you for the feedback!

> On Tue, Jun 11, 2019 at 03:04:07PM +0100, Michael Drake wrote:
>> If the alive check detects a transition to the alive state,
>> the device configuration is rewritten.
> 
> This seems like a big hack. You will have at the very least to explain
> why this is needed, and why you can't configure the device in response
> to drm_bridge operation calls.

The ti948 device is situated inside the housing of the LCD
panel.  The ti949 is a normal i2c device on the system i2c
bus.  In order for the ti948 to appear on the system's i2c
bus, the ti949 must be powered up and configured.

The panel is connected to the system via the FPD-Link III.
If a connector for the wire to the display is unplugged and
re-inserted, then the ti948 will drop out and come back.

Application note AN-2173, "I2C Communication Over
FPD-LinkIII with Bidirectional Control Channel" describes
this:

  http://www.ti.com/lit/an/snla131a/snla131a.pdf

Perhaps I need to expand the commit message to explain this?

Alternatively is there a more standard way of dealing with
remotely connected i2c devices?

>> Signed-off-by: Michael Drake <michael.drake@...ethink.co.uk>
>> Cc: Patrick Glaser <pglaser@...la.com>
>> Cc: Nate Case <ncase@...la.com>
>> ---
>>  drivers/gpu/drm/bridge/ti948.c | 19 ++++++++++++++++++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti948.c b/drivers/gpu/drm/bridge/ti948.c
>> index 86daa3701b91..b5c766711c4b 100644
>> --- a/drivers/gpu/drm/bridge/ti948.c
>> +++ b/drivers/gpu/drm/bridge/ti948.c
>> @@ -132,6 +132,8 @@ struct ti948_reg_val {
>>   * @reg_names:   Array of regulator names, or NULL.
>>   * @regs:        Array of regulators, or NULL.
>>   * @reg_count:   Number of entries in reg_names and regs arrays.
>> + * @alive_check: Context for the alive checking work item.
>> + * @alive:       Whether the device is alive or not (alive_check).
>>   */
>>  struct ti948_ctx {
>>  	struct i2c_client *i2c;
>> @@ -141,6 +143,8 @@ struct ti948_ctx {
>>  	const char **reg_names;
>>  	struct regulator **regs;
>>  	size_t reg_count;
>> +	struct delayed_work alive_check;
>> +	bool alive;
>>  };
>>  
>>  static bool ti948_readable_reg(struct device *dev, unsigned int reg)
>> @@ -346,6 +350,8 @@ static int ti948_power_on(struct ti948_ctx *ti948)
>>  	if (ret != 0)
>>  		return ret;
>>  
>> +	ti948->alive = true;
>> +
>>  	msleep(500);
>>  
>>  	return 0;
>> @@ -356,6 +362,8 @@ static int ti948_power_off(struct ti948_ctx *ti948)
>>  	int i;
>>  	int ret;
>>  
>> +	ti948->alive = false;
>> +
>>  	for (i = ti948->reg_count; i > 0; i--) {
>>  		dev_info(&ti948->i2c->dev, "Disabling %s regulator\n",
>>  				ti948->reg_names[i - 1]);
>> @@ -388,8 +396,17 @@ static void ti948_alive_check(struct work_struct *work)
>>  {
>>  	struct delayed_work *dwork = to_delayed_work(work);
>>  	struct ti948_ctx *ti948 = delayed_work_to_ti948_ctx(dwork);
>> +	int ret = ti948_device_check(ti948);
>>  
>> -	dev_info(&ti948->i2c->dev, "%s Alive check!\n", __func__);
>> +	if (ti948->alive == false && ret == 0) {
>> +		dev_info(&ti948->i2c->dev, "Device has come back to life!\n");
>> +		ti948_write_config_seq(ti948);
>> +		ti948->alive = true;
>> +
>> +	} else if (ti948->alive == true && ret != 0) {
>> +		dev_info(&ti948->i2c->dev, "Device has stopped responding\n");
>> +		ti948->alive = false;
>> +	}
>>  
>>  	/* Reschedule ourself for the next check. */
>>  	schedule_delayed_work(&ti948->alive_check, TI948_ALIVE_CHECK_DELAY);
> 

-- 
Michael Drake                 https://www.codethink.co.uk/