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

Hi Greg,

On Wed, 20 Feb 2019, Greg Kroah-Hartman wrote:
> On Wed, Feb 20, 2019 at 04:22:00PM +0100, Nikolaus Voss wrote:
>>>> v2: fix tps6598x_exec_cmd also
>>>> ---
>>>>  drivers/usb/typec/tps6598x.c | 26 ++++++++++++++++++++------
>>>>  1 file changed, 20 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
>>>> index c84c8c189e90..c54b73fb2a2f 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];
>>>
>>> I thought the build system now warned when you did this :(
>>
>> I must admit I'm developing on 4.19 stable series, so no warnings...
>
> Ick, no, you are 6 months behind where the rest of us are :(
>
> Always, at the very least, work off of Linus's tree.  For best results,
> work off of linux-next.

we are a medical device manufacturer and our prototypes run stable 
kernels because our main development goal is the patient therapy.

However, what I do check is that my patches apply cleanly onto Linus's 
tree and if I see any other changes of files my patch touches I rebase and 
compile.

I'll try to always do the last before I submit a patch in the future but 
testing can only be done on our prototype branch (with reasonable effort).

Nikolaus