Message ID | 20230920201035.3445-2-wsa+renesas@sang-engineering.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp4490699vqi; Wed, 20 Sep 2023 16:23:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEDYUzvGSQr7Pqxl8dKEMZKbj5INIHIeYe1UIHbXqP6JzaMr2SGhw8DZrfDTD9xmnL6ZTbR X-Received: by 2002:a05:6a20:1615:b0:134:73f6:5832 with SMTP id l21-20020a056a20161500b0013473f65832mr6169217pzj.16.1695252194319; Wed, 20 Sep 2023 16:23:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695252194; cv=none; d=google.com; s=arc-20160816; b=Nsrv/0jdCp9eVhDgWDTxcAXFMB9VesoHK2wvg3PLQFJDLiS6lEPPQCHUCAPeDSnLYp nRJOSrB0kzaS+IGG97wullFh/nl2ezksO/8H05MK328nlP1B0VsRI2M3fzh1a+hada4m jWxICkDba/8fd8vVsujwQpkQq4VljufWQ0woTdFK+6c+H5lXDbk3hLCP3cvVuUDQ/4fI g9FtTf0l3hLSiR+q9GTKhlfmQiiZWYXtadR90d1TzmNbgryHNlKajHZs+9hDAanZf2zg TJ7aO4Za6owng/B2uarhSUBef9kEC/DkQLc5uNfCeChlW1R+uBUNrkCoRMT+iUVxZX46 3xxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ZNeKrg5sAP30QqDQrIU7hgAIKaGsVVJXPQC5z91sR2k=; fh=j9MxXrCTMgACpdaMc27ckDET3IHjrMQRkUYnsFGSjwg=; b=o2Bm5wlkQ1pl/nel9gv9vbZ3/8t/9Slk0WxdnmB46fkGtwVwaimQSmfMub5tgeghrz nw/zfAJ8rsRFFyznz9+E9e1BR0OwOEepLyfiv+lUbize7yvF9WQ34yf3K3xrRTG9dmBu 33lvu0HApoTW+mVM8CoIf6AXsMykmBLzdSsOi0RHiYk43/AIf8buQkb0FDmp6zgdTK6u jKMU9YVER1NX4Q9dvWrDKorrhAIvwvj4q/jpG1RY16RENVr2EaUT0047mzmBKIM+4Owm ljrjgDcN90wJVjQ4shfAEDeHB9z3uHH/KViLA6TtYwIjtCLG39TDssjvAnPFK/ryaa7B nNAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sang-engineering.com header.s=k1 header.b=erc3tIF7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id az1-20020a056a02004100b00577461b010fsi102214pgb.685.2023.09.20.16.23.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 16:23:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@sang-engineering.com header.s=k1 header.b=erc3tIF7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 79AC98057E5F; Wed, 20 Sep 2023 13:11:01 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229692AbjITUKy (ORCPT <rfc822;realc9580@gmail.com> + 27 others); Wed, 20 Sep 2023 16:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229651AbjITUKw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 20 Sep 2023 16:10:52 -0400 Received: from mail.zeus03.de (www.zeus03.de [194.117.254.33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AEB73C9 for <linux-kernel@vger.kernel.org>; Wed, 20 Sep 2023 13:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= sang-engineering.com; h=from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; s=k1; bh=ZNeKrg5sAP30QqDQrIU7hgAIKaGsVVJXPQC5z91sR2k=; b=erc3tI F7QNEs3H3KRFvKBZcKcsmkR/ynJaaOGiCM4v/yRCukMAo4aTctihbTYFrXERq9tl fe/H9vzD3XoQYrYWsp46CXnRurhSklfF0+55brjjxwQDb6IMT00XHCo3+I9bOPuA 7gt7yqwwjvsta4WJTxLuJecZdAGK5rPmW71gEo6FHkjJvsXYgc26oiaRnl5wkxR3 7uVtmfW49ezMuky5H9KEqD6X8+B47318Sk4TMw540AyZdZlnafPU2XHUjxp2D7Ff qY90Jum3jeoFSZI2R7KzIHOAcWG/YJM3MNbfJgOtH/y1KekCzZDujyRVRqroJrcv aL7ZFqUGUhCkYbUA== Received: (qmail 720181 invoked from network); 20 Sep 2023 22:10:41 +0200 Received: by mail.zeus03.de with ESMTPSA (TLS_AES_256_GCM_SHA384 encrypted, authenticated); 20 Sep 2023 22:10:41 +0200 X-UD-Smtp-Session: l3s3148p1@dPg7+M8FztgujntX From: Wolfram Sang <wsa+renesas@sang-engineering.com> To: linux-mips@vger.kernel.org Cc: Jonas Gorski <jonas.gorski@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Wolfram Sang <wsa+renesas@sang-engineering.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: [PATCH 1/6] serial: 8250: remove AR7 support Date: Wed, 20 Sep 2023 22:10:27 +0200 Message-Id: <20230920201035.3445-2-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230920201035.3445-1-wsa+renesas@sang-engineering.com> References: <20230920201035.3445-1-wsa+renesas@sang-engineering.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 20 Sep 2023 13:11:01 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777600764504652348 X-GMAIL-MSGID: 1777600764504652348 |
Series |
remove AR7 platform and associated drivers
|
|
Commit Message
Wolfram Sang
Sept. 20, 2023, 8:10 p.m. UTC
AR7 is going to be removed from the Kernel, so remove its type
definition from 8250 code. As with previous removals, I checked with
Debian Code Search that 'PORT_AR7' is not used in userspace.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/tty/serial/8250/8250_port.c | 7 -------
include/uapi/linux/serial_core.h | 1 -
2 files changed, 8 deletions(-)
Comments
On 9/20/23 13:10, Wolfram Sang wrote: > AR7 is going to be removed from the Kernel, so remove its type > definition from 8250 code. As with previous removals, I checked with > Debian Code Search that 'PORT_AR7' is not used in userspace. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
On Wed, Sep 20, 2023 at 10:10:27PM +0200, Wolfram Sang wrote: > AR7 is going to be removed from the Kernel, so remove its type > definition from 8250 code. As with previous removals, I checked with > Debian Code Search that 'PORT_AR7' is not used in userspace. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Wolfram, (Adding Andy for commit 54b45ee8bd42 "serial: core: Remove unused PORT_* definitions"). On 20/9/23 22:10, Wolfram Sang wrote: > AR7 is going to be removed from the Kernel, so remove its type > definition from 8250 code. As with previous removals, I checked with > Debian Code Search that 'PORT_AR7' is not used in userspace. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > drivers/tty/serial/8250/8250_port.c | 7 ------- > include/uapi/linux/serial_core.h | 1 - > 2 files changed, 8 deletions(-) > diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h > index add349889d0a..3b51901926f9 100644 > --- a/include/uapi/linux/serial_core.h > +++ b/include/uapi/linux/serial_core.h > @@ -32,7 +32,6 @@ > #define PORT_XSCALE 15 > #define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ > #define PORT_OCTEON 17 /* Cavium OCTEON internal UART */ > -#define PORT_AR7 18 /* Texas Instruments AR7 internal UART */ I'm a bit surprised definitions are removed from the uAPI, isn't it expected to be very stable? Shouldn't it be better to keep it defined but modify the comment, mentioning "obsolete" or "deprecated"? Regards, Phil. > #define PORT_U6_16550A 19 /* ST-Ericsson U6xxx internal UART */ > #define PORT_TEGRA 20 /* NVIDIA Tegra internal UART */ > #define PORT_XR17D15X 21 /* Exar XR17D15x UART */
On Thu, Sep 21, 2023 at 12:36:05PM +0200, Philippe Mathieu-Daudé wrote: > On 20/9/23 22:10, Wolfram Sang wrote: > > --- a/include/uapi/linux/serial_core.h > > +++ b/include/uapi/linux/serial_core.h > > @@ -32,7 +32,6 @@ > > #define PORT_XSCALE 15 > > #define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ > > #define PORT_OCTEON 17 /* Cavium OCTEON internal UART */ > > -#define PORT_AR7 18 /* Texas Instruments AR7 internal UART */ > > I'm a bit surprised definitions are removed from the uAPI, isn't > it expected to be very stable? Shouldn't it be better to keep it > defined but modify the comment, mentioning "obsolete" or "deprecated"? The numbers up to 20 must stay, they are being used somewhere, setserial implementation in busybox (IIRC). NAK.
On Thu, Sep 21, 2023 at 12:36:05PM +0200, Philippe Mathieu-Daudé wrote: > On 20/9/23 22:10, Wolfram Sang wrote: > I'm a bit surprised definitions are removed from the uAPI, isn't > it expected to be very stable? They were added to uAPI by mistake to begin with. I don't know why people still continue adding more there... Basically we should stop to publish those numbers and move them into internal header (except those 20 or so, that must stay).
On 21. 09. 23, 13:16, Andy Shevchenko wrote: > On Thu, Sep 21, 2023 at 12:36:05PM +0200, Philippe Mathieu-Daudé wrote: >> On 20/9/23 22:10, Wolfram Sang wrote: > >>> --- a/include/uapi/linux/serial_core.h >>> +++ b/include/uapi/linux/serial_core.h >>> @@ -32,7 +32,6 @@ >>> #define PORT_XSCALE 15 >>> #define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ >>> #define PORT_OCTEON 17 /* Cavium OCTEON internal UART */ >>> -#define PORT_AR7 18 /* Texas Instruments AR7 internal UART */ >> >> I'm a bit surprised definitions are removed from the uAPI, isn't >> it expected to be very stable? Shouldn't it be better to keep it >> defined but modify the comment, mentioning "obsolete" or "deprecated"? > > The numbers up to 20 must stay, they are being used somewhere, setserial > implementation in busybox (IIRC). But they define it if we don't: #ifndef PORT_AR7 # define PORT_AR7 18 #endif > NAK. I don't mind either way. But likely we should reserve the field if we go and remove it (setserial has a number->string mapping in busybox). Hm, then reserving it or keep it? Perhaps keep it is better... So ack the NACK :).
On Thu, Sep 21, 2023 at 01:21:46PM +0200, Jiri Slaby wrote: > On 21. 09. 23, 13:16, Andy Shevchenko wrote: > > On Thu, Sep 21, 2023 at 12:36:05PM +0200, Philippe Mathieu-Daudé wrote: > > > On 20/9/23 22:10, Wolfram Sang wrote: ... > > > > -#define PORT_AR7 18 /* Texas Instruments AR7 internal UART */ > > > > > > I'm a bit surprised definitions are removed from the uAPI, isn't > > > it expected to be very stable? Shouldn't it be better to keep it > > > defined but modify the comment, mentioning "obsolete" or "deprecated"? > > > > The numbers up to 20 must stay, they are being used somewhere, setserial > > implementation in busybox (IIRC). > > But they define it if we don't: > #ifndef PORT_AR7 > # define PORT_AR7 18 > #endif Yep, but the problem is that we may not use that number anyway, because two different versions of kernel can clash on the same version of tool that will think about AR7 while it's something different. That's why instead of having reserved space, better to leave with names assigned. > > NAK. > I don't mind either way. But likely we should reserve the field if we go and > remove it (setserial has a number->string mapping in busybox). Hm, then > reserving it or keep it? Perhaps keep it is better... So ack the NACK :).
> I don't mind either way. But likely we should reserve the field if we go and > remove it (setserial has a number->string mapping in busybox). Hm, then > reserving it or keep it? Perhaps keep it is better... So ack the NACK :). Okay. I will resend with this number kept. Thanks everyone for the input!
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index fb891b67968f..a4f5d792679a 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -170,13 +170,6 @@ static const struct serial8250_config uart_config[] = { .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, .flags = UART_CAP_FIFO, }, - [PORT_AR7] = { - .name = "AR7", - .fifo_size = 16, - .tx_loadsz = 16, - .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_00, - .flags = UART_CAP_FIFO /* | UART_CAP_AFE */, - }, [PORT_U6_16550A] = { .name = "U6_16550A", .fifo_size = 64, diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h index add349889d0a..3b51901926f9 100644 --- a/include/uapi/linux/serial_core.h +++ b/include/uapi/linux/serial_core.h @@ -32,7 +32,6 @@ #define PORT_XSCALE 15 #define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ #define PORT_OCTEON 17 /* Cavium OCTEON internal UART */ -#define PORT_AR7 18 /* Texas Instruments AR7 internal UART */ #define PORT_U6_16550A 19 /* ST-Ericsson U6xxx internal UART */ #define PORT_TEGRA 20 /* NVIDIA Tegra internal UART */ #define PORT_XR17D15X 21 /* Exar XR17D15x UART */