All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitor Soares <Vitor.Soares@synopsys.com>
To: "bbrezillon@kernel.org" <bbrezillon@kernel.org>
Cc: Joao Pinto <Joao.Pinto@synopsys.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"wsa@the-dreams.de" <wsa@the-dreams.de>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	Vitor Soares <Vitor.Soares@synopsys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: RE: [PATCH v3 0/5] Introduce i3c device userspace interface
Date: Wed, 19 Feb 2020 00:39:31 +0000	[thread overview]
Message-ID: <CH2PR12MB421604E9272413A6C456AB16AE100@CH2PR12MB4216.namprd12.prod.outlook.com> (raw)
In-Reply-To: <cover.1582069402.git.vitor.soares@synopsys.com>

Hi Boris,

From: Vitor Soares <vitor.soares@synopsys.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.

Best regards,
Vitor Soares

WARNING: multiple messages have this Message-ID (diff)
From: Vitor Soares <Vitor.Soares@synopsys.com>
To: "bbrezillon@kernel.org" <bbrezillon@kernel.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"wsa@the-dreams.de" <wsa@the-dreams.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Vitor Soares <Vitor.Soares@synopsys.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: RE: [PATCH v3 0/5] Introduce i3c device userspace interface
Date: Wed, 19 Feb 2020 00:39:31 +0000	[thread overview]
Message-ID: <CH2PR12MB421604E9272413A6C456AB16AE100@CH2PR12MB4216.namprd12.prod.outlook.com> (raw)
In-Reply-To: <cover.1582069402.git.vitor.soares@synopsys.com>

Hi Boris,

From: Vitor Soares <vitor.soares@synopsys.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.

Best regards,
Vitor Soares

_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  parent reply	other threads:[~2020-02-19  0:39 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  0:20 [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19  0:20 ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 1/5] i3c: master: export i3c_masterdev_type Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 2/5] i3c: master: export i3c_bus_type symbol Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:20 ` [PATCH v3 3/5] i3c: master: add i3c_for_each_dev helper Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  7:35   ` Greg KH
2020-02-19  7:35     ` Greg KH
2020-02-21 11:47     ` Vitor Soares
2020-02-21 11:47       ` Vitor Soares
2020-02-21 11:52       ` Greg KH
2020-02-21 11:52         ` Greg KH
2020-02-21 12:59         ` Boris Brezillon
2020-02-21 12:59           ` Boris Brezillon
2020-02-21 16:44           ` Boris Brezillon
2020-02-21 16:44             ` Boris Brezillon
2020-02-21 16:45             ` Boris Brezillon
2020-02-21 16:45               ` Boris Brezillon
2020-02-21 17:19             ` Vitor Soares
2020-02-21 17:19               ` Vitor Soares
2020-02-22  8:38             ` Boris Brezillon
2020-02-22  8:38               ` Boris Brezillon
2020-02-19  0:20 ` [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  7:37   ` Greg KH
2020-02-19  7:37     ` Greg KH
2020-02-19  8:45     ` Vitor Soares
2020-02-19  8:45       ` Vitor Soares
2020-02-19  7:39   ` Greg KH
2020-02-19  7:39     ` Greg KH
2020-02-21 11:50     ` Vitor Soares
2020-02-21 11:50       ` Vitor Soares
2020-02-19  8:42   ` Greg KH
2020-02-19  8:42     ` Greg KH
2020-02-21 22:32   ` Boris Brezillon
2020-02-21 22:32     ` Boris Brezillon
2020-02-24 11:04     ` Vitor Soares
2020-02-24 11:04       ` Vitor Soares
2020-02-24 11:22       ` Boris Brezillon
2020-02-24 11:22         ` Boris Brezillon
2020-02-19  0:20 ` [PATCH v3 5/5] add i3cdev documentation Vitor Soares
2020-02-19  0:20   ` Vitor Soares
2020-02-19  0:46   ` Vitor Soares
2020-02-19  0:46     ` Vitor Soares
2020-02-19  4:34   ` Randy Dunlap
2020-02-19  4:34     ` Randy Dunlap
2020-02-21 10:31     ` Vitor Soares
2020-02-21 10:31       ` Vitor Soares
2020-02-21 15:36       ` Randy Dunlap
2020-02-21 15:36         ` Randy Dunlap
2020-02-19  0:39 ` Vitor Soares [this message]
2020-02-19  0:39   ` [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19  8:16   ` Boris Brezillon
2020-02-19  8:16     ` Boris Brezillon
2020-02-21 17:08     ` Vitor Soares
2020-02-21 17:08       ` Vitor Soares
2020-02-21 17:41       ` Boris Brezillon
2020-02-21 17:41         ` Boris Brezillon
2020-02-24 10:53         ` Vitor Soares
2020-02-24 10:53           ` Vitor Soares
2020-02-24 11:24           ` Boris Brezillon
2020-02-24 11:24             ` Boris Brezillon

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=CH2PR12MB421604E9272413A6C456AB16AE100@CH2PR12MB4216.namprd12.prod.outlook.com \
    --to=vitor.soares@synopsys.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=bbrezillon@kernel.org \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --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: link
Be 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.