linux-kernel - Re: [RFC 2/5] 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]

Message-ID: <20170803100334.64988a66@bbrezillon>
Date:   Thu, 3 Aug 2017 10:03:34 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Arnd Bergmann <arnd@...db.de>, linux-i2c@...r.kernel.org,
        Jonathan Corbet <corbet@....net>, 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>,
        Jan Kotas <jank@...ence.com>,
        Cyprian Wronka <cwronka@...ence.com>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.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,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 17:20:41 +0200
Boris Brezillon <boris.brezillon@...e-electrons.com> wrote:

> On Tue, 1 Aug 2017 17:01:08 +0200
> Wolfram Sang <wsa@...-dreams.de> wrote:
> 
> > > I do not know of any real devices as of today (all my tests have been
> > > done with a dummy/fake I3C slaves emulated with a slave IP),    
> > 
> > I see.
> >   
> > > spec clearly describe what legacy/static addresses are for and one of
> > > their use case is to connect an I3C device on an I2C bus and let it act
> > > as an I2C device.    
> > 
> > OK. That makes it more likely.
> >   
> > > Unless you want your device (likely a sensor) to be compatible with both
> > > I3C and I2C so that you can target even more people.    
> > 
> > Right. My question was if this is a realistic or more academic scenario.
> >   
> > > I'm perfectly fine with the I3C / I2C framework separation. The only
> > > minor problem I had with that was the inaccuracy of the
> > > sysfs/device-model representation: we don't have one i2c and one i3c
> > > bus, we just have one i3c bus with a mix of i2c and i3c devices.    
> > 
> > I understand that. What if I2C had the same seperation between the "bus"
> > and the "master"?
> >   
> 
> Yep, it might work if we can register an i2c_adapter and pass it an
> existing bus object. We'd still need a common base for i2c and i3c
> busses, unless we consider the bus as an opaque "struct device *"
> object.

I tried to envision how this could be implemented but realized
separating the bus and master concepts in I2C wouldn't solve all
problems.

Each device is attached a bus_type which defines how to match devices
and drivers, uevent format, ... But it also defines where the device
appears in sysfs (/sys/bus/<bus-name>/devices).

First question: where should an I2C device connected on an I3C bus
appear? /sys/bus/i3c/devices/ or /sys/bus/i2c/devices/? I'd say both
(with one of them being a symlink to the other) but I'm not sure.

Also, if we go for a 'single bus per master' representation but still
want i3c and i2c to be differentiated, that means when one adds an
i2c_driver we'll have to duplicate this driver object and register one
instance to the i2c framework and the other one to the i3c framework,
because device <-> driver matching is done per bus_type.

One solution would be to go for Arnd suggestion to extend i2c_bus_type
with I3C support, but then i3c related kojects would be exposed
under /sys/bus/i2c/ which can be disturbing for people who are used to
look at /sys/bus/<bus-name> to find devices connected on a specific bus
type.

Honestly, I don't know what's the best solution here. Every solution has
its pros and cons:

1/ The "one i2c bus and one i3c bus per i3c master" I proposed in this
   RFC is non-invasive but the resulting sysfs/device-model
   representation is not accurate.
2/ Separating the I3C and I2C framework with a thin layer between them
   to propagate i2c drivers registration to the i3c framework and make
   sure i2c devices are exposed in both worlds is much more complicated
   to implement but should provide an accurate bus <-> device
   representation.
3/ Extending i2c_bus_type (and more generally the I2C framework) to
   support I3C devices/busses is invasive and we still have a
   non-accurate representation (i2c busses are mixed with i3c busses
   and all exposed under /sys/bus/i2c/). One advantage with this
   solution compared to #2 is that we don't need to duplicate
   i2c_driver objects in order to register them to both i2c and i3c bus
   types.

Any advice is welcome.

Thanks,

Boris