linux-kernel - Re: [PATCH] usb: typec: tps6598x: handle block writes separately with plain-I2C adapters

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: <alpine.DEB.2.20.1902201352100.5820@fox.voss.local>
Date:   Wed, 20 Feb 2019 13:56:43 +0100 (CET)
From:   Nikolaus Voss <nv@...n.de>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: typec: tps6598x: handle block writes separately
 with plain-I2C adapters

Hi,

On Wed, 20 Feb 2019, Heikki Krogerus wrote:
> Hi,
>
> On Mon, Sep 10, 2018 at 07:05:01AM +0200, Nikolaus Voss wrote:
>> Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
>> adapters, but the problem described with regmap-i2c not handling
>> SMBus block transfers (i.e. read and writes) correctly also exists
>> with writes.
>>
>> As workaround, this patch adds a block write function the same way
>> 1a2f474d328f adds a block read function.
>>
>> Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with plain-I2C adapters")
>> Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
>> Signed-off-by: Nikolaus Voss <nikolaus.voss@...wensteinmedical.de>
>> ---
>>  drivers/usb/typec/tps6598x.c | 22 ++++++++++++++++++----
>>  1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
>> index c84c8c189e90..57a3e6c5c175 100644
>> --- a/drivers/usb/typec/tps6598x.c
>> +++ b/drivers/usb/typec/tps6598x.c
>> @@ -110,6 +110,20 @@ tps6598x_block_read(struct tps6598x *tps, u8 reg, void *val, size_t len)
>>  	return 0;
>>  }
>>
>> +static int tps6598x_block_write(struct tps6598x *tps, u8 reg,
>> +				void *val, size_t len)
>> +{
>> +	u8 data[len + 1];
>> +
>> +	if (!tps->i2c_protocol)
>> +		return regmap_raw_write(tps->regmap, reg, val, len);
>> +
>> +	data[0] = len;
>> +	memcpy(&data[1], val, len);
>> +
>> +	return regmap_raw_write(tps->regmap, reg, data, sizeof(data));
>> +}
>> +
>>  static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
>>  {
>>  	return tps6598x_block_read(tps, reg, val, sizeof(u16));
>> @@ -127,23 +141,23 @@ static inline int tps6598x_read64(struct tps6598x *tps, u8 reg, u64 *val)
>>
>>  static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
>>  {
>> -	return regmap_raw_write(tps->regmap, reg, &val, sizeof(u16));
>> +	return tps6598x_block_write(tps, reg, &val, sizeof(u16));
>>  }
>>
>>  static inline int tps6598x_write32(struct tps6598x *tps, u8 reg, u32 val)
>>  {
>> -	return regmap_raw_write(tps->regmap, reg, &val, sizeof(u32));
>> +	return tps6598x_block_write(tps, reg, &val, sizeof(u32));
>>  }
>>
>>  static inline int tps6598x_write64(struct tps6598x *tps, u8 reg, u64 val)
>>  {
>> -	return regmap_raw_write(tps->regmap, reg, &val, sizeof(u64));
>> +	return tps6598x_block_write(tps, reg, &val, sizeof(u64));
>>  }
>>
>>  static inline int
>>  tps6598x_write_4cc(struct tps6598x *tps, u8 reg, const char *val)
>>  {
>> -	return regmap_raw_write(tps->regmap, reg, &val, sizeof(u32));
>> +	return tps6598x_block_write(tps, reg, &val, sizeof(u32));
>>  }
>>
>>  static int tps6598x_read_partner_identity(struct tps6598x *tps)
>
> You need to fix tps6598x_exec_cmd() as well.

Right, thanks. I will fix that.

>
> Did you really send this last September? If you did, then the mail has
> been stuck somewhere for a long time.

It's been stuck with me, I forgot to send it ;-).

Nikolaus