Thread (35 messages) 35 messages, 5 authors, 2017-03-18

Re: [PATCH 08/10] serdev: add serdev_device_get_cts

From: Rob Herring <robh+dt@kernel.org>
Date: 2017-03-08 15:14:24
Also in: linux-bluetooth, linux-serial, lkml

On Tue, Mar 7, 2017 at 3:12 PM, Sebastian Reichel [off-list ref] wrote:
Hi Rob,

On Tue, Mar 07, 2017 at 10:03:37AM -0600, Rob Herring wrote:
quoted
On Sat, Mar 4, 2017 at 5:58 AM, Sebastian Reichel [off-list ref] wrote:
quoted
Add method to get current CTS line state.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
 drivers/tty/serdev/core.c           | 11 +++++++++++
 drivers/tty/serdev/serdev-ttyport.c | 15 +++++++++++++++
 include/linux/serdev.h              |  6 ++++++
 3 files changed, 32 insertions(+)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index a63b74031e22..36eb3dfb1477 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -184,6 +184,17 @@ void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
 }
 EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);

+bool serdev_device_get_cts(struct serdev_device *serdev)
I wonder if this should just be the wait for cts in the core. I think
that would be the common use for reading the CTS state. IIRC, I saw
some other device needing the same thing.
mh. I think it fits nicely to serdev_device_set_rts(). But I guess
it makes sense to have the wait feature directly in serdev. So I
suggest to add the function in addition to the simple get_cts
function. Does that make sense to you?
Sure. You should be able to implement that just in the core. Then the
host driver stays simple and we're not duplicating the wait in host
drivers (not that we expect to have lots of host drivers).

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help