Messages in this thread |  | | From | Vitor Soares <> | Subject | RE: [RFC v2 0/4] Introduce i3c device userspace interface | Date | Mon, 17 Feb 2020 15:32:55 +0000 |
| |
Hi Boris,
From: Boris Brezillon <boris.brezillon@collabora.com> Date: Mon, Feb 17, 2020 at 14:51:41
> Hello Vitor, > > Sorry for taking so long to reply, and thanks for working on that topic. > > On Wed, 29 Jan 2020 13:17:31 +0100 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > For today there is no way to use i3c devices from user space and > > the introduction of such API will help developers during the i3c device > > or i3c host controllers development. > > > > The i3cdev module is highly based on i2c-dev and yet I tried to address > > the concerns raised in [1]. > > > > NOTES: > > - The i3cdev dynamically request an unused major number. > > > > - The i3c devices are dynamically exposed/removed from dev/ folder based > > on if they have a device driver bound to it. > > May I ask why you need to automatically bind devices to the i3cdev > driver when they don't have a driver matching the device id > loaded/compiled-in? If we get the i3c subsystem to generate proper > uevents we should be able to load the i3cdev module and bind the device > to this driver using a udev rule.
My idea was to expose every device to user-space by default so we can test them without a driver (more or less the i2c use case) but as we agreed during the i3c subsystem only expose devices that doesn't have device driver. I considered to have a uevent but to expose the devices by default it would required something generic, what I didn't figure out and tend to follow the i2c-dev module.
With this current approach even if a device has a driver we can unbind it through the Sysfs and have access from user space which I found useful for debug.
> > Regards, > > Boris
|  |