Date:   Fri, 16 Nov 2018 12:50:39 +0000
From:   Przemyslaw Gaj <pgaj@...ence.com>
To:     vitor <vitor.soares@...opsys.com>,
        Boris Brezillon <boris.brezillon@...tlin.com>
CC:     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>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>, Peter Rosin <peda@...ntia.se>,
        Mike Shettel <mshettel@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v10 0/9] Add the I3C subsystem

Hi Vitor,

On 11/16/18, 1:32 PM, "vitor" <vitor.soares@...opsys.com> wrote:

    EXTERNAL MAIL
    
    
    Hi Boris,
    
    
    On 15/11/18 19:00, Boris Brezillon wrote:
    > On Thu, 15 Nov 2018 18:03:47 +0000
    > vitor <vitor.soares@...opsys.com> wrote:
    >
    >> Hi Boris,
    >>
    >>
    >> On 15/11/18 15:28, Boris Brezillon wrote:
    >>> On Thu, 15 Nov 2018 16:01:37 +0100
    >>> Wolfram Sang <wsa@...-dreams.de> wrote:
    >>>   
    >>>> Hi Boris,
    >>>>   
    >>>>> What we could do though, is expose I3C devices that do not have a
    >>>>> driver in kernel space, like spidev does.
    >>>> ...
    >>>>   
    >>>>> Mark, Wolfram, Arnd, Greg, any opinion?
    >>>> Is there a benefit for having drivers in userspace? My gut feeling is to
    >>>> encourage people to write kernel drivers. If this is, for some reason,
    >>>> not possible for some driver, then we have a use case at hand to test
    >>>> the then-to-be-developed userspace interface against. Until then, I
    >>>> personally wouldn't waste effort on designing it without a user in
    >>>> sight.
    >>> I kind of agree with that. Vitor, do you have a use case in mind for
    >>> such userspace drivers? I don't think it's worth designing an API for
    >>> something we don't need (yet).
    >> My use case is a tool for tests, lets say like the i2c tools.
    > What would you like to test exactly?
    >
    >> There is
    >> other subsystems, some of them mentioned on this thread, that have and
    >> ioctl system call or other method to change parameters or send data.
    > I don't think they added the /dev interface before having a real use
    > case for it.
    >
    >>
    >> I rise this topic because I really think it worth to define now how this
    >> should be design (and for me how to do the things right) to avoid future
    >> issues.
    > Actually it should be done the other way around: you should have a real
    > need and the /dev interface should be designed to fulfill this need.
    > Based on this real use case we can discuss other potential usage that
    > might appear in the future and try to design something more
    > future-proof, but clearly, this userspace interface should be driven by
    > a real/well-defined use case.
    >
    > Also, exposing things to userspace is way more risky than adding a new
    > in-kernel subsystem/framework, because it then becomes part of the
    > stable ABI.
    >
    > To make things clearer, I'm not against the idea of exposing I3C
    > devices (or I3C buses) to userspace, but I'd like to understand what you
    > plan to do with that. If this is about testing, what kind of tests
    > you'd like to run. If this is about developing drivers in userspace,
    > why can't these be done in kernel space (license issues?), and what
    > would those drivers be allowed to do?
    
    
    Basically I need a tool that help me during the development and to avoid 
    me to write a dummy driver for each device that I test.

For now we are doing it that way. Separate dummy driver for each device.
    
    For instances do some read/write, get/set ccc commands, if something 
    goes wrong during the bus initialization have a to debug etc...
    
That sounds good to have possibility to make simple reads/writes and 
send basic ccc commands. But of course keeping in mind that I3C bus is 
more complicated than I2C, as Boris mentioned before.
    
    For me this is a valid use case and I imagine when people start to 
    develop in i3c this interface will help everyone.
    
    
    Best regards,
    
    Vitor Soares
    
Regards,
Przemek
    

Powered by blists - more mailing lists