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


Groups > linux.kernel > #1632816 > unrolled thread

[PATCH] serdev: Restore serdev_device_write_buf for atomic context

Started byStefan Wahren <stefan.wahren@i2se.com>
First post2017-04-28 13:50 +0200
Last post2017-05-08 17:20 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] serdev: Restore serdev_device_write_buf for atomic context Stefan Wahren <stefan.wahren@i2se.com> - 2017-04-28 13:50 +0200
    Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic  context Johan Hovold <johan@kernel.org> - 2017-05-02 11:10 +0200
      Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context Rob Herring <robh@kernel.org> - 2017-05-02 14:50 +0200
        Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic  context Johan Hovold <johan@kernel.org> - 2017-05-02 15:20 +0200
          Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic  context Stefan Wahren <stefan.wahren@i2se.com> - 2017-05-04 18:30 +0200
            Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context Rob Herring <robh@kernel.org> - 2017-05-04 22:40 +0200
              Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic  context Johan Hovold <johan@kernel.org> - 2017-05-08 17:20 +0200

#1632816 — [PATCH] serdev: Restore serdev_device_write_buf for atomic context

FromStefan Wahren <stefan.wahren@i2se.com>
Date2017-04-28 13:50 +0200
Subject[PATCH] serdev: Restore serdev_device_write_buf for atomic context
Message-ID<tBczo-6JZ-21@gated-at.bofh.it>
Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
subroutine") the function serdev_device_write_buf cannot be used in
atomic context anymore (mutex_lock is sleeping). So restore the old
behavior.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: 6fe729c4bdae ("serdev: Add serdev_device_write subroutine")
---
 drivers/tty/serdev/core.c | 12 ++++++++++++
 include/linux/serdev.h    | 14 +++++++-------
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 433de5e..f71b473 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -122,6 +122,18 @@ void serdev_device_write_wakeup(struct serdev_device *serdev)
 }
 EXPORT_SYMBOL_GPL(serdev_device_write_wakeup);
 
+int serdev_device_write_buf(struct serdev_device *serdev,
+			    const unsigned char *buf, size_t count)
+{
+	struct serdev_controller *ctrl = serdev->ctrl;
+
+	if (!ctrl || !ctrl->ops->write_buf)
+		return -EINVAL;
+
+	return ctrl->ops->write_buf(ctrl, buf, count);
+}
+EXPORT_SYMBOL_GPL(serdev_device_write_buf);
+
 int serdev_device_write(struct serdev_device *serdev,
 			const unsigned char *buf, size_t count,
 			unsigned long timeout)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index cda76c6..e2a225b 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -195,6 +195,7 @@ int serdev_device_open(struct serdev_device *);
 void serdev_device_close(struct serdev_device *);
 unsigned int serdev_device_set_baudrate(struct serdev_device *, unsigned int);
 void serdev_device_set_flow_control(struct serdev_device *, bool);
+int serdev_device_write_buf(struct serdev_device *, const unsigned char *, size_t);
 void serdev_device_wait_until_sent(struct serdev_device *, long);
 int serdev_device_get_tiocm(struct serdev_device *);
 int serdev_device_set_tiocm(struct serdev_device *, int, int);
@@ -236,6 +237,12 @@ static inline unsigned int serdev_device_set_baudrate(struct serdev_device *sdev
 	return 0;
 }
 static inline void serdev_device_set_flow_control(struct serdev_device *sdev, bool enable) {}
+static inline int serdev_device_write_buf(struct serdev_device *serdev,
+					  const unsigned char *buf,
+					  size_t count)
+{
+	return -ENODEV;
+}
 static inline void serdev_device_wait_until_sent(struct serdev_device *sdev, long timeout) {}
 static inline int serdev_device_get_tiocm(struct serdev_device *serdev)
 {
@@ -312,11 +319,4 @@ static inline struct device *serdev_tty_port_register(struct tty_port *port,
 static inline void serdev_tty_port_unregister(struct tty_port *port) {}
 #endif /* CONFIG_SERIAL_DEV_CTRL_TTYPORT */
 
-static inline int serdev_device_write_buf(struct serdev_device *serdev,
-					  const unsigned char *data,
-					  size_t count)
-{
-	return serdev_device_write(serdev, data, count, 0);
-}
-
 #endif /*_LINUX_SERDEV_H */
-- 
2.1.4

[toc] | [next] | [standalone]


#1634270 — Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context

FromJohan Hovold <johan@kernel.org>
Date2017-05-02 11:10 +0200
SubjectRe: [PATCH] serdev: Restore serdev_device_write_buf for atomic context
Message-ID<tCBYJ-4BJ-3@gated-at.bofh.it>
In reply to#1632816
On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
> subroutine") the function serdev_device_write_buf cannot be used in
> atomic context anymore (mutex_lock is sleeping). So restore the old
> behavior.

Yeah, preventing use in atomic context seems unnecessary, although any
clients writing must now deal with serialisation themselves (as before,
and as they should).

Calling wait_for_completion in the non-blocking case was also needlessly
inefficient.

> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Fixes: 6fe729c4bdae ("serdev: Add serdev_device_write subroutine")

Reviewed-by: Johan Hovold <johan@kernel.org>

Thanks,
Johan

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


#1634384

FromRob Herring <robh@kernel.org>
Date2017-05-02 14:50 +0200
Message-ID<tCFpD-6LL-3@gated-at.bofh.it>
In reply to#1634270
On Tue, May 2, 2017 at 4:06 AM, Johan Hovold <johan@kernel.org> wrote:
> On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
>> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
>> subroutine") the function serdev_device_write_buf cannot be used in
>> atomic context anymore (mutex_lock is sleeping). So restore the old
>> behavior.
>
> Yeah, preventing use in atomic context seems unnecessary, although any
> clients writing must now deal with serialisation themselves (as before,
> and as they should).

We could just remove the mutex for serdev_device_write and always make
the client responsible for serialization.

> Calling wait_for_completion in the non-blocking case was also needlessly
> inefficient.

It won't be called because count should be 0.

Rob

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


#1634405 — Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context

FromJohan Hovold <johan@kernel.org>
Date2017-05-02 15:20 +0200
SubjectRe: [PATCH] serdev: Restore serdev_device_write_buf for atomic context
Message-ID<tCFSG-7ab-9@gated-at.bofh.it>
In reply to#1634384
On Tue, May 02, 2017 at 07:41:34AM -0500, Rob Herring wrote:
> On Tue, May 2, 2017 at 4:06 AM, Johan Hovold <johan@kernel.org> wrote:
> > On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
> >> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
> >> subroutine") the function serdev_device_write_buf cannot be used in
> >> atomic context anymore (mutex_lock is sleeping). So restore the old
> >> behavior.
> >
> > Yeah, preventing use in atomic context seems unnecessary, although any
> > clients writing must now deal with serialisation themselves (as before,
> > and as they should).
> 
> We could just remove the mutex for serdev_device_write and always make
> the client responsible for serialization.

That sounds reasonable.

> > Calling wait_for_completion in the non-blocking case was also needlessly
> > inefficient.
> 
> It won't be called because count should be 0.

That's not guaranteed; count would be nonzero whenever the tty
driver does not accept the full buffer and then we'd currently end up
calling wait_for_completion_timeout() with a zero-timeout instead of
just returning immediately.

Johan

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


#1635879 — Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context

FromStefan Wahren <stefan.wahren@i2se.com>
Date2017-05-04 18:30 +0200
SubjectRe: [PATCH] serdev: Restore serdev_device_write_buf for atomic context
Message-ID<tDrNE-60m-17@gated-at.bofh.it>
In reply to#1634405
Am 02.05.2017 um 15:18 schrieb Johan Hovold:
> On Tue, May 02, 2017 at 07:41:34AM -0500, Rob Herring wrote:
>> On Tue, May 2, 2017 at 4:06 AM, Johan Hovold <johan@kernel.org> wrote:
>>> On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
>>>> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
>>>> subroutine") the function serdev_device_write_buf cannot be used in
>>>> atomic context anymore (mutex_lock is sleeping). So restore the old
>>>> behavior.
>>> Yeah, preventing use in atomic context seems unnecessary, although any
>>> clients writing must now deal with serialisation themselves (as before,
>>> and as they should).
>> We could just remove the mutex for serdev_device_write and always make
>> the client responsible for serialization.
> That sounds reasonable.

So it's unwanted to have 2 write functions (non-atomic, atomic)?

Stefan

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


#1636033

FromRob Herring <robh@kernel.org>
Date2017-05-04 22:40 +0200
Message-ID<tDvHA-8tt-41@gated-at.bofh.it>
In reply to#1635879
On Thu, May 4, 2017 at 11:22 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Am 02.05.2017 um 15:18 schrieb Johan Hovold:
>> On Tue, May 02, 2017 at 07:41:34AM -0500, Rob Herring wrote:
>>> On Tue, May 2, 2017 at 4:06 AM, Johan Hovold <johan@kernel.org> wrote:
>>>> On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
>>>>> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
>>>>> subroutine") the function serdev_device_write_buf cannot be used in
>>>>> atomic context anymore (mutex_lock is sleeping). So restore the old
>>>>> behavior.
>>>> Yeah, preventing use in atomic context seems unnecessary, although any
>>>> clients writing must now deal with serialisation themselves (as before,
>>>> and as they should).
>>> We could just remove the mutex for serdev_device_write and always make
>>> the client responsible for serialization.
>> That sounds reasonable.
>
> So it's unwanted to have 2 write functions (non-atomic, atomic)?

No, it's unwanted to have more than we need.

Looking closer, we'd also have to ensure the wait for completion is
not called also. So probably better to just leave it as you have done
it.

Acked-by: Rob Herring <robh@kernel.org>

Rob

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


#1637497 — Re: [PATCH] serdev: Restore serdev_device_write_buf for atomic context

FromJohan Hovold <johan@kernel.org>
Date2017-05-08 17:20 +0200
SubjectRe: [PATCH] serdev: Restore serdev_device_write_buf for atomic context
Message-ID<tESC5-5Ad-9@gated-at.bofh.it>
In reply to#1636033
On Thu, May 04, 2017 at 03:32:53PM -0500, Rob Herring wrote:
> On Thu, May 4, 2017 at 11:22 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > Am 02.05.2017 um 15:18 schrieb Johan Hovold:
> >> On Tue, May 02, 2017 at 07:41:34AM -0500, Rob Herring wrote:
> >>> On Tue, May 2, 2017 at 4:06 AM, Johan Hovold <johan@kernel.org> wrote:
> >>>> On Fri, Apr 28, 2017 at 01:47:21PM +0200, Stefan Wahren wrote:
> >>>>> Starting with commit 6fe729c4bdae ("serdev: Add serdev_device_write
> >>>>> subroutine") the function serdev_device_write_buf cannot be used in
> >>>>> atomic context anymore (mutex_lock is sleeping). So restore the old
> >>>>> behavior.
> >>>> Yeah, preventing use in atomic context seems unnecessary, although any
> >>>> clients writing must now deal with serialisation themselves (as before,
> >>>> and as they should).
> >>> We could just remove the mutex for serdev_device_write and always make
> >>> the client responsible for serialization.
> >> That sounds reasonable.
> >
> > So it's unwanted to have 2 write functions (non-atomic, atomic)?
> 
> No, it's unwanted to have more than we need.
> 
> Looking closer, we'd also have to ensure the wait for completion is
> not called also. So probably better to just leave it as you have done
> it.

Indeed. Sorry if my reply above was unclear on that point (i.e. that
Stefan's patch is still needed regardless of whether we keep the mutex
or not).

Thanks,
Johan

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web