Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp228047pxp; Wed, 9 Mar 2022 01:29:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJySMhPHhYYJgISJ8mhUC3tftUIoc8Ww+k70XIDRUtkomGIMnAlMEKnImExjs0fcy0uQ25Fs X-Received: by 2002:a17:903:2442:b0:151:e3e2:cbf9 with SMTP id l2-20020a170903244200b00151e3e2cbf9mr16313865pls.115.1646818158797; Wed, 09 Mar 2022 01:29:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646818158; cv=none; d=google.com; s=arc-20160816; b=0PhA1PacS5YJbSvO+LluAf/DKEnrHB+X5o9X6t4Mm4Y6zhGgWG3j0lvR/kA0Q/cJl3 CXOl6ZriQZYDOVYykuKrB0nBUWg10NzqIdr3HSLy6hxmjHe+9kCrC3R2p4wI/u5N3fdx bXpi0lmstWva8LaXBUQmvF1HtuNw3dJQQFLCI1hzlsKh7Lkr535CaOr6s3P0GehEwjtv HKIDNobDFRp12sokfFfazwp0+5dc9uxfw/Y18waasYTFAuAEAtrpweHJ7+IlVs3+40XW /ENJ84YU8deXady1Z0Wd0iwS23NppJ6oHu5bCRnRZtM74U9AkMHfR1H/Rt3ZW6NEzWPP L7VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=USLU2ENzDR4eKdeARgu16GLuYQAPTjUUwfMpQoJt9r0=; b=WUyadOEGXQkJaUlgCYvU690WAUNgmixl2AEefEmpV4l39QUCwZIwpFnsA/W7BDS2UR piaTXbn4j+YS03H3CcgnMyGFfEBet2FQO2MwzNushd/XB4sm91kDRPmfDfd92OPl6ZpP Czn/JoQn9HOsOTUn5sriAajWXjlvIKGi6vBtQf2diz8MMRH6c7jB9d3D8AcOyfJB+L5R EsFv0XaAaCo9Bv+dG0tCYHmA1zbsjHdKdkjLp3Co0qCCs45wNs5GfyrSCZvhiwY44ly1 hINdm5SwkgzBaKokEDPvr3MjPbNfkHi8GJKw038bxA8nIuUWXxRxXNrdDERSEgGS5uYp DMXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e27-20020a631e1b000000b003731bea1d54si1354984pge.490.2022.03.09.01.29.03; Wed, 09 Mar 2022 01:29:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231532AbiCIIxk (ORCPT + 99 others); Wed, 9 Mar 2022 03:53:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231533AbiCIIxi (ORCPT ); Wed, 9 Mar 2022 03:53:38 -0500 Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [IPv6:2a01:4f8:150:2161:1:b009:f23e:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CDC913D1B; Wed, 9 Mar 2022 00:52:38 -0800 (PST) Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 7100A100DECB3; Wed, 9 Mar 2022 09:52:36 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 4F75824ADCC; Wed, 9 Mar 2022 09:52:36 +0100 (CET) Date: Wed, 9 Mar 2022 09:52:36 +0100 From: Lukas Wunner To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: linux-serial , Jiri Slaby , Greg Kroah-Hartman , LKML , Johan Hovold , Andy Shevchenko , Heikki Krogerus , Raymond Tan , Heiko Stuebner , Rob Herring Subject: Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support Message-ID: <20220309085236.GA8259@wunner.de> References: <20220302095606.14818-1-ilpo.jarvinen@linux.intel.com> <20220302095606.14818-2-ilpo.jarvinen@linux.intel.com> <20220306184857.GA19394@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 07, 2022 at 12:54:19PM +0200, Ilpo J?rvinen wrote: > I don't have strong opinion on the actual names myself (every RS-485 > transceivers I've come across name their pins to DE and RE). It's true that transceiver datasheets usually call these pins DE and RE, but on the UART side, by convention the RTS pin is used to drive DE. And RTS is then either asserted/deasserted in software (by the kernel driver), or by the UART hardware if it's capable of it. Hence the properties in Documentation/devicetree/bindings/serial/rs485.yaml and the members in struct serial_rs485 refer to "rts". It's synonymous to DE. I suppose Synopsys wanted to afford the integrator of the IP core as much freedom as possible and therefore offers separate RTS+DE pins as well as an RE pin. But that degree of freedom also leads to confusion, particularly if firmware might mux the pins in an unexpected way behind the OS's back. The RE pin of transceivers is usually either pulled-up (i.e. always asserted, full-duplex) or connected to negated RTS (half-duplex). A lot of transceivers have a !RE pin so RTS can be wired directly to DE and !RE. Full-duplex is primarily for RS-422. If full-duplex is enabled with RS-485, you'll receive your own echo, which is often (but not always) undesirable (depends on the application). For simplicity and consistency, it is best if the existing properties defined in rs485.yaml are used, instead of defining new ones which have the same meaning. For this reason I'd recommend using rs485-rts-active-low for the polarity of the DE pin. > What I think is more important though, is that RE would be by default > active low which matches to about every RS485 transceiver expectations. > Given what device_property_read_bool does when the property is missing, > it would make sense to have the property named as -active-high but I > don't know if that breaks some dt naming rule to have them opposites > of each other like that? That's a good point, I agree. I don't think that would violate any DT naming rule. Thanks, Lukas