From: Vitor Soares <Vitor.Soares@synopsys.com> To: linux-kernel@vger.kernel.org, linux-i3c@lists.infradead.org Cc: Joao.Pinto@synopsys.com, bbrezillon@kernel.org, gregkh@linuxfoundation.org, wsa@the-dreams.de, arnd@arndb.de, broonie@kernel.org, Vitor Soares <Vitor.Soares@synopsys.com> Subject: [RFC 0/5] Introduce i3c device userspace interface Date: Tue, 10 Dec 2019 16:37:28 +0100 [thread overview] Message-ID: <cover.1575977795.git.vitor.soares@synopsys.com> (raw) 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/i3c-<bus>-<pid>, but we can change the path to dev/bus/i3c/<bus>-<pid> or dev/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 Vitor Soares (5): i3c: master: export i3c_masterdev_type i3c: master: export i3c_bus_type symbol i3c: device: expose transfer strutures to uapi i3c: master: add i3c_for_each_dev helper i3c: add i3cdev module to expose i3c dev in /dev drivers/i3c/Kconfig | 15 ++ drivers/i3c/Makefile | 1 + drivers/i3c/i3cdev.c | 438 ++++++++++++++++++++++++++++++++++++++++ drivers/i3c/internals.h | 2 + drivers/i3c/master.c | 16 +- include/linux/i3c/device.h | 54 +---- include/uapi/linux/i3c/device.h | 66 ++++++ include/uapi/linux/i3c/i3cdev.h | 27 +++ 8 files changed, 565 insertions(+), 54 deletions(-) create mode 100644 drivers/i3c/i3cdev.c create mode 100644 include/uapi/linux/i3c/device.h create mode 100644 include/uapi/linux/i3c/i3cdev.h -- 2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Vitor Soares <Vitor.Soares@synopsys.com> To: linux-kernel@vger.kernel.org, linux-i3c@lists.infradead.org Cc: Joao.Pinto@synopsys.com, arnd@arndb.de, wsa@the-dreams.de, gregkh@linuxfoundation.org, bbrezillon@kernel.org, Vitor Soares <Vitor.Soares@synopsys.com>, broonie@kernel.org Subject: [RFC 0/5] Introduce i3c device userspace interface Date: Tue, 10 Dec 2019 16:37:28 +0100 [thread overview] Message-ID: <cover.1575977795.git.vitor.soares@synopsys.com> (raw) 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/i3c-<bus>-<pid>, but we can change the path to dev/bus/i3c/<bus>-<pid> or dev/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 Vitor Soares (5): i3c: master: export i3c_masterdev_type i3c: master: export i3c_bus_type symbol i3c: device: expose transfer strutures to uapi i3c: master: add i3c_for_each_dev helper i3c: add i3cdev module to expose i3c dev in /dev drivers/i3c/Kconfig | 15 ++ drivers/i3c/Makefile | 1 + drivers/i3c/i3cdev.c | 438 ++++++++++++++++++++++++++++++++++++++++ drivers/i3c/internals.h | 2 + drivers/i3c/master.c | 16 +- include/linux/i3c/device.h | 54 +---- include/uapi/linux/i3c/device.h | 66 ++++++ include/uapi/linux/i3c/i3cdev.h | 27 +++ 8 files changed, 565 insertions(+), 54 deletions(-) create mode 100644 drivers/i3c/i3cdev.c create mode 100644 include/uapi/linux/i3c/device.h create mode 100644 include/uapi/linux/i3c/i3cdev.h -- 2.7.4 _______________________________________________ linux-i3c mailing list linux-i3c@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-i3c
next reply other threads:[~2019-12-10 15:37 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-10 15:37 Vitor Soares [this message] 2019-12-10 15:37 ` [RFC 0/5] Introduce i3c device userspace interface Vitor Soares 2019-12-10 15:37 ` [RFC 1/5] i3c: master: export i3c_masterdev_type Vitor Soares 2019-12-10 15:37 ` Vitor Soares 2019-12-10 15:37 ` [RFC 2/5] i3c: master: export i3c_bus_type symbol Vitor Soares 2019-12-10 15:37 ` Vitor Soares 2019-12-10 15:37 ` [RFC 3/5] i3c: device: expose transfer strutures to uapi Vitor Soares 2019-12-10 15:37 ` Vitor Soares 2019-12-12 14:42 ` Greg KH 2019-12-12 14:42 ` Greg KH 2019-12-12 14:48 ` Vitor Soares 2019-12-12 14:48 ` Vitor Soares 2019-12-10 15:37 ` [RFC 4/5] i3c: master: add i3c_for_each_dev helper Vitor Soares 2019-12-10 15:37 ` Vitor Soares 2019-12-10 15:37 ` [RFC 5/5] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares 2019-12-10 15:37 ` Vitor Soares 2019-12-10 17:51 ` Arnd Bergmann 2019-12-10 17:51 ` Arnd Bergmann 2019-12-10 19:15 ` Vitor Soares 2019-12-10 19:15 ` Vitor Soares 2019-12-10 19:37 ` Arnd Bergmann 2019-12-10 19:37 ` Arnd Bergmann 2019-12-11 15:07 ` Vitor Soares 2019-12-11 15:07 ` Vitor Soares 2019-12-11 15:33 ` Arnd Bergmann 2019-12-11 15:33 ` Arnd Bergmann 2019-12-20 12:39 ` Vitor Soares 2019-12-20 12:39 ` Vitor Soares 2019-12-12 14:44 ` Greg KH 2019-12-12 14:44 ` Greg KH 2019-12-12 14:56 ` Vitor Soares 2019-12-12 14:56 ` Vitor Soares 2019-12-12 16:00 ` Greg KH 2019-12-12 16:00 ` Greg KH 2019-12-12 17:25 ` Vitor Soares 2019-12-12 17:25 ` Vitor Soares 2019-12-12 17:32 ` Greg KH 2019-12-12 17:32 ` Greg KH 2019-12-12 14:46 ` Greg KH 2019-12-12 14:46 ` Greg KH
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1575977795.git.vitor.soares@synopsys.com \ --to=vitor.soares@synopsys.com \ --cc=Joao.Pinto@synopsys.com \ --cc=arnd@arndb.de \ --cc=bbrezillon@kernel.org \ --cc=broonie@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-i3c@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.