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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 D0936EB64DA for ; Thu, 15 Jun 2023 15:00:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UobaE0WW0ahkY7RNYWPz2j7/50cmU7udyjuIgVcEiDc=; b=IEfe6HFPDMiT+q 2szZ2yZg09WlPbC1ZLvCG3TonfIOY5J8AfUuMcDKOs7EN+MdST+vRmJyVjncJUqqlead9XLosp+Eb hzFJrQunkkLdcGjIyCSiY2KtEBHwIT744cGeWgO0H7vU2uhzB/fr/znsB+Pto6ds0xMMqDYzoti6h uN17J1RRWA3EjRgBDvK0o8RzU6nqjmM22kYn5W/dh5eCClJ8P5m+FLln2uLvgGtUNBrNbj14gpEUL RVeTCkwlQd2bTTxrR2utd/VMMtN+2KRsTb2LVc3LdIEnsJYf9IeLhEnMcv++TY1ws7t4zcbk2KHbS SYlNUQSpCuipcB8RMisg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q9oSb-00FEvr-2V; Thu, 15 Jun 2023 15:00:29 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q9oSX-00FEt0-0k for linux-arm-kernel@lists.infradead.org; Thu, 15 Jun 2023 15:00:26 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ADA4662065; Thu, 15 Jun 2023 15:00:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99B98C433C0; Thu, 15 Jun 2023 15:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1686841224; bh=EoG092+beaSnQr2vJ3NUrwGrGf3QWovGqmmxwzEvM6Q=; h=Date:From:To:List-Id:Cc:Subject:References:In-Reply-To:From; b=q/s8r0Z6Uab26/N0tGr4mIo+AZMXoMHdWxVQUC5m/3cvbjgrfqSHA+K9t8rpKYRNB aZLO38wkT39hYSVahv0dNLm0+PBojevl3CSsYj/FddvoOay8K6J/kcRRy9rEOCsmMb 4EmPUVSQdxDbNieNrB4ilwF3/wSwVPLRu85pE5xY= Date: Thu, 15 Jun 2023 17:00:21 +0200 From: Greg Kroah-Hartman To: Arnd Bergmann Cc: Jacky Huang , Rob Herring , krzysztof.kozlowski+dt@linaro.org, Lee Jones , Michael Turquette , Stephen Boyd , Philipp Zabel , Jiri Slaby , Tomer Maimon , Catalin Marinas , Will Deacon , devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org, soc@kernel.org, schung@nuvoton.com, mjchen@nuvoton.com, Jacky Huang Subject: Re: [PATCH v14 1/1] tty: serial: Add Nuvoton ma35d1 serial driver support Message-ID: <2023061500-tipper-tightwad-8843@gregkh> References: <20230612025355.547871-1-ychuang570808@gmail.com> <20230612025355.547871-2-ychuang570808@gmail.com> <2023061338-lunchbox-snorkel-e6a9@gregkh> <2023061356-matchbook-footwear-d142@gregkh> <35e768ad-7f15-48a4-9c38-09570026cf71@app.fastmail.com> <2023061555-enlighten-worshiper-c92d@gregkh> <502240f7-2cac-4fe6-9e27-f9861db3666d@app.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <502240f7-2cac-4fe6-9e27-f9861db3666d@app.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230615_080025_365199_046E9917 X-CRM114-Status: GOOD ( 34.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 15, 2023 at 04:01:55PM +0200, Arnd Bergmann wrote: > On Thu, Jun 15, 2023, at 12:19, Greg Kroah-Hartman wrote: > > On Tue, Jun 13, 2023 at 05:44:23PM +0200, Arnd Bergmann wrote: > >> On Tue, Jun 13, 2023, at 16:49, Greg KH wrote: > >> I don't see how Jacky can come up with a patch to do this correctly > >> without more specific guidance to what exactly you are looking for, > >> after the last 123 people that added support for a new port got > >> that merged. > > > > I keep complaining about this, when I notice it. Just use the "default" > > port type in the serial driver and don't add a new type here and it > > should just work, right? > > > >> I checked debian codesearch and found only three obscure packages that > >> accidentally include this header instead of including linux/serial.h, > >> a couple of lists of all kernel headers, and none that include it on > >> purpose. I agree that this header should really not exist in uapi, > >> but the question is what exactly to do about it. > >> > >> Possible changes would be: > >> > >> - add a special value PORT_* constant other than PORT_UNKNOWN that > >> can be used by serial drivers instead of a unique value, and > >> ensure that the serial core can handle drivers using it. > > > > Why do we need a special constant? > > The "default" value is 0, which translates to PORT_UNKNOWN, and the > serial core code prevents this from working. I think Jacky tried > to use this the last one or two times you commented on it, and > it did not work. Ah, thanks, that makes sense. > Setting it to a plain '1' as Jacky suggested in his reply is the > same as PORT_8250, which may or may not be a good choice here. Odds are it would be fine :) > Since the number is exported to userspace in serial_struct, > it might be better to pick a new constant such as > > #define PORT_SERIAL_GENERIC (-1) > > in order to be less ambiguous. It's a signed integer, so -1 > would work here this would clearly be a special value, or > another option might be to use 255 as something that is > slightly less special but still recognizable as something > that may have a special meaning. A new constant would be good, 255 is nice, and then we can move everyone to use it unless they can specifically show a reason why it will not work for them. I think originally this was used to do device-specific ioctls, right? That shouldn't be happening anymore, hopefully... thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel