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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2ECE0C433F5 for ; Tue, 26 Apr 2022 14:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351451AbiDZONm (ORCPT ); Tue, 26 Apr 2022 10:13:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351452AbiDZONj (ORCPT ); Tue, 26 Apr 2022 10:13:39 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 291196256; Tue, 26 Apr 2022 07:10:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B025D61760; Tue, 26 Apr 2022 14:10:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8E92C385AA; Tue, 26 Apr 2022 14:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650982231; bh=ZPeje/e98HoyDemHXaKoIfAh2yfEIqi6kqltvCUz+ww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=crfo0u+PB5SA5RNj0pQLJWatVk5+qE7b+uBd61uRcRaJxczzYs9rk/aVzPXrKyYwc griwOklNbGPxwfqD9bWrszcneMdtK+CgXXW2ayV/CSuFqtcqOY4sb8e6wUBk3O37MM NeZ4qAp8hltXLoSrkQ0y3zsY+oM+cY/t8FoJi6YM= Date: Tue, 26 Apr 2022 16:10:26 +0200 From: Greg KH To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: linux-serial , Jiri Slaby , Lukas Wunner , Andy Shevchenko , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Vicente Bergas , Johan Hovold , heiko@sntech.de, giulio.benetti@micronovasrl.com, Heikki Krogerus , linux-api@vger.kernel.org, Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E.J. Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , sparclinux@vger.kernel.org, Arnd Bergmann , linux-arch@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v5 05/10] serial: termbits: ADDRB to indicate 9th bit addressing mode Message-ID: References: <20220426122448.38997-1-ilpo.jarvinen@linux.intel.com> <20220426122448.38997-6-ilpo.jarvinen@linux.intel.com> <17547658-4737-7ec1-9ef9-c61c6287b8b@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17547658-4737-7ec1-9ef9-c61c6287b8b@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Tue, Apr 26, 2022 at 05:01:31PM +0300, Ilpo Järvinen wrote: > 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? Argh, yes, please, let's do that now, I totally missed that. Will let us see how to unify them as well. thanks, greg k-h