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:   Thu, 12 Jul 2018 10:08:05 +0200
From:   Arnd Bergmann <>
To:     Peter Rosin <>
Cc:     Boris Brezillon <>,
        Wolfram Sang <>,,
        Jonathan Corbet <>,
        "open list:DOCUMENTATION" <>,
        Greg Kroah-Hartman <>,
        Przemyslaw Sroka <>,
        Arkadiusz Golec <>,
        Alan Douglas <>,
        Bartosz Folta <>,
        Damian Kos <>,
        Alicja Jurasik-Urbaniak <>,
        Cyprian Wronka <>,
        Suresh Punnoose <>,
        Rafal Ciepiela <>,
        Thomas Petazzoni <>,
        Nishanth Menon <>, Rob Herring <>,
        Pawel Moll <>,
        Mark Rutland <>,
        Ian Campbell <>,
        Kumar Gala <>,
        DTML <>,
        Linux Kernel Mailing List <>,
        Vitor Soares <>,
        Geert Uytterhoeven <>,
        Linus Walleij <>,
        Xiang Lin <>,
Subject: Re: [PATCH v4 01/10] i3c: Add core I3C infrastructure

On Thu, Jul 12, 2018 at 6:41 AM, Peter Rosin <> wrote:
> On 2018-07-11 19:12, Boris Brezillon wrote:
>> On Wed, 11 Jul 2018 17:39:56 +0200 Arnd Bergmann <> wrote:
>> That's exactly the sort of discussion I wanted to trigger. Maybe we
>> shouldn't care and expose this use case as if it was X different I3C
>> buses (with all devices present on the bus being exposed X times to the
>> system).
> For I2C, this multiple masters for one bus case was retrofitted in
> the i2c-demux-pinctrl driver. It's a huge kludge with a number of
> undesirable quirks. I don't know if the circumstances for adding
> this I2C driver also applies for I3C, but it might be an argument
> in favor of the proposed extra bus object...

>From reading the documentation and git history on that driver,
it seems to be used only for static configuration, i.e. you use
one driver or the other, but don't flip between them at runtime,

I'm guessing that even with i3c we may have to support something
like that, as a likely scenario might be that the i3c controller is
multiplexed with a traditional i2c controller and/or gpios, but you
would not be able to perform the i3c standard secondary master
transition with the latter two because they are (by definition) not
i3c compatible.


Powered by blists - more mailing lists