Message ID | 20230310181921.1437890-2-neeraj.sanjaykale@nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1031849wrd; Fri, 10 Mar 2023 10:29:19 -0800 (PST) X-Google-Smtp-Source: AK7set+Q08MSFu5/vQ4qMWNIoZDXWAZ2xL3h4baFNhzrD6CqRIFJHX6kjglmOYR8aylpaGWZq1SA X-Received: by 2002:a05:6a20:734f:b0:cd:26b2:ee17 with SMTP id v15-20020a056a20734f00b000cd26b2ee17mr30187311pzc.36.1678472958900; Fri, 10 Mar 2023 10:29:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1678472958; cv=pass; d=google.com; s=arc-20160816; b=KPumP1TcCcaa5ooyplnQa8IHrvV4JxphZyAbOCnNwYHjkmBJgu+9MXTvfh5jtwVp2v sGymIIUX7fYKu3y6dwYV+PwPTyT+O8AGEzkZEXeOWEWBSWF0jAl6EEnEPbLDpnRrHw1S 8F7P9Uh5tFRn0/GNgqUxD3lOIZ8jSrM95z6Y+2qMeXOg479QzBU6mLLpYQjnSbeSFYeN U7xCYqf9n5MsXRmUJ0NNghEYHpfqxf5Aa0qNvfEj1/PFhHBhRbQyuGGXv8NJY06Zh2SS 7x6eCOjAbkxGGl04ZhaWyaCRMzKB0MHsc9OOJhUEhzPsYoPiP2mqWNqPZEcESnVk3tFX ePSw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Y8vUV52mlQbn5GtqgDoRGrOJqgeNqnjP4c40QHQo9Wg=; b=CC05qAZFYzUn50hT4/M6m7bsMoTSQhQHi6Jtgl4+SUYno2feDQBjGUDKp1uVS7pyxL Adx34plE8zFTr9DGUzDr1xgNgd3Wq3NU/6KtMJnhCQT1T7Gi+p1+tY2kijIpnsCJcyXC HfmX0gIQEYXThWCQ9ztucfXh44E7GHnRCD2bbuQw94uX0yJoI1HLuUqmQh8b3LFxMdJO 20rFtQCdO4+yoiW6+6Q/Pzuphg5dROBLLUENI6B0y3s62PZxBxAYZWiwRVyKoE5l1XQc zEQGVZUiBiy8rmJoDOklwkkjG9bay+AWaKPJJx8Ygx8d7KRA0u/JRi0CvwaV73SJyt06 fhPQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=ekTH32RI; 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 e33-20020a630f21000000b00502f0ddd50bsi354755pgl.382.2023.03.10.10.29.06; Fri, 10 Mar 2023 10:29:18 -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=ekTH32RI; 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 S231600AbjCJSUR (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 13:20:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229827AbjCJSUL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 13:20:11 -0500 Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02on2075.outbound.protection.outlook.com [40.107.241.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4B9510284F; Fri, 10 Mar 2023 10:20:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d+mrvo22InCqcnjThS568Y9yeNfcsQQjuwMZoUtAiyhMYx4vuDlH2iuPamyS3mNGi4owvqBkzKPr14LXCm9rxBegGEI3/m3XkOfnYw6YS303b94s42qoTu0v5g1SM8wRuqYalhdywHSaCXeckXiABPUaDy068k9Q7aRReHqidk0D/7gOYe8svTia0SvmJH5U6cpdH8fdJ+yybtsQeyWaAgHxExtPzlRFTZYBAknsLKE7LDZbcTi5xq/UUjin0B9x+pqZXFLBQcueEhHInCko0IOyYKtbyHuzaVO3nRMEiPuH/HlkqUMpaGy8n/xPy2GjTRyyaUYnzwj30+oKNU/0Pw== 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=Y8vUV52mlQbn5GtqgDoRGrOJqgeNqnjP4c40QHQo9Wg=; b=LUFvf7rDGf2FSA4xH5sOUrP9ST1qYOzOkP1WOL2lA6qPFbYYrl0sx4U9CobSg57pwfLwJX4yo2MuD2SXI7uI9dxVNnIdaYprsPgO5xFTqiIY4OM41cuNPswnoSVr5k4ErPQeZADQ2tZn6MFWXOFYGBrSRj0ixPeezoGL3L8oycU4NII0TUR1TXL9iC0MDOa2mLhW8LvPG+sU6t5HvYRc3A50mVhGcJ25OJpLHvyYGUNPL7nYB1YiCPOd9L2wKEn8qTWrN09X4FW8Y0EXhnUG1OLTdOePWolaElaYjA/+fSZ+YGpOPM1X2SBmZF6yvWs213qIPpkRnyuSKLVkHG9u5A== 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=Y8vUV52mlQbn5GtqgDoRGrOJqgeNqnjP4c40QHQo9Wg=; b=ekTH32RI62JHi+fE/4XmNB8fhN+oDz+vrvgpFibrbFjzVdedmiODNZ/63Pz8VlVruQZbYFogG+vZ5kr2ko9gfDMMYqZDEspxip+gjHSdpOZqELaPBj4TlYZqDvakUlug8c470Eiv6G2oOHROrPe8JzDOT/oipkYgIvR28XPGOIo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AM9PR04MB8603.eurprd04.prod.outlook.com (2603:10a6:20b:43a::10) by DB9PR04MB9704.eurprd04.prod.outlook.com (2603:10a6:10:303::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.16; Fri, 10 Mar 2023 18:20:07 +0000 Received: from AM9PR04MB8603.eurprd04.prod.outlook.com ([fe80::45d2:ce51:a1c4:8762]) by AM9PR04MB8603.eurprd04.prod.outlook.com ([fe80::45d2:ce51:a1c4:8762%5]) with mapi id 15.20.6178.019; Fri, 10 Mar 2023 18:20:07 +0000 From: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, marcel@holtmann.org, johan.hedberg@gmail.com, luiz.dentz@gmail.com, gregkh@linuxfoundation.org, jirislaby@kernel.org, alok.a.tiwari@oracle.com, hdanton@sina.com, ilpo.jarvinen@linux.intel.com, leon@kernel.org Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, amitkumar.karwar@nxp.com, rohit.fule@nxp.com, sherry.sun@nxp.com, neeraj.sanjaykale@nxp.com Subject: [PATCH v8 1/3] serdev: Add method to assert break signal over tty UART port Date: Fri, 10 Mar 2023 23:49:19 +0530 Message-Id: <20230310181921.1437890-2-neeraj.sanjaykale@nxp.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230310181921.1437890-1-neeraj.sanjaykale@nxp.com> References: <20230310181921.1437890-1-neeraj.sanjaykale@nxp.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR04CA0195.apcprd04.prod.outlook.com (2603:1096:4:14::33) To AM9PR04MB8603.eurprd04.prod.outlook.com (2603:10a6:20b:43a::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR04MB8603:EE_|DB9PR04MB9704:EE_ X-MS-Office365-Filtering-Correlation-Id: 302b7648-666f-4580-e05e-08db21941389 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3I6IzM5ASbdSjFoq/dvYlxJvzn1abCYmyatrw+/lw2u1iYHIcBdOpBSl8Nfn6vIUEJdzwPH/u7LJHvuxBlYRslkyTQNP/VU18fRMt4KHAPrfNJDTiCdVopi/LBvjyHx0SUzmgOp8w3N+MpXJpiOi/u+7c9mhQBtuOv/TNK4QCErtFAd6Bl6BGTW6DCb5p6TDg7Lq3y0tz/UlvU3W+uZ9bY0Rd3y+P0ZK8Q2DWJlakOAdT+t8NDAOMA5aMwfWX6/RQVI2M5EsqGaFA8fzDobyY+GZv6iGGQgrCiTGcAnmBNiyP/EouiLVSRHRo2mkDtAR5sBN5Ze3dWYDuhdZZwVsh1jGesMRx4aTmu+/356+HDKI6mRds6BEY0g1bJEs/BxoT2CoPB5eS4YWpd6sygC9kD0MtRiF4tK9H4PTnbhiN/VRuEn6l5U8FwCR3ddN/JT3ZQMerc1iTzhT3/KPHNNnex8dx2WBN05OHhBy6Sxv69TvcYSGIAwm3b6rZ5qtOgqiCYSnVn/whTkbp7xPiyqb/IYK34VRKOQSyNpoiji9og+uq10miByHR8GjGTYwE7/hLo3guob+uRqr1xnHjAQCK9AF13i4DimdEAM7AofxtB10BXQ6T+C9Z7MS008rzc6aoZyMY2EbOXpp9RBGKqyrzQVldrrmNMVCjFajTv1IpdrhheHmG155tJIoEFJLDUN1TmaqXXTJnlUeBWVzFKgXfhVdP6VWz9EOGGtK8YLK744= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR04MB8603.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(346002)(136003)(396003)(366004)(39860400002)(376002)(451199018)(66946007)(66476007)(66556008)(1076003)(6512007)(6506007)(316002)(38100700002)(26005)(8676002)(36756003)(7416002)(478600001)(6666004)(8936002)(2906002)(5660300002)(6486002)(921005)(52116002)(86362001)(83380400001)(4326008)(2616005)(38350700002)(41300700001)(186003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: vTFeAV2uz3Qsp67YdsG8bPDHZpATSEGt93YheGDThYLCgpsyZ4PWI1Rp2iSB1vArrgGo1J0BqJTtJAV/d4qO0YhZnJOeKFIWfGbUipGRQgTpgzFjO5q+EhCK8915CZyBOn+JP5+w6gBvRh8EwdhBxwbZqHR0H57s8gNiwwFfGmKJPKcIClENCxpgC5Em7oFWqWT4lr+/UqkRr0sfW9cIGis0OFU1xO+RoI734MFc6mM8LYWy9ar3AkV03elltHri7eBqaq/5yGs+LM3rdKZzJvV2zi0guWqdT5FnggS2r9TeuStzk1zAeYCtko8uUWhDmeJqIsfphUuFVNDWy0na59zYjCrSC4DETIXLGdQJYBcSWkletrKgkeww6qwWXcbqd89U0hbfl2hKVMf+Flrvz/oYKW9TMUe9yUynP+H6wrNQYqCOZFsBnlIvGrqefO2i94oKgG9pQ1FIUqhf4MEqiJbVTTwEyXh+gXKOXuUQXeKEhD8csyRyWIeg16T2U86jn/0wBzjiFzfSoQ/y3zcQTkeR9PKHoPmk3GkFeGp5u14Xh6NfTXiIEnMJZ9vmV5XJqV8HJipLBSLKAYlX7I3hz9FXaCb6TArbZ8A2eqASRuPpZOzgCjFFHhJAWxpjecB9tj1Tj1NvUfROue9ZUTH0+dmOhP3sjWt/hZg4SwNE1LIcHgKuL1uDlo234LtoxzWAMpgGp6xOhFbVeYjl+Gsz7VDTpeXlFPQAAtPU9dRLuFcbawxbu2BSdVAlI2uAeYqb0Fr+haWAkx9W0VgRNXrsMp6ifP2a3SbEsrlb77MH0EJ0dSpEqmzSfjWtBTohOtXa3rqxvxGYLhLnWUCuiRog8QYzTg9htIbbUWbpu8h8Ivv1ztRiTg8shyc72bXkJ9kJ2YxhWaOMLw86uEiYkyN/vac2pQTkUAjEu75JGhSiM4LMYHtbUHl55bXDtZirQN2sXH1z3UpoEP1Na3OOJDmkb/w59GYJ4XbiikXDSACgV/aGAHq9+YfkyF8yE4IlWJVBC0jFCFVIhY4nl+OiDimrrt82wC4Ocihv0m0SZiQwP8MAkKuHm7zfUj4B9TiWMx9/KxkTMo5tu+2tikfgPxK0PYALJ7xrRVAXru4EhdUNihZLEDe+XRPTzPpNuX2cgm9UZMoWN3K1/uqYJ9GTqPpoXqofLfaVCtaxibF/p7ZiQB3GpZnlvAQFU1FMTz2IMWz8bkQQO6A7uhn4g+vlQC/OgObSrqaexPebCYWvcEWYuL0C2RlSAmDz9DX7cf2H2wmFhPPtSR7K186WNFLEqLprAhbHMmJqPVXkXgu331Q9o909bn4h1iE9oiwVOxMaaNzf+F2JZtg/bx0ACke5o3mzNIWARodHHtV+SAYz7e2tmaP3RpxwGrAeZbGjvThjv/cVIL17kD/WJUZeC7Rgi9nppEu++9pI2tfz2g4r3+UwC7hpPjICpZc4f9f/rm4nKkCTGlA1+amRDmMSaXltOamKzPE9VdTPKXzpQDO77VRKRPIhvlNOEg55Dxe/M17/2xdjO1+MLumL1b81NZWMNXAUghrFWBZ2y83HaJbWS3XYmKUHJ6qiBjfNP+HZcd3Q5no+V1ItkCxHVaggfRkUpofbKw== X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 302b7648-666f-4580-e05e-08db21941389 X-MS-Exchange-CrossTenant-AuthSource: AM9PR04MB8603.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2023 18:20:07.2079 (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: +Igxur1sDovRVuozIQN6cirOtOOQsLfSXNOxlZSyDFRLAOeOD2edqHnkjsJtmNWw6D9pUMWPgmFRFiTi0af6U4A0AoQ5iYgmGZcO/6K4FAw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR04MB9704 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,URIBL_BLOCKED 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?1760006461265527019?= X-GMAIL-MSGID: =?utf-8?q?1760006461265527019?= |
Series |
Add support for NXP bluetooth chipsets
|
|
Commit Message
Neeraj Sanjay Kale
March 10, 2023, 6:19 p.m. UTC
Adds serdev_device_break_ctl() and an implementation for ttyport.
This function simply calls the break_ctl in tty layer, which can
assert a break signal over UART-TX line, if the tty and the
underlying platform and UART peripheral supports this operation.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
---
v3: Add details to the commit message. (Greg KH)
---
drivers/tty/serdev/core.c | 11 +++++++++++
drivers/tty/serdev/serdev-ttyport.c | 12 ++++++++++++
include/linux/serdev.h | 6 ++++++
3 files changed, 29 insertions(+)
Comments
On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote: > Adds serdev_device_break_ctl() and an implementation for ttyport. > This function simply calls the break_ctl in tty layer, which can > assert a break signal over UART-TX line, if the tty and the > underlying platform and UART peripheral supports this operation. > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> > --- > v3: Add details to the commit message. (Greg KH) ... > diff --git a/include/linux/serdev.h b/include/linux/serdev.h > index 66f624fc618c..c065ef1c82f1 100644 > --- a/include/linux/serdev.h > +++ b/include/linux/serdev.h ... > @@ -255,6 +257,10 @@ static inline int serdev_device_set_tiocm(struct serdev_device *serdev, int set, > { > return -ENOTSUPP; > } > +static inline int serdev_device_break_ctl(struct serdev_device *serdev, int break_state) > +{ > + return -EOPNOTSUPP; Is the use of -EOPNOTSUPP intentional here? I see -ENOTSUPP is used elsewhere in this file. > +} > static inline int serdev_device_write(struct serdev_device *sdev, const unsigned char *buf, > size_t count, unsigned long timeout) > { > -- > 2.34.1 >
Hi Simon > > On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote: > > Adds serdev_device_break_ctl() and an implementation for ttyport. > > This function simply calls the break_ctl in tty layer, which can > > assert a break signal over UART-TX line, if the tty and the underlying > > platform and UART peripheral supports this operation. > > > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> > > --- > > v3: Add details to the commit message. (Greg KH) > > ... > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h index > > 66f624fc618c..c065ef1c82f1 100644 > > --- a/include/linux/serdev.h > > +++ b/include/linux/serdev.h > > ... > > > @@ -255,6 +257,10 @@ static inline int serdev_device_set_tiocm(struct > > serdev_device *serdev, int set, { > > return -ENOTSUPP; > > } > > +static inline int serdev_device_break_ctl(struct serdev_device > > +*serdev, int break_state) { > > + return -EOPNOTSUPP; > > Is the use of -EOPNOTSUPP intentional here? > I see -ENOTSUPP is used elsewhere in this file. I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the check patch scripts and by Leon Romanovsky. https://patchwork.kernel.org/project/bluetooth/patch/20230130180504.2029440-2-neeraj.sanjaykale@nxp.com/ ENOTSUPP is not a standard error code and should be avoided in new patches. See: https://lore.kernel.org/netdev/20200510182252.GA411829@lunn.ch/ > > > +} > > static inline int serdev_device_write(struct serdev_device *sdev, const > unsigned char *buf, > > size_t count, unsigned long > > timeout) { > > -- > > 2.34.1 > > Thanks, Neeraj
On Sun, Mar 12, 2023 at 07:01:17AM +0000, Neeraj sanjay kale wrote: > Hi Simon > > > > > On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote: > > > Adds serdev_device_break_ctl() and an implementation for ttyport. > > > This function simply calls the break_ctl in tty layer, which can > > > assert a break signal over UART-TX line, if the tty and the underlying > > > platform and UART peripheral supports this operation. > > > > > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> > > > --- > > > v3: Add details to the commit message. (Greg KH) > > > > ... > > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h index > > > 66f624fc618c..c065ef1c82f1 100644 > > > --- a/include/linux/serdev.h > > > +++ b/include/linux/serdev.h > > > > ... > > > > > @@ -255,6 +257,10 @@ static inline int serdev_device_set_tiocm(struct > > > serdev_device *serdev, int set, { > > > return -ENOTSUPP; > > > } > > > +static inline int serdev_device_break_ctl(struct serdev_device > > > +*serdev, int break_state) { > > > + return -EOPNOTSUPP; > > > > Is the use of -EOPNOTSUPP intentional here? > > I see -ENOTSUPP is used elsewhere in this file. > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the check patch scripts and by Leon Romanovsky. > https://patchwork.kernel.org/project/bluetooth/patch/20230130180504.2029440-2-neeraj.sanjaykale@nxp.com/ > > ENOTSUPP is not a standard error code and should be avoided in new patches. > See: https://lore.kernel.org/netdev/20200510182252.GA411829@lunn.ch/ Thanks. I agree that EOPNOTSUPP is preferable. But my question is if we chose to use it in this case, even if it is inconsistent with similar code in the same file/API. If so, then I have no objections.
Hi Simon > > > > > > On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote: > > > > Adds serdev_device_break_ctl() and an implementation for ttyport. > > > > This function simply calls the break_ctl in tty layer, which can > > > > assert a break signal over UART-TX line, if the tty and the > > > > underlying platform and UART peripheral supports this operation. > > > > > > > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> > > > > --- > > > > v3: Add details to the commit message. (Greg KH) > > > > > > ... > > > > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h index > > > > 66f624fc618c..c065ef1c82f1 100644 > > > > --- a/include/linux/serdev.h > > > > +++ b/include/linux/serdev.h > > > > > > ... > > > > > > > @@ -255,6 +257,10 @@ static inline int > > > > serdev_device_set_tiocm(struct serdev_device *serdev, int set, { > > > > return -ENOTSUPP; > > > > } > > > > +static inline int serdev_device_break_ctl(struct serdev_device > > > > +*serdev, int break_state) { > > > > + return -EOPNOTSUPP; > > > > > > Is the use of -EOPNOTSUPP intentional here? > > > I see -ENOTSUPP is used elsewhere in this file. > > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the check > patch scripts and by Leon Romanovsky. > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > hwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20230130180504.202 > 944 > > 0-2- > neeraj.sanjaykale%40nxp.com%2F&data=05%7C01%7Cneeraj.sanjaykale%40 > > > nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f1%7C686ea1d3bc2b4c6fa92 > cd99c5 > > > c301635%7C0%7C0%7C638142451647332825%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiM > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C > > %7C&sdata=6cF0gipe4kkwYI6txo0vs8vnmF8azCO6gxQ%2F6Tdyd%2Fw%3D > &reserved= > > 0 > > > > ENOTSUPP is not a standard error code and should be avoided in new > patches. > > See: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fnetdev%2F20200510182252.GA411829%40lunn.ch%2F&data > =05%7C > > > 01%7Cneeraj.sanjaykale%40nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f > 1%7C > > > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638142451647332825% > 7CUnknow > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLC > > > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wFgYY6VnZ8BBn6Wme8%2BYj > aJRy98qyPnUy > > XC8iCFCv5k%3D&reserved=0 > > Thanks. > > I agree that EOPNOTSUPP is preferable. > But my question is if we chose to use it in this case, even if it is inconsistent > with similar code in the same file/API. > If so, then I have no objections. No, it was just to satisfy the check patch error and Leon's comment. The driver is happy to check if the serdev returned success or not, and simply print the error code during driver debug. Do you think this should be reverted to ENOTSUPP to maintain consistency? Thanks, Neeraj
On Mon, Mar 13, 2023 at 04:19:59AM +0000, Neeraj sanjay kale wrote: > Hi Simon > > > > > > > > > On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote: > > > > > Adds serdev_device_break_ctl() and an implementation for ttyport. > > > > > This function simply calls the break_ctl in tty layer, which can > > > > > assert a break signal over UART-TX line, if the tty and the > > > > > underlying platform and UART peripheral supports this operation. > > > > > > > > > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> > > > > > --- > > > > > v3: Add details to the commit message. (Greg KH) > > > > > > > > ... > > > > > > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h index > > > > > 66f624fc618c..c065ef1c82f1 100644 > > > > > --- a/include/linux/serdev.h > > > > > +++ b/include/linux/serdev.h > > > > > > > > ... > > > > > > > > > @@ -255,6 +257,10 @@ static inline int > > > > > serdev_device_set_tiocm(struct serdev_device *serdev, int set, { > > > > > return -ENOTSUPP; > > > > > } > > > > > +static inline int serdev_device_break_ctl(struct serdev_device > > > > > +*serdev, int break_state) { > > > > > + return -EOPNOTSUPP; > > > > > > > > Is the use of -EOPNOTSUPP intentional here? > > > > I see -ENOTSUPP is used elsewhere in this file. > > > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the check > > patch scripts and by Leon Romanovsky. > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > > > hwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20230130180504.202 > > 944 > > > 0-2- > > neeraj.sanjaykale%40nxp.com%2F&data=05%7C01%7Cneeraj.sanjaykale%40 > > > > > nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f1%7C686ea1d3bc2b4c6fa92 > > cd99c5 > > > > > c301635%7C0%7C0%7C638142451647332825%7CUnknown%7CTWFpbGZsb3 > > d8eyJWIjoiM > > > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > > %7C%7C > > > %7C&sdata=6cF0gipe4kkwYI6txo0vs8vnmF8azCO6gxQ%2F6Tdyd%2Fw%3D > > &reserved= > > > 0 > > > > > > ENOTSUPP is not a standard error code and should be avoided in new > > patches. > > > See: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > > .kernel.org%2Fnetdev%2F20200510182252.GA411829%40lunn.ch%2F&data > > =05%7C > > > > > 01%7Cneeraj.sanjaykale%40nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f > > 1%7C > > > > > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638142451647332825% > > 7CUnknow > > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > > WwiLC > > > > > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wFgYY6VnZ8BBn6Wme8%2BYj > > aJRy98qyPnUy > > > XC8iCFCv5k%3D&reserved=0 > > > > Thanks. > > > > I agree that EOPNOTSUPP is preferable. > > But my question is if we chose to use it in this case, even if it is inconsistent > > with similar code in the same file/API. > > If so, then I have no objections. > > No, it was just to satisfy the check patch error and Leon's comment. The driver is happy to check if the serdev returned success or not, and simply print the error code during driver debug. > Do you think this should be reverted to ENOTSUPP to maintain consistency? My _opinion_, is that first prize would be converting existing instances of ENOTSUPP in this file to EOPNOTSUPP. And then use EOPNOTSUPP going forward. And that second prize would be for your patch to use ENOTSUPP. Because I think there is a value consistency. But I do see why you have done things the way you have. And I don't necessarily think it is wrong.
Hi Simon, > > > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h > > > > > > index > > > > > > 66f624fc618c..c065ef1c82f1 100644 > > > > > > --- a/include/linux/serdev.h > > > > > > +++ b/include/linux/serdev.h > > > > > > > > > > ... > > > > > > > > > > > @@ -255,6 +257,10 @@ static inline int > > > > > > serdev_device_set_tiocm(struct serdev_device *serdev, int set, { > > > > > > return -ENOTSUPP; > > > > > > } > > > > > > +static inline int serdev_device_break_ctl(struct > > > > > > +serdev_device *serdev, int break_state) { > > > > > > + return -EOPNOTSUPP; > > > > > > > > > > Is the use of -EOPNOTSUPP intentional here? > > > > > I see -ENOTSUPP is used elsewhere in this file. > > > > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the > > > > check > > > patch scripts and by Leon Romanovsky. > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > > patc%2F&data=05%7C01%7Cneeraj.sanjaykale%40nxp.com%7Cd6011072c88 > 94 > > > > > b141a3008db23bb5bc0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C6 > > > > > 38143059832335354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQ > > > > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =k > > > > > gk6w%2Fn2d3rNx%2FXe1rLfN0U%2BeTBJTxztSRUEUW2Noqk%3D&reserved= > 0 > > > > > > > > hwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20230130180504.202 > > > 944 > > > > 0-2- > > > > neeraj.sanjaykale%40nxp.com%2F&data=05%7C01%7Cneeraj.sanjaykale%40 > > > > > > > > nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f1%7C686ea1d3bc2b4c6fa92 > > > cd99c5 > > > > > > > > c301635%7C0%7C0%7C638142451647332825%7CUnknown%7CTWFpbGZsb3 > > > d8eyJWIjoiM > > > > > > > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > > > %7C%7C > > > > %7C&sdata=6cF0gipe4kkwYI6txo0vs8vnmF8azCO6gxQ%2F6Tdyd%2Fw% > 3D > > > &reserved= > > > > 0 > > > > > > > > ENOTSUPP is not a standard error code and should be avoided in new > > > patches. > > > > See: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > > lore%2F&data=05%7C01%7Cneeraj.sanjaykale%40nxp.com%7Cd6011072c88 > 94 > > > > > b141a3008db23bb5bc0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C6 > > > > > 38143059832335354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQ > > > > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =9 > > > > > wojVR7aEgzoeajvy%2FMAkSqAYGBkxrJZtyxlvIpeZ%2Bw%3D&reserved=0 > > > > .kernel.org%2Fnetdev%2F20200510182252.GA411829%40lunn.ch%2F& > data > > > =05%7C > > > > > > > > 01%7Cneeraj.sanjaykale%40nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f > > > 1%7C > > > > > > > > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638142451647332825% > > > 7CUnknow > > > > > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > > > WwiLC > > > > > > > > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wFgYY6VnZ8BBn6Wme8%2BYj > > > aJRy98qyPnUy > > > > XC8iCFCv5k%3D&reserved=0 > > > > > > Thanks. > > > > > > I agree that EOPNOTSUPP is preferable. > > > But my question is if we chose to use it in this case, even if it is > > > inconsistent with similar code in the same file/API. > > > If so, then I have no objections. > > > > No, it was just to satisfy the check patch error and Leon's comment. The > driver is happy to check if the serdev returned success or not, and simply > print the error code during driver debug. > > Do you think this should be reverted to ENOTSUPP to maintain consistency? > > My _opinion_, is that first prize would be converting existing instances of > ENOTSUPP in this file to EOPNOTSUPP. And then use EOPNOTSUPP going > forward. And that second prize would be for your patch to use ENOTSUPP. > Because I think there is a value consistency. > > But I do see why you have done things the way you have. > And I don't necessarily think it is wrong. When you put it that way, how can I say no to a first prize! :D I have replaced all instances of ENOTSUPP with EOPNOTSUPP in these 2 files after making sure none of the functions returning it has a check for ENOTSUPP. It seems most of the instances do not check for a return value anyways. Please check v9 patch for the changes. Thanks Neeraj
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c index 0180e1e4e75d..f2fdd6264e5d 100644 --- a/drivers/tty/serdev/core.c +++ b/drivers/tty/serdev/core.c @@ -405,6 +405,17 @@ int serdev_device_set_tiocm(struct serdev_device *serdev, int set, int clear) } EXPORT_SYMBOL_GPL(serdev_device_set_tiocm); +int serdev_device_break_ctl(struct serdev_device *serdev, int break_state) +{ + struct serdev_controller *ctrl = serdev->ctrl; + + if (!ctrl || !ctrl->ops->break_ctl) + return -EOPNOTSUPP; + + return ctrl->ops->break_ctl(ctrl, break_state); +} +EXPORT_SYMBOL_GPL(serdev_device_break_ctl); + static int serdev_drv_probe(struct device *dev) { const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver); diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c index d367803e2044..9888673744af 100644 --- a/drivers/tty/serdev/serdev-ttyport.c +++ b/drivers/tty/serdev/serdev-ttyport.c @@ -247,6 +247,17 @@ static int ttyport_set_tiocm(struct serdev_controller *ctrl, unsigned int set, u return tty->ops->tiocmset(tty, set, clear); } +static int ttyport_break_ctl(struct serdev_controller *ctrl, unsigned int break_state) +{ + struct serport *serport = serdev_controller_get_drvdata(ctrl); + struct tty_struct *tty = serport->tty; + + if (!tty->ops->break_ctl) + return -EOPNOTSUPP; + + return tty->ops->break_ctl(tty, break_state); +} + static const struct serdev_controller_ops ctrl_ops = { .write_buf = ttyport_write_buf, .write_flush = ttyport_write_flush, @@ -259,6 +270,7 @@ static const struct serdev_controller_ops ctrl_ops = { .wait_until_sent = ttyport_wait_until_sent, .get_tiocm = ttyport_get_tiocm, .set_tiocm = ttyport_set_tiocm, + .break_ctl = ttyport_break_ctl, }; struct device *serdev_tty_port_register(struct tty_port *port, diff --git a/include/linux/serdev.h b/include/linux/serdev.h index 66f624fc618c..c065ef1c82f1 100644 --- a/include/linux/serdev.h +++ b/include/linux/serdev.h @@ -92,6 +92,7 @@ struct serdev_controller_ops { void (*wait_until_sent)(struct serdev_controller *, long); int (*get_tiocm)(struct serdev_controller *); int (*set_tiocm)(struct serdev_controller *, unsigned int, unsigned int); + int (*break_ctl)(struct serdev_controller *ctrl, unsigned int break_state); }; /** @@ -202,6 +203,7 @@ int serdev_device_write_buf(struct serdev_device *, const unsigned char *, size_ void serdev_device_wait_until_sent(struct serdev_device *, long); int serdev_device_get_tiocm(struct serdev_device *); int serdev_device_set_tiocm(struct serdev_device *, int, int); +int serdev_device_break_ctl(struct serdev_device *serdev, int break_state); void serdev_device_write_wakeup(struct serdev_device *); int serdev_device_write(struct serdev_device *, const unsigned char *, size_t, long); void serdev_device_write_flush(struct serdev_device *); @@ -255,6 +257,10 @@ static inline int serdev_device_set_tiocm(struct serdev_device *serdev, int set, { return -ENOTSUPP; } +static inline int serdev_device_break_ctl(struct serdev_device *serdev, int break_state) +{ + return -EOPNOTSUPP; +} static inline int serdev_device_write(struct serdev_device *sdev, const unsigned char *buf, size_t count, unsigned long timeout) {