Re: [PATCH v10 0/9] Add the I3C subsystem

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

On Mon, 19 Nov 2018 12:35:42 +0000
vitor <vitor.soares@xxxxxxxxxxxx> wrote:

> Hi Boris,
> 
> On 16/11/18 13:16, Boris Brezillon wrote:
> > On Fri, 16 Nov 2018 12:31:42 +0000
> > vitor <vitor.soares@xxxxxxxxxxxx> wrote:
> >  
> >> Hi Boris,
> >>
> >>
> >> On 15/11/18 19:00, Boris Brezillon wrote:  
> >>> On Thu, 15 Nov 2018 18:03:47 +0000
> >>> vitor <vitor.soares@xxxxxxxxxxxx> wrote:
> >>>     
> >>>> Hi Boris,
> >>>>
> >>>>
> >>>> On 15/11/18 15:28, Boris Brezillon wrote:  
> >>>>> On Thu, 15 Nov 2018 16:01:37 +0100
> >>>>> Wolfram Sang <wsa@xxxxxxxxxxxxx> 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.  
> > But we want I3C device drivers to be upstreamed, so why not developing a
> > real driver everytime you test a new device and submitting it upstream?  
> 
> 
> Usually the devices that I test aren't the final product so it isn't 
> easy to do the upstream.
> 
> But when possible I plan to do that.
> 
> 
> >  
> >> For instances do some read/write,  
> > Doing SDR/DDR transfers is probably acceptable, but I still think we
> > should push hard to have kernel drivers when that's possible.
> >  
> >> get/set ccc commands,  
> > Exposing CCC commands is definitely not a good idea, since they're not
> > even exposed to kernel drivers.
> >  
> >> if something
> >> goes wrong during the bus initialization have a to debug etc...  
> > Can't we add such a debug infrastructure in the kernel. Maybe we can
> > expose debugfs files too if that helps, though if those debugfs files
> > are actually used by userspace libs/tools, it's not any better than
> > ioctls or sysfs files, since they will anyway become a stable ABI.
> >  
> >>
> >> For me this is a valid use case and I imagine when people start to
> >> develop in i3c this interface will help everyone.  
> > How about you propose an i3cdev driver that allow users to do SDR
> > transfers throuh an ioctl?  
> 
> I think that was for v6 I started to something to expose the bus like in 
> i2c-dev, but I liked the idea of expose only the device doesn't have a 
> driver. Do you know if  there is already something in the kernel doing 
> the same?

I know [1], but there might be other subsystems doing the same thing.

[1]https://elixir.bootlin.com/linux/v4.20-rc3/source/drivers/spi/spidev.c