Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp9640389rwp; Thu, 20 Jul 2023 07:46:42 -0700 (PDT) X-Google-Smtp-Source: APBJJlEHGnb4tVptvuNVTJQiqy/kOvmjlxefhgoHOQp0I+ey0b2JH4pQZFlbR64qFyMnU5PN7pij X-Received: by 2002:a05:6a20:428b:b0:132:9783:452e with SMTP id o11-20020a056a20428b00b001329783452emr8032476pzj.12.1689864402655; Thu, 20 Jul 2023 07:46:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689864402; cv=none; d=google.com; s=arc-20160816; b=ubABszGjOZJZOehEQKQ6gP1Y2UdrwDCZ6bbboAWQ/GuaYot7wLG1gRdnHrJL35wGNV OPmMHdmo2QHH57I/+Yi0MfogbxVarcCMiJcbP46Go4ws0SwmCwncDL4NXu7dK2VBPgkV syrPQvsOszTAyG4qJewvuhcbkLQicjoKwONTTwapZCz4rVgS7C7v3hmgNShuT+WAV1NN KM+cLLLv33yk5xQBkJ/Cma9E3ST4JFO7ENigmWX4xSQpptvnttCW5221fw51rJuX5RW7 4oi24f8JvS1+VAvRR7hwhfyPRsak0SNDh0DktM09V3lo7XPFjrKCDgc/LI8HRILliAHA Q5+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=hisc4XQYILakBDoDtV+vVjO/p+vLqhmLL15u4n/SN7Q=; fh=Gjjx0WBt6GlsVECr6l5IdZoubnahyYC4rhBY7lBbLsk=; b=NvtyNIErZyXIYNOsyTT+hLEbN9e4CgZFx+H5jyAenVbu2iJyrXTHQG6q8xvZ+pPc+t 6uAvDm+8a8HjOiklif3V4P87rNPtTd699dpEZ+xujrm40XdXmSPtUqPNfmF+UQfyeN0y SgLRj5+F1X7DdWa+Hlb7aPw6RDn5I7/SG/leX9aA56aZYBxRELhq120yen2bfh+27vB0 SyORK/6ebGQJXD1NmetlYsrpw3kAWN68w8cwu2GIkt7qrc9xhgQFrckKY2N4WG0GsrDi J+1wqXK7tgpWIBDCitopIeEEbvfhwA5tD/FYlDHexmw7+LEwmhDK4kZ+BuCz8n050wSZ kRAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=boFfscIY; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l185-20020a6391c2000000b0053f2551834esi998549pge.735.2023.07.20.07.46.30; Thu, 20 Jul 2023 07:46:42 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=boFfscIY; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231167AbjGTNqB (ORCPT + 99 others); Thu, 20 Jul 2023 09:46:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230134AbjGTNp7 (ORCPT ); Thu, 20 Jul 2023 09:45:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BCCE1986; Thu, 20 Jul 2023 06:45:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ADB9A61AF3; Thu, 20 Jul 2023 13:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE895C433C8; Thu, 20 Jul 2023 13:45:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689860757; bh=MVVckKfWdb/UFwbNUW/fQU3gPnX5foBXQJh6KT8HQ+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=boFfscIY8umJ/s7h4gFQo5CTmHGrgpus1lA0CIwGCqiXJEdfJZ7xqXm/BciUYsfei Bp5R3aIPsCW0LzfkWu/GWbVaICvCG6Bhghqkh4PIUZDQ5qwYvzgqzldEGoQF6g+cp1 EB+t94GHkAZGQTucE5y1mL1/54YAY0i5+RLcxAphNv+xRGZ5G3Cte8xLSHtsNpJXXK PwiY9ELH8r1+2UJs3Rcb/CEtH/R1Um6bxmWLG4iqnMHW7KB3VaMT3N5/LtqGhL7m5a 7vHXJqpIjNQMnvjo4Nx1lxq1PaVMo8WT9Su9BJmVNxTuVZnRpaN2/Ve9//957kdC7X s574fvJaTCvwQ== Received: from johan by xi.lan with local (Exim 4.96) (envelope-from ) id 1qMTyo-00076j-07; Thu, 20 Jul 2023 15:46:06 +0200 Date: Thu, 20 Jul 2023 15:46:06 +0200 From: Johan Hovold To: Jarkko Sonninen Cc: Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] USB: serial: xr: Add TIOCGRS485 and TIOCSRS485 ioctls Message-ID: References: <20230423185929.1595056-1-kasper@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,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 Thu, Jul 06, 2023 at 10:37:51PM +0300, Jarkko Sonninen wrote: > On 6/20/23 15:38, Johan Hovold wrote: > Thank you. Sorry for slow responses. My mind has been elsewhere. No worries at all. > > On Sun, Apr 23, 2023 at 09:59:28PM +0300, Jarkko Sonninen wrote: > >> User enables RS-485 mode by setting SER_RS485_ENABLED flag in > >> struct serial_rs485 flags. User should also set either > >> SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND to select the > >> behaviour of the RTS#/RS485 pin. Setting SER_RS485_RTS_ON_SEND > >> will drive RTS#/RS485 high during transmission. As this is the > >> typical application described by Exar, it is selected when > >> user sets neither or both flags. > > Since RTS# is active low, shouldn't SER_RS485_RTS_ON_SEND drive RTS# low > > rather than high during transmission as I also pointed out earlier? > > I guess you are right. I'll change that. > > > I use an exar usb adapter to control a solar charging controller. I > haven't found any other type of exar adapters in ebay. > > This adapter uses high level (RTS off) on TX. So I really would like it > to work with the default configuration. > > I hope it is ok to use SER_RS485_RTS_AFTER_SEND as the default I was first going to argue against with this as serial core defaults to SER_RS485_RTS_ON_SEND when neither is set, but I changed my mind as I believe this is more in line with how these flags were intended to be used. Having both flags set to the same value clearly makes no sense, but if left that way I think SER_RS485_RTS_ON_SEND should take precedence and SER_RS485_RTS_AFTER_SEND simply be set not its negation (when the hardware does not support the nonsensical RTS always asserted combination...). That is: /* RTS always toggles after TX */ if (rs485->flags & SER_RS485_RTS_ON_SEND) rs485->flags &= ~SER_RS485_RTS_AFTER_SEND; else rs485->flags |= SER_RS485_RTS_AFTER_SEND; Since you still need to use the new ioctl() to enable RS485 mode, there shouldn't really be any reason not to simultaneously set the polarity your application expects anyway. Johan