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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F35AC11D02 for ; Thu, 20 Feb 2020 07:49:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 050AC208C4 for ; Thu, 20 Feb 2020 07:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726885AbgBTHtL (ORCPT ); Thu, 20 Feb 2020 02:49:11 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:42377 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726501AbgBTHtK (ORCPT ); Thu, 20 Feb 2020 02:49:10 -0500 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j4gZy-00076I-W3; Thu, 20 Feb 2020 08:49:03 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1j4gZx-0007Au-66; Thu, 20 Feb 2020 08:49:01 +0100 Date: Thu, 20 Feb 2020 08:49:01 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Andy Shevchenko Cc: Jacek Anaszewski , Pavel Machek , Dan Murphy , Greg Kroah-Hartman , Jiri Slaby , Linux LED Subsystem , Linux Kernel Mailing List , Sascha Hauer , "open list:SERIAL DRIVERS" Subject: Re: [PATCH v6 1/4] lib: new helper kstrtodev_t() Message-ID: <20200220074901.ohcrisjgd26555ya@pengutronix.de> References: <20200213091600.554-1-uwe@kleine-koenig.org> <20200213091600.554-2-uwe@kleine-koenig.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-serial@vger.kernel.org Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote: > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König wrote: > > > > This function is in the same spirit as the other kstrto* functions and > > uses the same calling convention. It expects the input string to be in > > the format %u:%u and implements stricter parsing than sscanf as it > > returns an error on trailing data (other than the usual \n). > > Can we first split the kstrotox* (and simple_strto*) to the separate > header first? I don't feel strong here what is right. But I hesitate to create another pre-condition for this patch set. > On top of that, why kstrtodev_t is so important? How many users are > already in the kernel to get an advantage out of it? Does it need to be important? It matches the other kstrto* functions and so it seemed more natural to me to put it near the other functions. I'm not aware of other potential users and surprised you seem to suggest this as a requirement. > What to do with all other possible variants ("%d:%d", "%dx%d" and its > %u variant, etc)? I don't see how %d:%d is relevant, major and minor cannot be negative can they? I never saw 'x' as separator between major and minor. I considered shortly parsing %u, but given that (I think) this is an internal representation only I chose to not make it more visible than it already is. > Why simple_strto*() can't be used? I didn't really consider it, but looking in more detail I don't like it much. Without having tried it I think simple_strtoull accepts "1000000000000000000000000000000000000000000" returning some arbitrary value without an error indication. And given that I was asked for strict parsing (i.e. not accepting 2:4:something) I'd say using simple_strto* is a step backwards. Also simple_strtoul() has "This function is obsolete. Please use kstrtoul instead." in its docstring which seems to apply to the other simple_strto*() functions, too. > > #include > > #include > > #include > > > +#include > > Perhaps preserve order? Can do. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |