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]

Message-ID: <CAK8P3a0wcmeFKvRf7=FTNvePayc2AxniHoNkLOuzQQCt=MiLjQ@mail.gmail.com>
Date:   Tue, 24 Jul 2018 18:25:22 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Peter Rosin <peda@...ntia.se>,
        Wolfram Sang <wsa@...-dreams.de>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Greg KH <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>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vitor Soares <Vitor.Soares@...opsys.com>,
        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 6:14 PM, Boris Brezillon
<boris.brezillon@...tlin.com> wrote:
> On Tue, 24 Jul 2018 17:58:29 +0200
> Arnd Bergmann <arnd@...db.de> wrote:
>
>> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
>> <geert@...ux-m68k.org> wrote:
>> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@...db.de> wrote:
>> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
>> >> <geert@...ux-m68k.org> wrote:
>> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@...db.de> wrote:
>> The second case is the one that started the discussion, and
>> this is where I said I'd prefer to associate each slave with at
>> most one master at boot time, while the current v6 patch
>> is prepared for having one slave be accessed alternatingly
>> by multiple masters using the master handover, though so
>> far nobody has been able to describe exactly how we'd pick
>> which master is active at what point,
>
> Even if it's not yet implemented, I have everything in place to figure
> this out (see the ->cur_master field in the i3c_bus object). Now,
> what's missing is a list of possible masters attached to an i3c device
> so that the framework can pick the most appropriate one at runtime and
> initiate mastership handover if required (if the selected master is not
> the currently active one).
>
> The selection logic should look like this:
>
>         if (active_master supports requested feature)
>                 use active master
>         else
>                 pick an inactive one that has relevant caps and initiate
>                 mastership handover (+ update bus->cur_master)

How would you deal with soft requirements like performance?
E.g. if you have one master that can do large transfers faster
through a special DMA engine, and other master that can
be faster for small transfers, but both support all capabilities
for that device, won't you need some complex logic to avoid
being stuck with a slow master indefinitely?

>> or what specific scenario
>> would require it.
>
> I think I described a scenario (masters having different
> capabilities all connected to the same bus), though I don't know how
> likely this use case is :-/.

I was looking for something more specific here. What (lack of)
capabilities could two i3c controllers have that require you to
use both of them for the same device, rather than picking
a master for each slave with the right feature set?

     Arnd