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
| ||
|
Date: Tue, 1 Aug 2017 11:47:15 -0500 From: "Andrew F. Davis" <afd@...com> To: Wolfram Sang <wsa@...-dreams.de>, Boris Brezillon <boris.brezillon@...e-electrons.com> CC: Arnd Bergmann <arnd@...db.de>, <linux-i2c@...r.kernel.org>, Jonathan Corbet <corbet@....net>, <linux-doc@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Przemyslaw Sroka <psroka@...ence.com>, Arkadiusz Golec <agolec@...ence.com>, Alan Douglas <adouglas@...ence.com>, Bartosz Folta <bfolta@...ence.com>, Damian Kos <dkos@...ence.com>, Alicja Jurasik-Urbaniak <alicja@...ence.com>, Jan Kotas <jank@...ence.com>, Cyprian Wronka <cwronka@...ence.com>, Alexandre Belloni <alexandre.belloni@...e-electrons.com>, Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>, Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>, Mark Rutland <mark.rutland@....com>, Ian Campbell <ijc+devicetree@...lion.org.uk>, Kumar Gala <galak@...eaurora.org>, <devicetree@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure On 07/31/2017 04:42 PM, Wolfram Sang wrote: > >> Actually, that's the first option I considered, but I3C and I2C are >> really different. I'm not talking about the physical layer here, but >> the way the bus has to be handled by the software layer. Actually, I >> thing the I3C bus is philosophically closer to auto-discoverable busses >> like USB than I2C or SPI. > > Acked-by: Wolfram Sang <wsa@...-dreams.de> > >> Of course, I can move all the code in drivers/i2c/, but that won't >> change the fact that I3C and I2C busses are completely different >> with little to share between them. > > That wouldn't make sense. > >> To me, the I2C backward compatibility is just a nice feature that was >> added to help people smoothly transition from mixed I3C busses with >> both I2C and I3C devices connected to it (I2C devices being here >> when no (affordable) equivalent exist in the I3C world) to pure I3C >> busses with only I3C devices connected to it. > > Yeah, and it is still to be seen how good this really works. Devices > which do clock stretching are out of the question. Probably everything > which needs an interrupt as well? > I'm surprised they didn't allow for slave clock stretching when communicating with a legacy i2c device, it will prohibit use of a rather large class of devices. :( As for interrupts you are always free to wire up an out-of-band interrupt like before. :) >> This being said, I'd be happy if you prove me wrong and propose a >> solution that allows us to extend the I2C framework to support I3C >> without to much pain ;-). > > From all I know, I don't see that coming. >
Powered by blists - more mailing lists