[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200219091658.7506e7bd@collabora.com>
Date: Wed, 19 Feb 2020 09:16:58 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Vitor Soares <Vitor.Soares@...opsys.com>
Cc: "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Jose Abreu <Jose.Abreu@...opsys.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"wsa@...-dreams.de" <wsa@...-dreams.de>,
"arnd@...db.de" <arnd@...db.de>,
"broonie@...nel.org" <broonie@...nel.org>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>
Subject: Re: [PATCH v3 0/5] Introduce i3c device userspace interface
On Wed, 19 Feb 2020 00:39:31 +0000
Vitor Soares <Vitor.Soares@...opsys.com> wrote:
> Hi Boris,
>
> From: Vitor Soares <vitor.soares@...opsys.com>
> Date: Wed, Feb 19, 2020 at 00:20:38
>
> > 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.
> >
> > - For now, the module exposes i3c devices without device driver on
> > dev/bus/i3c/<bus>-<pid>
> >
> > - As in the i2c subsystem, here it is exposed the i3c_priv_xfer to
> > userspace. I tried to use a dedicated structure as in spidev but I don't
> > see any obvious advantage.
> >
> > - Since the i3c API only exposes i3c_priv_xfer to devices, for now, the
> > module just makes use of one ioctl(). This can change in the future with
> > the introduction hdr commands or by the need of exposing some CCC
> > commands to the device API (private contract between master-slave).
> > Regarding the i3c device info, some information is already available
> > through sysfs. We can add more device attributes to expose more
> > information or add a dedicated ioctl() request for that purpose or both.
> >
> > - Similar to i2c, I have also created a tool that you can find in [2]
> > for testing purposes. If you have some time available I would appreciate
> > your feedback about it as well.
> >
> > [1] https://lkml.org/lkml/2018/11/15/853
> > [2] https://github.com/vitor-soares-snps/i3c-tools.git
> >
> > Changes in v3:
> > Use the xfer_lock to prevent device detach during ioctl call
> > Expose i3cdev under /dev/bus/i3c/ folder like usb does
> > Change NOTIFY_BOUND to NOTIFY_BIND, this allows the device detach occur
> > before driver->probe call
> > Avoid use of IS_ERR_OR_NULL
> > Use u64_to_user_ptr instead of (void __user *)(uintptr_t) cast
> > Allocate k_xfer and data_ptrs at once and eliminate double allocation
> > check
> > Pass i3cdev to dev->driver_data
> > Make all minors available
> > Add API documentation
> >
> > Changes in v2:
> > Use IDR api for minor numbering
> > Modify ioctl struct
> > Fix SPDX license
> >
> > Vitor Soares (5):
> > i3c: master: export i3c_masterdev_type
> > i3c: master: export i3c_bus_type symbol
> > i3c: master: add i3c_for_each_dev helper
> > i3c: add i3cdev module to expose i3c dev in /dev
> > userspace-api: add i3cdev documentation
> >
> > Documentation/userspace-api/i3c/i3cdev.rst | 116 ++++++++
> > drivers/i3c/Kconfig | 15 +
> > drivers/i3c/Makefile | 1 +
> > drivers/i3c/i3cdev.c | 429 +++++++++++++++++++++++++++++
> > drivers/i3c/internals.h | 2 +
> > drivers/i3c/master.c | 16 +-
> > include/uapi/linux/i3c/i3cdev.h | 38 +++
> > 7 files changed, 616 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/userspace-api/i3c/i3cdev.rst
> > create mode 100644 drivers/i3c/i3cdev.c
> > create mode 100644 include/uapi/linux/i3c/i3cdev.h
> >
> > --
> > 2.7.4
>
> I want to make you know that none of your previous comments was ignored
> and I would like to start the discussion from this point.
Sure, np. I'll probably wait for a v4 exploring the option I proposed
then.
Powered by blists - more mailing lists