Message ID | 20221110081728.10172-3-sherry.sun@nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp15904wru; Thu, 10 Nov 2022 00:20:40 -0800 (PST) X-Google-Smtp-Source: AMsMyM65Ob7oHi2kRYLOoR0/1UJ5YTgGoP+2XmTvNCFPFk/rlY9SzhhwOuEctsl6cDuuxZBJCWSA X-Received: by 2002:a17:906:4bc7:b0:78d:f2d8:4623 with SMTP id x7-20020a1709064bc700b0078df2d84623mr2484086ejv.274.1668068440143; Thu, 10 Nov 2022 00:20:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1668068440; cv=pass; d=google.com; s=arc-20160816; b=CrVgjLhfMTWbjyT1RYvCT0CKBmG2Ol0l5AH0TdCRzp/aN1XigRnPJS4ZWfJPE5gBpm QtATfmsuw6XO03WsvV9xDwIJXzjX4g9QSdamr/AIC1E0R/7iFHPT6qo7CufzCpAc8N8k 2P2jkv77lPXFhmzQsSLnkItWOnzUvfT7DQslJsav2vJ9beO7EN0vt+27DwuwlgyGwL6x 8dzEKnX5HIoItPYHqnPToSmvwAOx3yUgjyUbeOFbhdOJsW4rb0ApIo3Ymz2KMjDhyL1j 1jFteoCG0yr/OT38Dew3JuodqHaUIWskNykVzcyXJbtfzPqGukNX8ubPfo0dTy39TOAU 6gvw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=LTC+t8kYf0GC0OzkqBvmE0A8XCc6Lso/PN9oSUIcjho=; b=MebI0W6SqcINsimU5YItdiiUi0ZDKbw8pHYlCyp7XS4DjOUsVq61GcmcaD9rv+Ip5a 4RCWwaZ8lPrjedkPgR4i7oklhqBswbbezKj508/4uZW/N/2YUlvKX5XDp3mFrNaTTqdj V2cBxI79DV2u6mFWCRTgNCPgY3ZKbKTwEwnt9SnSN/ZMP2n/B6dYKbwPJPKhR7GvOabI Uj2h0vNTPQeHLriMlQHNaPhlq6RkjFBBfzPIr+7qH4JVlnzU/Q36cNWb7/N3qtNKmLkN j0LDHOY8CICpiObDLnBcaUDuA9rFYGSg27rg4GCC7Naq7Yp+zO2fbOO161n/XcFAeZz5 tvkQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=H0pSQmtb; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nd10-20020a170907628a00b007ae199ea55asi19301278ejc.817.2022.11.10.00.20.16; Thu, 10 Nov 2022 00:20:40 -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; dkim=pass header.i=@nxp.com header.s=selector2 header.b=H0pSQmtb; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232823AbiKJITs (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Thu, 10 Nov 2022 03:19:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232927AbiKJITk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 10 Nov 2022 03:19:40 -0500 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20067.outbound.protection.outlook.com [40.107.2.67]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9C8E2250A; Thu, 10 Nov 2022 00:19:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MGb5zzfb54gQDTXVDRWZktmk1YnJvJ5SSFI2dTEJ20e8DP9NiaUm9ophCNl+x8tDlEEOr3oLQ98n7KerYJaegHgPJncn56Javf8eDD9Ybv4DzR9t+4NdrbHb6BayphOLwzuo+cC/GSIZFFC76Hy/rbrqzmMxJyiZ9UlgstTkESd3J9Hs9uY0rLqnzXzbvgIHpWAU9ESrXORFNMTITR6ZLqPATUdIi7VSIq3bFfvQxQ/Z7VRVI2arPFQI6bIU9JfeSQeSlaxWIXS7RZFJFui9kIeGvdLFy31712omwnmu+rBbA2ARVwlKqKvgbCDdlXUxmqlKnAnEOyXi42KZr5hPTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LTC+t8kYf0GC0OzkqBvmE0A8XCc6Lso/PN9oSUIcjho=; b=mo5ErY5Aa19YxuvNWlb/+42VNgEIMm51KMgZSyeBsY4SR4IVEffmTwgibkVfYyzJiV8z2wV6bBZ+IttV+YXzQ6aX9KNNRea1eygdgURoqS+7vKnVK++8cNSiy446cZAhN/u6kzMWS+VgWu7z/Qt0RjTij02g1HXz9KlM+c0YO+KHalxkCI7pGdhKrDcPgQpicAr+p33/Qa1xemceJRmEL1bjesM+J3OAAL3dioPtfHG2SQbslWa3GvEIqMogF0XlKkcvOzFEW3aXtC1y2ys3piNMKtrgaY1Y830WwNc+duamqhVVeEm/kqvbnUzPEmnHf1CvGvS+0GRdHJeSa/R3Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LTC+t8kYf0GC0OzkqBvmE0A8XCc6Lso/PN9oSUIcjho=; b=H0pSQmtbASDTA7yDGA+A9owUyPsCXkRs8ELtsqdrKH31k7eqYEmtsMbQcq+z1KM33q23GAQYiquMeqyksjajnErVBlfIAX9Cw59NTEyZCF5R9tiOLREpgnre2ZSHWZwIJVgAlOsBO5MtIpPPPpmoh2QYZgiZm/kTv1hxQEOLp9M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AS8PR04MB8404.eurprd04.prod.outlook.com (2603:10a6:20b:3f8::7) by AS8PR04MB8916.eurprd04.prod.outlook.com (2603:10a6:20b:42f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.24; Thu, 10 Nov 2022 08:19:30 +0000 Received: from AS8PR04MB8404.eurprd04.prod.outlook.com ([fe80::71f1:f7bb:5039:e55d]) by AS8PR04MB8404.eurprd04.prod.outlook.com ([fe80::71f1:f7bb:5039:e55d%3]) with mapi id 15.20.5791.027; Thu, 10 Nov 2022 08:19:30 +0000 From: Sherry Sun <sherry.sun@nxp.com> To: gregkh@linuxfoundation.org, jirislaby@kernel.org Cc: michael@walle.cc, jingchang.lu@freescale.com, tomonori.sakita@sord.co.jp, atsushi.nemoto@sord.co.jp, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-imx@nxp.com Subject: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear UARTCTRL_LOOPS in lpuart32_shutdown() Date: Thu, 10 Nov 2022 16:17:25 +0800 Message-Id: <20221110081728.10172-3-sherry.sun@nxp.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221110081728.10172-1-sherry.sun@nxp.com> References: <20221110081728.10172-1-sherry.sun@nxp.com> Content-Type: text/plain X-ClientProxiedBy: SI2PR02CA0022.apcprd02.prod.outlook.com (2603:1096:4:195::23) To AS8PR04MB8404.eurprd04.prod.outlook.com (2603:10a6:20b:3f8::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR04MB8404:EE_|AS8PR04MB8916:EE_ X-MS-Office365-Filtering-Correlation-Id: e38b3dd6-c20d-4ebe-90db-08dac2f44a26 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jUVAAbfLKDws/ncQMLRNe6gEGy9HQqhhYczVqWcmlN3O4MQPCykhmA89RTys2rWdqOd6Ar4Ef2/pm1hDU3IhWaIaNVPfvXTqYEt0f0mhaMZ9W5M+Wlu3QPJCrcXikfBiJWedry7lV+iEh56vUtk+Mv6biat+/MA0+mdTWCZYswfRxlQsNtUZNjBjQHlcRRNpyrfngP7a7uvjr1vmRPq35z90JqZ7FslZAyt0OvGUTdzXPysm+TmvBlggWNhfLcMrXJEJlKgj2zYoqsE9iVWuJ6Gqsy701yOxdB4UUVta9qX7aM7SEFKSXx9MTXEyaMyKEvxs6PflyGhtIrkSBFyH8xNfd38GNS7j4rv9iYE9eWzWZkcW2gMPOQ0rHQRxs0jnrnupR0aI9HjSCZR/Ha2T+gZnEmGSu3Q0LdB8AwYqW+DDGgHY+RE9sfwTiXhKI30/uI64v4GELogXiIMbUZiuLF9Qw5PlgX7q1LJpfoJjEyxZE6R95OPWLU0R02yOiDmpj3usNxlB9teEWkHqQ/wcvZb0Zun7XpWEM424S/gcFt88o0JYUfeiWgRQy/P+X+sIWvXV6LfqB4f3MzHTUqPDdQZ22IIXtvnc4S7Bo0UbiPgJVVtKlVPlBwhbxDYScsKCUhdNmNOvVpL/tDNaxeiGQUv4DOCH4QeVdPjpbzvdqE2Jv6NcnTvZb6Sm/rXHSwzMJ/Fsv7NeZ+OQ+qTHEoUzNdOCeV2xB0RTs5mkPmIL1N0A10xJkWSqoA8Z/D+BpY/j9Cwz4WLJ9PQctoVQlBMSag== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR04MB8404.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(346002)(366004)(136003)(376002)(39860400002)(451199015)(6506007)(38100700002)(38350700002)(36756003)(86362001)(26005)(2906002)(478600001)(6666004)(186003)(41300700001)(6512007)(316002)(66476007)(6486002)(44832011)(66556008)(83380400001)(66946007)(8936002)(2616005)(1076003)(52116002)(8676002)(5660300002)(4326008);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: R8yDWxF3W0+DoATY3hGoMWcyGloDd/28xfuho8AOT1btLeZtKz+9OxlFEfNja5+mPrDp1Pg31+M8AfXCkkypCOtXnm+oK57DuDNtr5J1fIfA9fh3xoRuPZfY7WsXb/hVWEg69rUCl47/iC7m7B6Mbvb4ABeKgZbOU2bOP/gyNkBFk+5dCaFgE0G7T6s49E47xhPnRZZMO/lyUnMwsRIPLU0VmJLHuL/TwrX2quF24/OWS6OdPQ6TrsPUMaVpKCT2D/vtt0PFXvQvSnSrlJomFhUWD3zT5FCTzRYxfhTwD87CbVCn3zdwbWccQR1lFrGp9JinRmvffecYz57SR7BfDJweFukvg3VtCQ1nJDk7VY90Y4PekSYDj/Kvk6x2L8DoVTIGs+YvRwqH7oTVAuRaUCzLTORToYAxUV4ct6dZHgM73+E6fRGY4u2mt5NmCmYsnWV4F8JU8/mL7dyw9APlxvS//85M00wV+LCaikwhDapmrn8TJ7uu+Ax9jW6KF+NkUqrbzEpey5ybtkpvXxc4Hx+/vOs3ltjyfSAMYZK9myKJnZleB+pxRWXLMSgTlj1i/q05pZzAWs8ril51knwnb2nKryN1ccEbka9YtlzhPCYlTKfTEW3DsgQ25IYyJQKIFVja/gdRJ8xflpk2kmkjDUuB1ayHyrRMMPO+PinJ+j2ZP7qzHKj08S7SW8HraWjJq5sjHjCjfGPBtGwx8edYlu1p5kdYatqtdHMtFAkJt8tZYhrJWG/BgVlJLuuE4fvul3Ibn2Ftb+zum2DoiApb3oNEAycV2yUccMU1MZHBeTBO1C5XK4HdcxU5lOQJYE7ndc1jSae6dhiiuVu9yYEj2LXc3+SOtbOd/QM6J8V3tXoynjCrALFddttqbG41SkV8J5FzlDpAY+v2AYoxA6QY5fqAmQcwU69Jvi3lM2xg/dhwzIXMnAPFmAj8tYGCwrQQ4tZySmIwZIxaN3j4b2klD/ZGTUMLRgTtG87l4Mm9s2yO8GSfObYZKY97Gwst+Wlj6BLYvBi3zdDmr/SWSciRiHzKuPPYCf83eSj3Voio5Vn98gY0J6vPgTPuxDPItmFZQ1X1IhxNqJ07jAx2eB5CwT1dPFLu8VLHgHu68qGP324ShBDXTIyU93VhaKkmrGmkn+wbHMiOFf+V1rCjRYxX9uOlb4Yink3ICQx0sivixEjaYRbUnMge9X/rbbLjSo2TXdG5mzYYKyM8+u6S1XLdWP9ojqtDscDFFyjy55fOvawk68fYHS6xM9coPl2ojvFgIoeHdwJTZU3OCGnI+PW/T/3StaDCz6meGjdt7cW6F/7hTpWnRd5J/FxDDtHfLQeBGjTKS8BHO1RTUvoRckEPDo4HZYNozZ/NVg3MN3xVQVTWdOmVJINRrcwlIHKzjDoogHGnY7ihHtQuPyjZ1VDcDXebNU4ZxWg1lV8mp/j91UQcC7To+IeJpRzuGvIe4c1r1yue3nbQz+Mc+T/NB7JnMsqhqdDlQQL/IgQpwKlW8bOCWTsb6joM1cAF3xDfpJXXXXQxY468Lof6b6WZiqE9ERZWlR/tsfEe9PaIF9xLSSX9rcl/P0no079Y4XlePlvt X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: e38b3dd6-c20d-4ebe-90db-08dac2f44a26 X-MS-Exchange-CrossTenant-AuthSource: AS8PR04MB8404.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2022 08:19:30.1614 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jGL3OvEMcd+JPbAoGrgagw4Oil6yG/2+ATLXznxrD5me06rjk6FnhQWS62yHq8WVtd8Ni30Huo71ODqihi72jA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8916 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749096532655186938?= X-GMAIL-MSGID: =?utf-8?q?1749096532655186938?= |
Series |
fsl_lpuart: improve Idle Line Interrupt and registers handle in .shutdown()
|
|
Commit Message
Sherry Sun
Nov. 10, 2022, 8:17 a.m. UTC
UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback mode, but
nowhere clear this bit, it should be cleared when closing the uart port
to avoid the loopback mode been enabled by default when reopening the
uart.
Fixes: 8a0c810d94f0 ("serial: fsl_lpuart: add loopback support")
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
Changes in V2:
1. Split one patch into four smaller patches to improve the commit
messages and add Fixes tag as suggested by Ilpo.
---
drivers/tty/serial/fsl_lpuart.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
Am 2022-11-10 09:17, schrieb Sherry Sun: > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback mode, > but > nowhere clear this bit, it should be cleared when closing the uart port > to avoid the loopback mode been enabled by default when reopening the > uart. It's cleared in set_mctrl(). What is the expectation from the serial core here? -michael
> -----Original Message----- > From: Michael Walle <michael@walle.cc> > Sent: 2022年11月23日 18:34 > To: Sherry Sun <sherry.sun@nxp.com> > Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear UARTCTRL_LOOPS in > lpuart32_shutdown() > > Am 2022-11-10 09:17, schrieb Sherry Sun: > > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback mode, > > but nowhere clear this bit, it should be cleared when closing the uart > > port to avoid the loopback mode been enabled by default when reopening > > the uart. > > It's cleared in set_mctrl(). What is the expectation from the serial core here? > Hi Michael, If we call .set_mctrl(TIOCM_LOOP), the UARTCTRL_LOOPS will be set. Then when we call .shutdown(), serial core won't call .set_mctrl() to clear it, so the UARTCTRL_LOOPS need to be cleared here. Per my understanding, .shutdown() should clean up all the uart flags, as the transmitter and receiver will been disabled, we will re-configure all the settings needed when re-open the port. Best Regards Sherry
Am 2022-11-23 11:58, schrieb Sherry Sun: >> -----Original Message----- >> From: Michael Walle <michael@walle.cc> >> Sent: 2022年11月23日 18:34 >> To: Sherry Sun <sherry.sun@nxp.com> >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear >> UARTCTRL_LOOPS in >> lpuart32_shutdown() >> >> Am 2022-11-10 09:17, schrieb Sherry Sun: >> > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback mode, >> > but nowhere clear this bit, it should be cleared when closing the uart >> > port to avoid the loopback mode been enabled by default when reopening >> > the uart. >> >> It's cleared in set_mctrl(). What is the expectation from the serial >> core here? >> > > Hi Michael, > > If we call .set_mctrl(TIOCM_LOOP), the UARTCTRL_LOOPS will be set. > Then when we call .shutdown(), serial core won't call .set_mctrl() to > clear it, so the UARTCTRL_LOOPS need to be cleared here. > Per my understanding, .shutdown() should clean up all the uart flags, > as the transmitter and receiver will been disabled, we will > re-configure all the settings needed when re-open the port. Two things, (1) should the loopback be cleared on a newly opened serial device? (2) as mentioned in my other reply, this can also be handled in the startup. Eg. the startup can clear the loopback flag. (together with possible hardware events). I'm not that deep into the serial core, thus my question about the expectations from the serial core. I guess the answer to (1) is yes, but better to ask. -michael
> -----Original Message----- > From: Michael Walle <michael@walle.cc> > Sent: 2022年11月23日 19:09 > To: Sherry Sun <sherry.sun@nxp.com> > Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear UARTCTRL_LOOPS in > lpuart32_shutdown() > > Am 2022-11-23 11:58, schrieb Sherry Sun: > >> -----Original Message----- > >> From: Michael Walle <michael@walle.cc> > >> Sent: 2022年11月23日 18:34 > >> To: Sherry Sun <sherry.sun@nxp.com> > >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear > >> UARTCTRL_LOOPS in > >> lpuart32_shutdown() > >> > >> Am 2022-11-10 09:17, schrieb Sherry Sun: > >> > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback > >> > mode, but nowhere clear this bit, it should be cleared when closing > >> > the uart port to avoid the loopback mode been enabled by default > >> > when reopening the uart. > >> > >> It's cleared in set_mctrl(). What is the expectation from the serial > >> core here? > >> > > > > Hi Michael, > > > > If we call .set_mctrl(TIOCM_LOOP), the UARTCTRL_LOOPS will be set. > > Then when we call .shutdown(), serial core won't call .set_mctrl() to > > clear it, so the UARTCTRL_LOOPS need to be cleared here. > > Per my understanding, .shutdown() should clean up all the uart flags, > > as the transmitter and receiver will been disabled, we will > > re-configure all the settings needed when re-open the port. > > Two things, > (1) should the loopback be cleared on a newly opened serial device? > (2) as mentioned in my other reply, this can also be handled in > the startup. Eg. the startup can clear the loopback flag. > (together with possible hardware events). > > I'm not that deep into the serial core, thus my question about the > expectations from the serial core. I guess the answer to > (1) is yes, but better to ask. > Hi Michael, For the (1), I have checked the serial core, seems the answer is no, . startup() won't clean the status, only when the uart device is probed, lpuart will do the global reset to all the registers instead of .startup(). So I think the uart running status cleared in .shutdown() is reasonable. Best Regards Sherry
Hi Sherry, Am 2022-11-23 12:30, schrieb Sherry Sun: >> -----Original Message----- >> From: Michael Walle <michael@walle.cc> >> Sent: 2022年11月23日 19:09 >> To: Sherry Sun <sherry.sun@nxp.com> >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear >> UARTCTRL_LOOPS in >> lpuart32_shutdown() >> >> Am 2022-11-23 11:58, schrieb Sherry Sun: >> >> -----Original Message----- >> >> From: Michael Walle <michael@walle.cc> >> >> Sent: 2022年11月23日 18:34 >> >> To: Sherry Sun <sherry.sun@nxp.com> >> >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; >> >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; >> >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- >> >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> >> >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear >> >> UARTCTRL_LOOPS in >> >> lpuart32_shutdown() >> >> >> >> Am 2022-11-10 09:17, schrieb Sherry Sun: >> >> > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback >> >> > mode, but nowhere clear this bit, it should be cleared when closing >> >> > the uart port to avoid the loopback mode been enabled by default >> >> > when reopening the uart. >> >> >> >> It's cleared in set_mctrl(). What is the expectation from the serial >> >> core here? >> >> >> > >> > Hi Michael, >> > >> > If we call .set_mctrl(TIOCM_LOOP), the UARTCTRL_LOOPS will be set. >> > Then when we call .shutdown(), serial core won't call .set_mctrl() to >> > clear it, so the UARTCTRL_LOOPS need to be cleared here. >> > Per my understanding, .shutdown() should clean up all the uart flags, >> > as the transmitter and receiver will been disabled, we will >> > re-configure all the settings needed when re-open the port. >> >> Two things, >> (1) should the loopback be cleared on a newly opened serial device? >> (2) as mentioned in my other reply, this can also be handled in >> the startup. Eg. the startup can clear the loopback flag. >> (together with possible hardware events). >> >> I'm not that deep into the serial core, thus my question about the >> expectations from the serial core. I guess the answer to >> (1) is yes, but better to ask. >> > > Hi Michael, > > For the (1), I have checked the serial core, seems the answer is no, . > startup() won't clean the status, only when the uart device is probed, > lpuart will do the global reset to all the registers instead of > .startup(). So I think the uart running status cleared in .shutdown() > is reasonable. That's not what I've meant. Even with this patch as it is right now, the loopback flag is cleared on a "newly opened serial device". Just with one difference, you are clearing the flag in shutdown. My question was rather, should the loopback (or generally any mctrl flags) be persistent across close/open cycles. E.g. looking at omap-serial.c, this driver doesn't seem to handle the loopback flag at .startup() or .shutdown(). Same seems to be true for sh-sci.c. Greg? -michael
> -----Original Message----- > From: Michael Walle <michael@walle.cc> > Sent: 2022年11月23日 19:43 > To: Sherry Sun <sherry.sun@nxp.com> > Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear UARTCTRL_LOOPS in > lpuart32_shutdown() > > Hi Sherry, > > Am 2022-11-23 12:30, schrieb Sherry Sun: > >> -----Original Message----- > >> From: Michael Walle <michael@walle.cc> > >> Sent: 2022年11月23日 19:09 > >> To: Sherry Sun <sherry.sun@nxp.com> > >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear > >> UARTCTRL_LOOPS in > >> lpuart32_shutdown() > >> > >> Am 2022-11-23 11:58, schrieb Sherry Sun: > >> >> -----Original Message----- > >> >> From: Michael Walle <michael@walle.cc> > >> >> Sent: 2022年11月23日 18:34 > >> >> To: Sherry Sun <sherry.sun@nxp.com> > >> >> Cc: gregkh@linuxfoundation.org; jirislaby@kernel.org; > >> >> jingchang.lu@freescale.com; tomonori.sakita@sord.co.jp; > >> >> atsushi.nemoto@sord.co.jp; linux-serial@vger.kernel.org; linux- > >> >> kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > >> >> Subject: Re: [PATCH V2 2/5] tty: serial: fsl_lpuart: clear > >> >> UARTCTRL_LOOPS in > >> >> lpuart32_shutdown() > >> >> > >> >> Am 2022-11-10 09:17, schrieb Sherry Sun: > >> >> > UARTCTRL_LOOPS bit is set in lpuart32_set_mctrl() for loopback > >> >> > mode, but nowhere clear this bit, it should be cleared when > >> >> > closing the uart port to avoid the loopback mode been enabled by > >> >> > default when reopening the uart. > >> >> > >> >> It's cleared in set_mctrl(). What is the expectation from the > >> >> serial core here? > >> >> > >> > > >> > Hi Michael, > >> > > >> > If we call .set_mctrl(TIOCM_LOOP), the UARTCTRL_LOOPS will be set. > >> > Then when we call .shutdown(), serial core won't call .set_mctrl() > >> > to clear it, so the UARTCTRL_LOOPS need to be cleared here. > >> > Per my understanding, .shutdown() should clean up all the uart > >> > flags, as the transmitter and receiver will been disabled, we will > >> > re-configure all the settings needed when re-open the port. > >> > >> Two things, > >> (1) should the loopback be cleared on a newly opened serial device? > >> (2) as mentioned in my other reply, this can also be handled in > >> the startup. Eg. the startup can clear the loopback flag. > >> (together with possible hardware events). > >> > >> I'm not that deep into the serial core, thus my question about the > >> expectations from the serial core. I guess the answer to > >> (1) is yes, but better to ask. > >> > > > > Hi Michael, > > > > For the (1), I have checked the serial core, seems the answer is no, . > > startup() won't clean the status, only when the uart device is probed, > > lpuart will do the global reset to all the registers instead of > > .startup(). So I think the uart running status cleared in .shutdown() > > is reasonable. > > That's not what I've meant. Even with this patch as it is right now, the > loopback flag is cleared on a "newly opened serial device". Just with one > difference, you are clearing the flag in shutdown. > > My question was rather, should the loopback (or generally any mctrl > flags) > be persistent across close/open cycles. E.g. looking at omap-serial.c, this > driver doesn't seem to handle the loopback flag at .startup() or .shutdown(). > Same seems to be true for sh-sci.c. > > Greg? > Hi Michael, Now got your point, thanks for the clarification. I have checked some other drivers, maybe you are right, now I am also confused that if the loopback flags should be persistent across close/open cycles. ☹ Best Regards Sherry
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c index a8f8e535077a..dbf8cccea105 100644 --- a/drivers/tty/serial/fsl_lpuart.c +++ b/drivers/tty/serial/fsl_lpuart.c @@ -1772,7 +1772,8 @@ static void lpuart32_shutdown(struct uart_port *port) /* disable Rx/Tx and interrupts */ temp = lpuart32_read(port, UARTCTRL); temp &= ~(UARTCTRL_TE | UARTCTRL_RE | UARTCTRL_ILIE | - UARTCTRL_TIE | UARTCTRL_TCIE | UARTCTRL_RIE); + UARTCTRL_TIE | UARTCTRL_TCIE | UARTCTRL_RIE | + UARTCTRL_LOOPS); lpuart32_write(port, temp, UARTCTRL); spin_unlock_irqrestore(&port->lock, flags);