linux-kernel - Re: [PATCH v4 01/10] i3c: Add core I3C infrastructure

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] [day] [month] [year] [list]

Date:   Thu, 12 Jul 2018 12:24:20 +0200
From:   Boris Brezillon <boris.brezillon@...tlin.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Wolfram Sang <wsa@...-dreams.de>, 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>, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v4 01/10] i3c: Add core I3C infrastructure

On Thu, 12 Jul 2018 12:03:05 +0200
Arnd Bergmann <arnd@...db.de> wrote:

> >> want to be in b) rather than c). An example of this would be
> >> an input device on a PC: If the user operateds the keyboard
> >> or pointer and we have handed off ownership to a sensor hub,
> >> we never get an input event, right?  
> >
> > Correct. I guess we could try to regain bus ownership in case we have
> > IBIs enabled. Or we let the secondary master give the bus back to us
> > when it sees IBIs it can't handle, as described in section 5.1.7:
> >
> > "
> > Once granted control of the Bus, the Secondary Master maintains
> > control until another Master is granted Bus control. After the
> > Secondary Master transitions to the Current Master role it could
> > encounter Bus management activities besides the data transfers that it
> > itself initiates. Some examples are the In-Band Interrupt, or the
> > Hot-Join request. One optional possibility, shown at Section 5.1.7.2,
> > is that the Secondary Master performs the Current Master’s actions with
> > the full capabilities of the Main Master. Another optional possibility
> > is that the Secondary Master, while serving in the Current Master role,
> > could defer some actions to a more capable Master, as described in
> > Section 5.1.7.3.
> > "  
> 
> Ah, so the current master can ask a secondary master to take over
> again even if  the secondary master has not requested to be come the
> current master?

Yes. Then the inactive master can refuse of course, but it is working
both ways:

- an inactive master can ask for bus ownership
- an active master can ask an inactive one to take over

> 
> >> > I agree. This being said, moving to a representation where the bus is
> >> > implicitly represented by the master_controller instance shouldn't be
> >> > too difficult. So, if you think we should try this approach I can do
> >> > the modifications in my v6.  
> >>
> >> I'd say let's wait before you do that change, possibly add a comment
> >> in there now to remind us of what an alternative would be.  
> >
> > You mean I should keep the i3c_bus object?  
> 
> I mean the ongoing discussion shouldn't stop you from posting a v6.

Ok.