Messages in this thread | | | Subject | Re: [PATCH v10 0/9] Add the I3C subsystem | From | vitor <> | Date | Mon, 19 Nov 2018 12:35:42 +0000 |
| |
Hi Boris,
On 16/11/18 13:16, Boris Brezillon wrote: > On Fri, 16 Nov 2018 12:31:42 +0000 > vitor <vitor.soares@synopsys.com> wrote: > >> Hi Boris, >> >> >> On 15/11/18 19:00, Boris Brezillon wrote: >>> On Thu, 15 Nov 2018 18:03:47 +0000 >>> vitor <vitor.soares@synopsys.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@the-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. > 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?
Best regards,
Vitor Soares
| |