netdev - Re: question about i2c_transfer() function (regarding mdio-i2c on RollBall SFPs)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210108084051.GA1223@kunai>
Date:   Fri, 8 Jan 2021 09:40:51 +0100
From:   Wolfram Sang <wsa@...nel.org>
To:     Marek Behun <marek.behun@....cz>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        Pali Rohár <pali@...nel.org>,
        linux-i2c@...r.kernel.org
Subject: Re: question about i2c_transfer() function (regarding mdio-i2c on
 RollBall SFPs)

> I thought as much, but maybe there is some driver which can offload
> whole i2c_transfer to HW, and has to pass the addresses of the buffers
> to the HW, and the HW can have problems if the buffers overlap
> somewhere...

Well, sure, you can never know what crazy HW is out there :) But that
shouldn't prevent us from doing legit I2C transfers. The likeliness of
such HW is low enough; They must process the whole transfer in one go
(rare) AND have the limitiation with the buffer pointers (at least I
don't know one) AND have no possibility of a fallback to a simpler mode
where they can handle the transfer per message. If such a controller
exists, it would need a new quirk flag, I'd say, and reject the
transfer. But that shouldn't stop you from fixing your issue.

Thanks for thinking thoroughly about drawbacks! Much appreciated.

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