linux-kernel - Re: [PATCH v6 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Aug 2018 15:01:14 +0200
From:   Boris Brezillon <boris.brezillon@...tlin.com>
To:     Przemyslaw Gaj <pgaj@...ence.com>
Cc:     vitor <Vitor.Soares@...opsys.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>, Wolfram Sang <wsa@...-dreams.de>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        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>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Xiang Lin <Xiang.Lin@...aptics.com>,
        Peter Rosin <peda@...ntia.se>
Subject: Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure

Hi Przemek,

On Tue, 28 Aug 2018 12:55:20 +0000
Przemyslaw Gaj <pgaj@...ence.com> wrote:

> Hi Vitor,
> 
> I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
> 
> On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@...tlin.com> wrote:
> 
>     EXTERNAL MAIL
>     
>     
>     Hi Vitor,
>     
>     On Tue, 28 Aug 2018 12:50:12 +0100
>     vitor <Vitor.Soares@...opsys.com> wrote:
>     
>     > Hi Boris,
>     > 
>     > The DT Bindings say "The node describing an I3C bus should be named 
>     > i3c-master.". Do you have a field for secondary master?  
> 
> I think we don’t need separate field for secondary master. Main and secondary masters 
> support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
> 
>     > 
>     > On 24-08-2018 19:16, Boris Brezillon wrote:  
>     > > Well, before even considering supporting secondary master registration,
>     > > we need to handle mastership handover. As for the DAA operation, it's
>     > > likely to be host specific, so we'll have to add a new hook to the
>     > > i3c_master_controller_ops struct.    
>     > Do you mean when master try to delegate the bus ownership through 
>     > GETACCMST? or to get the bus ownership with IBI-MR?  
>     
>     I think we need to support both.
> 
> I agree.
>     
>     > 
>     > I think that could be useful to pass the ibi type on request_ibi(), 
>     > there is some case where the master doesn't support IBI-MR.  
>     
>     Actually, I was planning on making it completely separate from
>     regular slave IBIs. That is, the master controller driver would demux
>     the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
>     mastership handover work to the workqueue (pretty much what we do for
>     Hot-Join already). Mastership handover is anyway likely to be IP
>     specific, so I don't think there's a need to make it look like a
>     regular IBI.
> 
> I think it's better to have separate function to do mastership request.
>     
>     Regarding whether IBI-MR support should be exposed to the I3C framework
>     or not depends on how much will be automated on the framework side. I
>     don't the answer yet, but that's probably something will figure out
>     along the road.
> 
> My current implementation is: when request_mastership field 
> of i3c_master_controller_ops structure is set, master driver supports mastership requests.
> That's how I check if this is supported or not.

Can you maybe host your code on a public repo (I can push it for you if
needed) so that you and Vitor can start discussing implementation
details.

Thanks,

Boris