Message-ID: <CAK8P3a1NWo11JzR6wEk_fcQFoJBmJwA1ynjHdCnEK8PF4Q2-=Q@mail.gmail.com>
Date:   Tue, 24 Jul 2018 22:21:20 +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:54 PM, Boris Brezillon
<boris.brezillon@...tlin.com> wrote:
> On Tue, 24 Jul 2018 18:25:22 +0200
> Arnd Bergmann <arnd@...db.de> wrote:
>
>> 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:
>> >> 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?
>
> Hehe, if I had a clear answer to this question we wouldn't have this
> discussion :-). I gave you an example:
>
> - master A supporting IBIs but not HDR transactions
> - master B supporting HDR modes but not IBIs
>
> but as I said, I'm not sure how likely this example is...

I'd say for a specific example like that, the person that did the
SoC integration should find a new job outside of hardware
design ;-)

I suppose the point is really that this is only preparation for something
completely unexpected, and any specific example one could come
up with is very unlikely to occur in real hardware.

> The question is more, should we design things so that we can at some
> point implement a solution to support those funky setups, or should we
> just ignore it and risk breaking sysfs/DT ABI when/if we have to support
> that?
>
> This is really an open question. I initially went for the former, but
> have no objection switching to the latter.

For me it's mainly a feeling that the risk of something going wrong
with the current design is bigger than it actually solving problems
we will encounter later. I hope that when you do a v7 version for
comparison, I'll be able to pinpoint specific aspects that are better
rather than being that unspecific. (note: I'll be on vacation next
week and won't be able to review it until I'm back).

Let me try to summarize the points made so far:

1. If we need a way for dynamic handover between two of our
    own masters and are not prepared for it now, some hardware
    designs may end up being unusable junk. Hopefully those
    cases are rare and found early during design when the hardware
    can still be changed to something that works.

2. If we design a system that does allow that handover and we don't
    need it, the biggest risk is introducing complexity in the system
    that makes it harder to use and debug for everyone.

3. The case where we have two masters on a bus, but each
    slave is only ever driven by one master can easily be added
    later, by adding some DT description for that machine as I
    described, but no extra code or DT bindings, or reprobing
    of devices during handover.

4. Handing over between an i2c master and an i3c master cannot
    be done with the current design either way, and could only ever
    work in very limited scenarios. The same is true for i3c masters
    that can be connected to the same bus, but not at the same
    time (like the case with multiplexed i2c masters today).

5. The debug scenario that Wolfram described might be handled
    with a separate bus structure and handing over behind the
    curtains, but does not require it to be done without a reprobe.
    I can imagine several other (simpler) designs that would allow
    doing this.

        Arnd

Powered by blists - more mailing lists