From patchwork Thu Mar 17 13:47:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geert Uytterhoeven X-Patchwork-Id: 8611121 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: X-Original-To: patchwork-linux-renesas-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E2A6CC0554 for ; Thu, 17 Mar 2016 13:47:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DEE9F20351 for ; Thu, 17 Mar 2016 13:47:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7DBF420361 for ; Thu, 17 Mar 2016 13:47:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936146AbcCQNrd (ORCPT ); Thu, 17 Mar 2016 09:47:33 -0400 Received: from michel.telenet-ops.be ([195.130.137.88]:49350 "EHLO michel.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936109AbcCQNrb (ORCPT ); Thu, 17 Mar 2016 09:47:31 -0400 Received: from ayla.of.borg ([84.195.106.123]) by michel.telenet-ops.be with bizsmtp id X1nU1s00G2fm56U061nURz; Thu, 17 Mar 2016 14:47:30 +0100 Received: from ramsan.of.borg ([192.168.97.29] helo=ramsan) by ayla.of.borg with esmtp (Exim 4.82) (envelope-from ) id 1agYGu-0001Bo-Dy; Thu, 17 Mar 2016 14:47:28 +0100 Received: from geert by ramsan with local (Exim 4.82) (envelope-from ) id 1agYGx-0003Da-1e; Thu, 17 Mar 2016 14:47:31 +0100 From: Geert Uytterhoeven To: Greg Kroah-Hartman , Jiri Slaby , Peter Hurley , Magnus Damm Cc: Laurent Pinchart , Yoshinori Sato , linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-sh@vger.kernel.org, Geert Uytterhoeven , devicetree@vger.kernel.org Subject: [PATCH/RFC 2/5] serial: sh-sci: Update DT binding documentation for dedicated RTS/CTS Date: Thu, 17 Mar 2016 14:47:26 +0100 Message-Id: <1458222449-12324-3-git-send-email-geert+renesas@glider.be> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1458222449-12324-1-git-send-email-geert+renesas@glider.be> References: <1458222449-12324-1-git-send-email-geert+renesas@glider.be> Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some Renesas SCIF UARTs have dedicated lines for RTS/CTS hardware flow control. Whether these lines exist depends on SoC and UART instance inside the SoC. Whether these lines can be used for hardware flow control depends on board wiring. Amend the DT bindings with an optional property to indicate that RTS/CTS hardware flow control lines exist, and can be used as such. Signed-off-by: Geert Uytterhoeven Cc: devicetree@vger.kernel.org --- This has been mimicked after the "fsl,uart-has-rtscts" and "sirf,uart-has-rtscts" properties. However, as this is fairly generic, perhaps it should just be named "uart-has-rtscts" instead? --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index f8d7b36742967163..8de177c187536c68 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -79,6 +79,11 @@ Optional properties: - {cts,dsr,dcd,rng,rts,dtr,out1,out2}-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's CTS, DSR, DCD, RNG, RTS, DTR, OUT1, or OUT2 line. + - renesas,uart-has-rtscts: The presence of this property indicates that the + UART has dedicated lines for RTS/CTS hardware flow control, and that + they are available for use (wired and enabled by pinmux configuration). + Note that this property is mutually-exclusive with "cts-gpios" and + "rts-gpios" above. Example: aliases {