From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E428C433EF for ; Tue, 26 Apr 2022 14:04:34 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KnkCP2GlZz3bqJ for ; Wed, 27 Apr 2022 00:04:33 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Q6ggUSdB; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=ilpo.jarvinen@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Q6ggUSdB; dkim-atps=neutral Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KnkBg3jZyz2yNv for ; Wed, 27 Apr 2022 00:03:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650981835; x=1682517835; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=muy4OIGsUfuoU+ynYUj8788CzK12+NiFyJaROrENCgM=; b=Q6ggUSdBsaLnUCenchQxlsBYhw532Uu93BZYfUpYXST5OAHphfHoPuXo Gvca3Y0Nwt3edfLU+kF1dCMZUi05yORHeZTv7eq6BurmFq/G6QFpMp/yc SKwoKLoQcwp5QA+lIPvtVuzpHArB+fYfR/PghIXvjgQmBbEk53tv0NNDE IoOgOrjwVuf5Q0FBZJB0JmS1JUWqJ8ffL7KE4rn92p4Qtkd8ypqI1vFIO JaKkQfyOGpeYuBjHFzXg4iTzIMu1lByMRiAQhLAHlNOdOQNlzxxPejIaJ yrODhfWbm0R6+BLh76GTzutFhD5YE8IimnC2hLz2gb31iLG6KL0w337Zk w==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="246147770" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="246147770" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 07:01:41 -0700 X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="579908538" Received: from mmilkovx-mobl.amr.corp.intel.com ([10.249.47.245]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 07:01:33 -0700 Date: Tue, 26 Apr 2022 17:01:31 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= Subject: Re: [PATCH v5 05/10] serial: termbits: ADDRB to indicate 9th bit addressing mode In-Reply-To: Message-ID: <17547658-4737-7ec1-9ef9-c61c6287b8b@linux.intel.com> References: <20220426122448.38997-1-ilpo.jarvinen@linux.intel.com> <20220426122448.38997-6-ilpo.jarvinen@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-479992224-1650981548=:1644" Content-ID: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heikki Krogerus , heiko@sntech.de, "James E.J. Bottomley" , Paul Mackerras , sparclinux@vger.kernel.org, linux-api@vger.kernel.org, Jiri Slaby , linux-arch@vger.kernel.org, Helge Deller , linux-serial , =?ISO-8859-15?Q?Uwe_Kleine-K=F6nig?= , Matt Turner , Arnd Bergmann , Johan Hovold , Vicente Bergas , Ivan Kokshaysky , Andy Shevchenko , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, Greg KH , linux-usb@vger.kernel.org, linux-mips@vger.kernel.org, "David S. Miller" , Lukas Wunner , linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, giulio.benetti@micronovasrl.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-479992224-1650981548=:1644 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: <16767992-12e-3b16-2fdb-9ced864fa36e@linux.intel.com> One additional thing below I missed on the first read. On Tue, 26 Apr 2022, Ilpo Järvinen wrote: > On Tue, 26 Apr 2022, Greg KH wrote: > > > On Tue, Apr 26, 2022 at 03:24:43PM +0300, Ilpo Järvinen wrote: > > > Add ADDRB to termbits to indicate 9th bit addressing mode. This change > > > is necessary for supporting devices with RS485 multipoint addressing > > > [*]. A later patch in the patch series adds support for Synopsys > > > Designware UART capable for 9th bit addressing mode. In this mode, 9th > > > bit is used to indicate an address (byte) within the communication > > > line. The 9th bit addressing mode is selected using ADDRB introduced by > > > an earlier patch. > > > > > > [*] Technically, RS485 is just an electronic spec and does not itself > > > specify the 9th bit addressing mode but 9th bit seems at least > > > "semi-standard" way to do addressing with RS485. > > > > > > Cc: linux-api@vger.kernel.org > > > Cc: Ivan Kokshaysky > > > Cc: Matt Turner > > > Cc: linux-alpha@vger.kernel.org > > > Cc: Thomas Bogendoerfer > > > Cc: linux-mips@vger.kernel.org > > > Cc: "James E.J. Bottomley" > > > Cc: Helge Deller > > > Cc: linux-parisc@vger.kernel.org > > > Cc: Michael Ellerman > > > Cc: Benjamin Herrenschmidt > > > Cc: Paul Mackerras > > > Cc: linuxppc-dev@lists.ozlabs.org > > > Cc: "David S. Miller" > > > Cc: sparclinux@vger.kernel.org > > > Cc: Arnd Bergmann > > > Cc: linux-arch@vger.kernel.org > > > Cc: linux-usb@vger.kernel.org > > > Signed-off-by: Ilpo Järvinen > > > --- > > > #define CMSPAR 010000000000 /* mark or space (stick) parity */ > > > #define CRTSCTS 020000000000 /* flow control */ > > > > > > diff --git a/arch/powerpc/include/uapi/asm/termbits.h b/arch/powerpc/include/uapi/asm/termbits.h > > > index ed18bc61f63d..c6a033732f39 100644 > > > --- a/arch/powerpc/include/uapi/asm/termbits.h > > > +++ b/arch/powerpc/include/uapi/asm/termbits.h > > > @@ -171,6 +171,7 @@ struct ktermios { > > > #define HUPCL 00040000 > > > > > > #define CLOCAL 00100000 > > > +#define ADDRB 004000000000 /* address bit */ > > > #define CMSPAR 010000000000 /* mark or space (stick) parity */ > > > #define CRTSCTS 020000000000 /* flow control */ > > > > > > diff --git a/arch/sparc/include/uapi/asm/termbits.h b/arch/sparc/include/uapi/asm/termbits.h > > > index ce5ad5d0f105..5eb1d547b5c4 100644 > > > --- a/arch/sparc/include/uapi/asm/termbits.h > > > +++ b/arch/sparc/include/uapi/asm/termbits.h > > > @@ -201,6 +201,7 @@ struct ktermios { > > > #define B3500000 0x00001012 > > > #define B4000000 0x00001013 */ > > > #define CIBAUD 0x100f0000 /* input baud rate (not used) */ > > > +#define ADDRB 0x20000000 /* address bit */ > > > #define CMSPAR 0x40000000 /* mark or space (stick) parity */ > > > #define CRTSCTS 0x80000000 /* flow control */ > > > > Why all the different values? Can't we pick one and use it for all > > arches? Having these be different in different arches and userspace > > should not be a thing for new fields, right? ADDRB value is the same for all archs (it's just this octal vs hex notation I've followed as per the nearby defines within the same file which makes them look different). Should I perhaps add to my cleanup list conversion of all those octal ones to hex? > > > diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c > > > index 78baba55a8b5..d179b9b57a25 100644 > > > --- a/drivers/char/pcmcia/synclink_cs.c > > > +++ b/drivers/char/pcmcia/synclink_cs.c > > > @@ -2287,6 +2287,8 @@ static void mgslpc_set_termios(struct tty_struct *tty, struct ktermios *old_term > > > == RELEVANT_IFLAG(old_termios->c_iflag))) > > > return; > > > > > > + tty->termios.c_cflag &= ~ADDRB; > > > > Having to do this for all drivers feels wrong. It isn't needed for any > > other flag, right? > > My understanding is that it would be needed for other flags too, it's just > that many drivers probably haven't cared enough. Some drivers certainly > clear a few flags they don't support while others don't clear any but > it's also challenging to determine it which flags which driver supports. > How bad the impact is per flag varies. > > > That makes me really not like this change as it > > feels very ackward and > > yet-another-thing-a-serial-driver-has-to-remember. > > It would be nice to have some mask for supported bits per driver. But it > will be challenging to add at this point and I'm far from sure I could get > them right per driver even if carefully trying to. > > > And as you are wanting to pass this bit to userspace, where is that > > documented? > > Ah, I probably should add it to driver-api/serial/driver.rst too but ADDRB > is certainly mentioned alongside with other addressing mode documentation > I wrote for the later changes in this series. -- i. --8323329-479992224-1650981548=:1644--