Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
On Thu, 29 Oct 2020 19:45:46 -0700 Hemant Kumar wrote:
> +/* .driver_data stores max mtu */
> +static const struct mhi_device_id mhi_uci_match_table[] = {
> + { .chan = "LOOPBACK", .driver_data = 0x1000},
> + {},
> +};
> +MODULE_DEVICE_TABLE(mhi, mhi_uci_match_table);
I forgot to follow up. If you're adding a testing interface to the
kernel there needs to be an open source test code that makes use of
it. If the code is not large something in
tools/testing/selftests/drivers would be great, but link to an external
project in the documentation is good enough.
Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
hi Hemant,
On Fri, Oct 30, 2020 at 06:26:38PM -0700, Hemant Kumar wrote:
> Hi Mani,
>
> On 10/30/20 3:34 AM, Manivannan Sadhasivam wrote:
> > Hi Hemant,
> >
> > On Thu, Oct 29, 2020 at 07:45:46PM -0700, Hemant Kumar wrote:
> > > This MHI client driver allows userspace clients to transfer
> > > raw data between MHI device and host using standard file operations.
> > > Driver instantiates UCI device object which is associated to device
> > > file node. UCI device object instantiates UCI channel object when device
> > > file node is opened. UCI channel object is used to manage MHI channels
> > > by calling MHI core APIs for read and write operations. MHI channels
> > > are started as part of device open(). MHI channels remain in start
> > > state until last release() is called on UCI device file node. Device
> > > file node is created with format
> > >
> > > /dev/mhi__
> > >
> > > Currently it supports LOOPBACK channel.
> > >
> > > Signed-off-by: Hemant Kumar
> >
> > Thanks for continuously updating the series based on reviews, now the
> > locking
> > part looks a _lot_ cleaner than it used to be. I just have one query
> > (inline)
> > regarding the usage of refcount for uci_chan and uci_dev. Once you fix that,
> > I think this is good to go in.
> Thanks for reviewing my changes.
>
> [..]
>
> > > +#define DEVICE_NAME "mhi"
> > > +#define MHI_UCI_DRIVER_NAME "mhi_uci"
> > > +#define MAX_UCI_MINORS 128
> >
> > Prefix MHI for these.
> Done.
>
> >
> > > +
> > > +static DEFINE_IDR(uci_idr);
> > > +static DEFINE_MUTEX(uci_drv_mutex);
> > > +static struct class *uci_dev_class;
> > > +static int uci_dev_major;
> > > +
> > > +/**
> > > + * struct uci_chan - MHI channel for a UCI device
> > > + * @udev: associated UCI device object
> > > + * @ul_wq: wait queue for writer
> > > + * @write_lock: mutex write lock for ul channel
> > > + * @dl_wq: wait queue for reader
> > > + * @read_lock: mutex read lock for dl channel
> > > + * @dl_pending_lock: spin lock for dl_pending list
> > > + * @dl_pending: list of dl buffers userspace is waiting to read
> > > + * @cur_buf: current buffer userspace is reading
> > > + * @dl_size: size of the current dl buffer userspace is reading
> > > + * @ref_count: uci_chan reference count
> > > + */
> > > +struct uci_chan {
> > > + struct uci_dev *udev;
> > > + wait_queue_head_t ul_wq;
> > > +
> > > + /* ul channel lock to synchronize multiple writes */
> >
> > I asked you to move these comments to Kdoc in previous iteration.
> There are multiple revisions of UCI pushed after i responded on this one. On
> V7 i responded to your comment :)
>
> "This was added because checkpatch --strict required to add a comment when
> lock is added to struct, after adding inline comment, checkpatch error was
> gone."
>
> i was sticking to --strict option. Considering it is best to address what
> --strict is complaining for.
Ah okay.
> >
> > > + struct mutex write_lock;
> > > +
> > > + wait_queue_head_t dl_wq;
> > > +
> > > + /* dl channel lock to synchronize multiple reads */
> > > + struct mutex read_lock;
> > > +
> > > + /*
> > > + * protects pending list in bh context, channel release, read and
> > > + * poll
> > > + */
> > > + spinlock_t dl_pending_lock;
> > > +
> > > + struct list_head dl_pending;
> > > + struct uci_buf *cur_buf;
> > > + size_t dl_size;
> > > + struct kref ref_count;
> >
> > I'm now thinking that instead of having two reference counts for uci_chan
> > and
> > uci_dev, why can't you club them together and just use uci_dev's refcount to
> > handle the channel management also.
> >
> > For instance in uci_open, you are incrementing the refcount for uci_dev
> > before
> > starting the channel and then doing the same for uci_chan in
> > mhi_uci_dev_start_chan(). So why can't you just use a single refcount once
> > the
> > mhi_uci_dev_start_chan() succeeds? The UCI device is useless without a
> > channel,
> > isn't it?
> Main idea is to have the uci driver probed (uci device object is
> instantiated) but it is possible that device node is not opened or if it was
> opened before and release() was called after that. So UCI channel is not
> active but device node would continue to exist. Which can be opened again
> and channel would move to start state. So we dont want to couple mhi driver
> probe with starting of channels. We start channels only when it is really
> needed. This would allow MHI device to go to lower power state when channels
> are disabled.
>
Okay, makes sense! Please make sure you add it in Documentation.
> [..]
>
> > > +
> > > +static int mhi_queue_inbound(struct uci_dev *udev)
> > > +{
> > > + struct mhi_device *mhi_dev = udev->mhi_dev;
> > > + struct device *dev = _dev->dev;
> > > + int nr_trbs, i, ret = -EIO;
> >
> > s/nr_trbs/nr_desc
> Done.
> >
> > > + size_t dl_buf_size;
> > > + void *buf;
> > > + struct uci_buf *ubuf;
> > > +
> > > + /* dont queue if dl channel is not supported */
> > > + if (!udev->mhi_dev->dl_chan)
> > > +
Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
Hi Mani,
On 10/30/20 3:34 AM, Manivannan Sadhasivam wrote:
Hi Hemant,
On Thu, Oct 29, 2020 at 07:45:46PM -0700, Hemant Kumar wrote:
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
Thanks for continuously updating the series based on reviews, now the locking
part looks a _lot_ cleaner than it used to be. I just have one query (inline)
regarding the usage of refcount for uci_chan and uci_dev. Once you fix that,
I think this is good to go in.
Thanks for reviewing my changes.
[..]
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS 128
Prefix MHI for these.
Done.
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
I asked you to move these comments to Kdoc in previous iteration.
There are multiple revisions of UCI pushed after i responded on this
one. On V7 i responded to your comment :)
"This was added because checkpatch --strict required to add a comment
when lock is added to struct, after adding inline comment, checkpatch
error was gone."
i was sticking to --strict option. Considering it is best to address
what --strict is complaining for.
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
I'm now thinking that instead of having two reference counts for uci_chan and
uci_dev, why can't you club them together and just use uci_dev's refcount to
handle the channel management also.
For instance in uci_open, you are incrementing the refcount for uci_dev before
starting the channel and then doing the same for uci_chan in
mhi_uci_dev_start_chan(). So why can't you just use a single refcount once the
mhi_uci_dev_start_chan() succeeds? The UCI device is useless without a channel,
isn't it?
Main idea is to have the uci driver probed (uci device object is
instantiated) but it is possible that device node is not opened or if it
was opened before and release() was called after that. So UCI channel is
not active but device node would continue to exist. Which can be opened
again and channel would move to start state. So we dont want to couple
mhi driver probe with starting of channels. We start channels only when
it is really needed. This would allow MHI device to go to lower power
state when channels are disabled.
[..]
+
+static int mhi_queue_inbound(struct uci_dev *udev)
+{
+ struct mhi_device *mhi_dev = udev->mhi_dev;
+ struct device *dev = _dev->dev;
+ int nr_trbs, i, ret = -EIO;
s/nr_trbs/nr_desc
Done.
+ size_t dl_buf_size;
+ void *buf;
+ struct uci_buf *ubuf;
+
+ /* dont queue if dl channel is not supported */
+ if (!udev->mhi_dev->dl_chan)
+ return 0;
Not returning an error?
Here we dont need to return error because when open is called it would
call this function and if dl_chan is not supported we still want to
return success for a uci device which only supports UL channel.
Keeping this check inside function looks clean so i am not adding this
check in open().
[..]
+static __poll_t mhi_uci_poll(struct file *file, poll_table *wait)
+{
+ struct uci_dev *udev = file->private_data;
+ struct mhi_device *mhi_dev = udev->mhi_dev;
+ struct device *dev = _dev->dev;
+ struct uci_chan *uchan = udev->uchan;
+
Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
Hi Randy, On 10/29/20 10:48 PM, Randy Dunlap wrote: On 10/29/20 7:45 PM, Hemant Kumar wrote: diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig index e841c10..476cc55 100644 --- a/drivers/bus/mhi/Kconfig +++ b/drivers/bus/mhi/Kconfig @@ -20,3 +20,16 @@ config MHI_BUS_DEBUG Enable debugfs support for use with the MHI transport. Allows reading and/or modifying some values within the MHI controller for debug and test purposes. + +config MHI_UCI + tristate "MHI UCI" + depends on MHI_BUS + help + MHI based Userspace Client Interface (UCI) driver is used for MHI-based + transferring raw data between host and device using standard file + operations from userspace. Open, read, write, and close operations + are supported by this driver. Please check mhi_uci_match_table for also poll according to the documentation. good catch, will add in next patch set. + all supported channels that are exposed to userspace. + + To compile this driver as a module, choose M here: the module will be + called mhi_uci. Thanks, Hemant -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
Hi Hemant,
On Thu, Oct 29, 2020 at 07:45:46PM -0700, Hemant Kumar wrote:
> This MHI client driver allows userspace clients to transfer
> raw data between MHI device and host using standard file operations.
> Driver instantiates UCI device object which is associated to device
> file node. UCI device object instantiates UCI channel object when device
> file node is opened. UCI channel object is used to manage MHI channels
> by calling MHI core APIs for read and write operations. MHI channels
> are started as part of device open(). MHI channels remain in start
> state until last release() is called on UCI device file node. Device
> file node is created with format
>
> /dev/mhi__
>
> Currently it supports LOOPBACK channel.
>
> Signed-off-by: Hemant Kumar
Thanks for continuously updating the series based on reviews, now the locking
part looks a _lot_ cleaner than it used to be. I just have one query (inline)
regarding the usage of refcount for uci_chan and uci_dev. Once you fix that,
I think this is good to go in.
Thanks,
Mani
> ---
> drivers/bus/mhi/Kconfig | 13 +
> drivers/bus/mhi/Makefile | 4 +
> drivers/bus/mhi/uci.c| 662
> +++
> 3 files changed, 679 insertions(+)
> create mode 100644 drivers/bus/mhi/uci.c
>
> diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
> index e841c10..476cc55 100644
> --- a/drivers/bus/mhi/Kconfig
> +++ b/drivers/bus/mhi/Kconfig
> @@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
> Enable debugfs support for use with the MHI transport. Allows
> reading and/or modifying some values within the MHI controller
> for debug and test purposes.
> +
> +config MHI_UCI
> + tristate "MHI UCI"
> + depends on MHI_BUS
> + help
> + MHI based Userspace Client Interface (UCI) driver is used for
> + transferring raw data between host and device using standard file
> + operations from userspace. Open, read, write, and close operations
> + are supported by this driver. Please check mhi_uci_match_table for
> + all supported channels that are exposed to userspace.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called mhi_uci.
> diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
> index 19e6443..80feefb 100644
> --- a/drivers/bus/mhi/Makefile
> +++ b/drivers/bus/mhi/Makefile
> @@ -1,2 +1,6 @@
> # core layer
> obj-y += core/
> +
> +# MHI client
> +mhi_uci-y := uci.o
> +obj-$(CONFIG_MHI_UCI) += mhi_uci.o
> diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
> new file mode 100644
> index 000..ea73c08
> --- /dev/null
> +++ b/drivers/bus/mhi/uci.c
> @@ -0,0 +1,662 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEVICE_NAME "mhi"
> +#define MHI_UCI_DRIVER_NAME "mhi_uci"
> +#define MAX_UCI_MINORS 128
Prefix MHI for these.
> +
> +static DEFINE_IDR(uci_idr);
> +static DEFINE_MUTEX(uci_drv_mutex);
> +static struct class *uci_dev_class;
> +static int uci_dev_major;
> +
> +/**
> + * struct uci_chan - MHI channel for a UCI device
> + * @udev: associated UCI device object
> + * @ul_wq: wait queue for writer
> + * @write_lock: mutex write lock for ul channel
> + * @dl_wq: wait queue for reader
> + * @read_lock: mutex read lock for dl channel
> + * @dl_pending_lock: spin lock for dl_pending list
> + * @dl_pending: list of dl buffers userspace is waiting to read
> + * @cur_buf: current buffer userspace is reading
> + * @dl_size: size of the current dl buffer userspace is reading
> + * @ref_count: uci_chan reference count
> + */
> +struct uci_chan {
> + struct uci_dev *udev;
> + wait_queue_head_t ul_wq;
> +
> + /* ul channel lock to synchronize multiple writes */
I asked you to move these comments to Kdoc in previous iteration.
> + struct mutex write_lock;
> +
> + wait_queue_head_t dl_wq;
> +
> + /* dl channel lock to synchronize multiple reads */
> + struct mutex read_lock;
> +
> + /*
> + * protects pending list in bh context, channel release, read and
> + * poll
> + */
> + spinlock_t dl_pending_lock;
> +
> + struct list_head dl_pending;
> + struct uci_buf *cur_buf;
> + size_t dl_size;
> + struct kref ref_count;
I'm now thinking that instead of having two reference counts for uci_chan and
uci_dev, why can't you club them together and just use uci_dev's refcount to
handle the channel management also.
For instance in uci_open, you are incrementing the refcount for uci_dev before
starting the channel and then doing the same for uci_chan in
mhi_uci_dev_start_chan(). So why can't you just use a single refcount once the
mhi_uci_dev_start_chan() succeeds? The UCI device is useless without a channel,
isn't it?
> +};
> +
> +/**
> + * struct uci_buf - UCI buffer
> + * @data: data buffer
> + *
Re: [PATCH v11 4/4] bus: mhi: Add userspace client interface driver
On 10/29/20 7:45 PM, Hemant Kumar wrote: > diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig > index e841c10..476cc55 100644 > --- a/drivers/bus/mhi/Kconfig > +++ b/drivers/bus/mhi/Kconfig > @@ -20,3 +20,16 @@ config MHI_BUS_DEBUG > Enable debugfs support for use with the MHI transport. Allows > reading and/or modifying some values within the MHI controller > for debug and test purposes. > + > +config MHI_UCI > + tristate "MHI UCI" > + depends on MHI_BUS > + help > + MHI based Userspace Client Interface (UCI) driver is used for MHI-based > + transferring raw data between host and device using standard file > + operations from userspace. Open, read, write, and close operations > + are supported by this driver. Please check mhi_uci_match_table for also poll according to the documentation. > + all supported channels that are exposed to userspace. > + > + To compile this driver as a module, choose M here: the module will be > + called mhi_uci. -- ~Randy
[PATCH v11 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 4 +
drivers/bus/mhi/uci.c| 662 +++
3 files changed, 679 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index e841c10..476cc55 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
Enable debugfs support for use with the MHI transport. Allows
reading and/or modifying some values within the MHI controller
for debug and test purposes.
+
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, and close operations
+ are supported by this driver. Please check mhi_uci_match_table for
+ all supported channels that are exposed to userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..80feefb 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,6 @@
# core layer
obj-y += core/
+
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..ea73c08
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+ mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+
