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  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]
Date:   Tue, 7 Jul 2020 23:03:00 +0900
From:   Sungbo Eo <>
To:     Andy Shevchenko <>,
        Bartosz Golaszewski <>
Cc:     Linus Walleij <>,
        Michael Walle <>,
        LKML <>,
        linux-gpio <>
Subject: Re: [PATCH v5 1/2] gpio: add GPO driver for PCA9570

On 20. 7. 6. 오후 9:00, Andy Shevchenko wrote:
> On Mon, Jul 6, 2020 at 2:21 PM Bartosz Golaszewski
> <> wrote:>
>> On Sun, Jul 5, 2020 at 3:31 PM Sungbo Eo <> wrote:
>>> NXP PCA9570 is a 4-bit I2C GPO expander without interrupt functionality.
>>> Its ports are controlled only by a data byte without register address.
>>> Datasheet:
> No blank line here.
>>> Signed-off-by: Sungbo Eo <>
>> This driver looks nice now but why did you remove the mutex in v3? I
>> think when Andy commented on that, he meant not understanding why the
>> error check is protected, not the i2c operations.
> Right.

Oh, probably I misunderstood the comment... :(

But I don't really understand what mutex does here. The driver does not 
need consecutive commands, it only sends/receives only one byte at a 
time. And AFAIK each i2c_smbus function is already protected by a mutex. 
So what should be exactly inside the lock? Should we protect the output 
buffer as well? I'm not an expert on this so please enlighten me.

Thanks for your kind reviews, as always. :)

>> Are you sure you don't need this lock?
> It's a good point!

Powered by blists - more mailing lists