linux-kernel - Re: [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer

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: <20210410201302.GC2471@kunai>
Date:   Sat, 10 Apr 2021 22:13:02 +0200
From:   Wolfram Sang <wsa@...nel.org>
To:     Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc:     robh+dt@...nel.org, linux@...ck-us.net, jdelvare@...e.com,
        linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer

On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> received. This is particularly helpful with SMBUS devices like the LM81
> which will timeout if we take too long between bytes in a transfer.
> 
> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>

Okay, this change is too large and HW specific for a detailed review.
But I trust you and hope you will be around to fix regressions if I
apply it for 5.13? That kind of leads to the question if you want to
step up as the maintainer for this driver?

Only thing I noticed was a "BUG" and "BUG_ON" and wonder if we really
need to halt the kernel in that case. Maybe WARN is enough?

I'll apply the first five patches now, they look good to me.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)