On Thu, Mar 16, 2017 at 8:33 AM, Andrey Smirnov <andrew.smirnov@xxxxxxxxx> wrote: > On Wed, Mar 15, 2017 at 7:18 AM, Rob Herring <robh@xxxxxxxxxx> wrote: >> On Tue, Mar 14, 2017 at 8:48 AM, Andrey Smirnov >> <andrew.smirnov@xxxxxxxxx> wrote: >>> Add serdev_device_write() which is a blocking call allowing to transfer >>> arbitraty amount of data (potentially exceeding amount that >>> serdev_device_write_buf can process in a single call) >>> >>> Cc: cphealy@xxxxxxxxx >>> Cc: Guenter Roeck <linux@xxxxxxxxxxxx> >>> Cc: linux-serial@xxxxxxxxxxxxxxx >>> Cc: linux-kernel@xxxxxxxxxxxxxxx >>> Signed-off-by: Andrey Smirnov <andrew.smirnov@xxxxxxxxx> >>> --- >>> drivers/tty/serdev/core.c | 37 +++++++++++++++++++++++++++++++++++++ >>> include/linux/serdev.h | 23 +++++++++++++++++------ >>> 2 files changed, 54 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c >>> index f4c6c90..759e834 100644 >>> --- a/drivers/tty/serdev/core.c >>> +++ b/drivers/tty/serdev/core.c >>> @@ -128,6 +128,41 @@ int serdev_device_write_buf(struct serdev_device *serdev, >>> } >>> EXPORT_SYMBOL_GPL(serdev_device_write_buf); >>> >>> +int serdev_device_write(struct serdev_device *serdev, >>> + const unsigned char *buf, size_t count) >> >> _write vs. _write_buf are not all that clear what the difference is. >> but I don't have a better name. >> > > serdev_device_send? send vs. write_buf? Still not that clear. >> Perhaps a timeout param is needed? This could never complete if CTS >> remains deasserted. > > Yeah, I think it is a good idea, I'll add that in v2. Maybe just combine the 2 functions and a timeout of 0 follows the original behavior of serdev_device_write_buf. I'm not sure if we could handle write_wakeup in that case though. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
