Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1600416 > unrolled thread

[PATCH 2/2] serdev: Add minimal bus locking API

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] serdev: Add minimal bus locking API Andrey Smirnov <andrew.smirnov@gmail.com> - 2017-03-14 14:50 +0100
    Re: [PATCH 2/2] serdev: Add minimal bus locking API Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-03-15 00:30 +0100
      Re: [PATCH 2/2] serdev: Add minimal bus locking API Andrey Smirnov <andrew.smirnov@gmail.com> - 2017-03-16 15:50 +0100
    Re: [PATCH 2/2] serdev: Add minimal bus locking API Rob Herring <robh@kernel.org> - 2017-03-15 15:30 +0100

#1600416 — [PATCH 2/2] serdev: Add minimal bus locking API

Add minimal bus locking API which is useful for serial devices that
implement request-reply protocol

Cc: cphealy@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 drivers/tty/serdev/core.c |  1 +
 include/linux/serdev.h    | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 759e834..20ca231 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -269,6 +269,7 @@ struct serdev_device *serdev_device_alloc(struct serdev_controller *ctrl)
 	serdev->dev.type = &serdev_device_type;
 	init_completion(&serdev->write_wakeup);
 	mutex_init(&serdev->write_lock);
+	mutex_init(&serdev->bus_lock);
 	return serdev;
 }
 EXPORT_SYMBOL_GPL(serdev_device_alloc);
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 8f7aa35..6b73a79 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -48,6 +48,7 @@ struct serdev_device {
 	const struct serdev_device_ops *ops;
 	struct completion write_wakeup;
 	struct mutex write_lock;
+	struct mutex bus_lock;
 };
 
 static inline struct serdev_device *to_serdev_device(struct device *d)
@@ -55,6 +56,16 @@ static inline struct serdev_device *to_serdev_device(struct device *d)
 	return container_of(d, struct serdev_device, dev);
 }
 
+static inline void serdev_device_bus_lock(struct serdev_device *serdev)
+{
+	mutex_lock(&serdev->bus_lock);
+}
+
+static inline void serdev_device_bus_unlock(struct serdev_device *serdev)
+{
+	mutex_unlock(&serdev->bus_lock);
+}
+
 /**
  * struct serdev_device_driver - serdev slave device driver
  * @driver:	serdev device drivers should initialize name field of this
-- 
2.9.3

[toc] | [next] | [standalone]

#1600953

On Tue, Mar 14, 2017 at 3:48 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Add minimal bus locking API which is useful for serial devices that
> implement request-reply protocol

Can you put an example here?

I'm not sure mutex is needed at all.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1602414

On Tue, Mar 14, 2017 at 4:20 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Mar 14, 2017 at 3:48 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> Add minimal bus locking API which is useful for serial devices that
>> implement request-reply protocol
>
> Can you put an example here?
>
> I'm not sure mutex is needed at all.

My use case is a "supervisory" microcontroller connected to SoC via
UART various aspects of which are exposed via MFD. I saw this kind of
"device design pattern" a number of times in my career, so I thought
and abstraction to help dealing with cases like that might be useful.

However, since Rob mentioned that API's expectation is that any such
locking is driver's responsibility, I'll drop this patch.

Thanks,
Andrey Smirnov

[toc] | [prev] | [next] | [standalone]

#1601441

On Tue, Mar 14, 2017 at 8:48 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Add minimal bus locking API which is useful for serial devices that
> implement request-reply protocol

It's assumed that there's a single client, so I think the client
drivers should manage any locking they need. Maybe that changes if we
have multiple slave devices using RS-485.

Rob

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web