linux-kernel - Re: [PATCH v6 00/10] Add the I3C subsystem

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]

Date:   Tue, 24 Jul 2018 18:04:52 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Peter Rosin <peda@...ntia.se>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <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>,
        Cyprian Wronka <cwronka@...ence.com>,
        Suresh Punnoose <sureshp@...ence.com>,
        Rafal Ciepiela <rafalc@...ence.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.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>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vitor Soares <Vitor.Soares@...opsys.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Xiang Lin <Xiang.Lin@...aptics.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>, Przemyslaw Gaj <pgaj@...ence.com>
Subject: Re: [PATCH v6 00/10] Add the I3C subsystem

On Tue, Jul 24, 2018 at 5:57 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
>
>> > Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
>> > transfers to the PMIC, the other has I2C slave functionality. One cannot
>> > do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
>> > Sometimes you can mux the pins to GPIO, so you have a third option.
>> >
>> > This setup is the reason the demux driver exists.
>>
>> Have you run into scenarios where you dynamically switch between
>> the two masters in order to do different things (on one slave, or
>> on multiple slaves), or could you always decide on one of them
>> at boot time with that particular chip?
>
> My personal use case is debugging. R-Car H2 is great because I can
> always pinmux this or that I2C IP core to the same set of pins, and in 2
> out of 4 cases even GPIO bitbang on top of that. So, it is great to
> compare behaviour, do scopes with the same type of setup, etc...
> For that, I do runtime switches, but the slaves are not really under
> real usage.

Ok, so runtime here still means it's chosen by an operator (i.e. you),
not part of regular operation.

> I have absolutely no idea how $customers use it, sadly.

Right.

>> I think an SoC design we will likely see is an i3c master multiplexed with
>> an i2c master to access one bus. The i2c master can then use clock
>> stretching and other things that may not work in the i3c master, and it
>> may be used in the absence of proper i3c drivers in the OS.
>
> Multiplexed? Well, as soon you want to use I3C features like IBI, this
> is not going to work, right? It will not even work with Linux being an
> I2C slave itself. Or do you mean running the I3C and I2C controller
> simultaneously using the same wires?

I meant multiplexing it through the pinmux framework, with one of the
two being active at any time. Obviously this makes no sense for
i3c slaves, but it can be useful if the bus only contains i2c slaves.

>> However, that case cannot be handled with the abstraction in the
>> proposed i3c framework, which can only deal with multiple i3c
>> standard compliant masters. I'm also not sure if it can be added
>> to the i2c-demux-pinctrl driver.
>
> The I2C demuxer maps the whole bus to an i2c_adapter. You cannot select
> a master per client.

What I meant here was switching the bus between an i2c master and an
i3c master like you do with the i2c demuxer. Right now, this wouldn't
work because i2c and i3c use different representations in DT and in
Linux for the same devices.

     Arnd