From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EB6D3C5833 for ; Thu, 4 Jun 2026 06:59:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780556353; cv=none; b=KVzqQO9nwcyd+75psawjeisHzpZI2DfW6Xgapc/WgqtGRio9MRT31yY/W+2WOiSjVxKRqmqpk72BLY5h21fFmY02fYeWAnhlT+U9+qQOmBBl3q8KLMaY0N4V7QH8l/Lp9UBJf7CTrGSPMjHpwayihb+h6S0Mswyk9mjf1LV0/SE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780556353; c=relaxed/simple; bh=Dsw+7sUNwHxphbFtJ7BkSK49t92q7EDhEiGm9kaNeo0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u9C6/uU6Od32+q4+xY4MkvH4zUf8Zuk03cvpQuySoPNwKUhUEeiXi9RkRe7XT7E6x0U9LKamTH0cK5zPNv4KSA6DKjTBIunBAdB27HsJUnWvhZ7x7g2Nj6gfjntlcKjZTECnne9daRyhjGP2eg6I7FXI+4vHgqpiMC85pDZ8xXk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=JPgoZ8Ps; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="JPgoZ8Ps" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-45ef616daf6so319173f8f.3 for ; Wed, 03 Jun 2026 23:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780556350; x=1781161150; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5fDg4RbpG/7cnvSEIJnEMxEzvLB+wnNfQDAIMzcoodI=; b=JPgoZ8PsyhmQcQ88So7h/QYYAT4NeWmKz6CCCybCzhLtLBv4Ao2yA/ZRSz6GV+ZA7N DuBvVBV1ArBTWS75NO6IfpjAfA3fO2D02peZ57X0/qKcd4crplghFMk8If6tmSFaX6B1 Vdmf67LJCBzcV63vPTGAUCy7shs2UbvhESfOFKVd2bidzZVhLQGPj1qyemF4E0f7fle5 Naxvp2cpYHKMrEMOFY2d+IDPCReVMAaHZQCSkyBjNn0D/R1hWrZmDSfLSoLG0fbsHtdt 2/5ZFV6eQEYBDvSyggoo7RJKmkd9H5w0wk376u0uk9HEtHVQt+USr6OLDFlv9qbfOB7E isug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780556350; x=1781161150; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5fDg4RbpG/7cnvSEIJnEMxEzvLB+wnNfQDAIMzcoodI=; b=QJ/GH0NU1xJZXM4mge0eJf3+FX0cSI1EX7qyaG0F2KkSG+PPraTM9S5/rVDAKB60zR KCsLXWuXgQQHiRcD0CU4LTEucFiPSNBdT0FSsXmgLSaANx/tSx36GrMdGON1KBU3LTRe Qx3ZAI3W1aemLI/NwewYoIV1En7AVhlCvZWtrOhdTyJqDwpUGv405reEkNJh2pFPNB23 Y80Y+2LOSrncUqwGRAj9+7XDZlbAL5QL0cX6KQDIaezv017jyE8aLuyOphqr4XE0+ICs cYUeJF7tksvn8tfRc2Cf5hDMCpVAjWczhKfqIUh2H+PmBcPDBLklvJMgEAUJiwU2vfnt pf8A== X-Forwarded-Encrypted: i=1; AFNElJ/NgEsVn0q6XjrMPW+tq9BIxIGPIL1giql+PIvxuqueCa8GAmR8bsqD+6V/VPCuW9scAVXtbgCRf0VhpvM=@vger.kernel.org X-Gm-Message-State: AOJu0YxMDVnRg8QBUUb3j6tsUIj33DFlleqfxaUAw3LjQf0s2l2DjRzZ ibWgskAv6Gsj2M8Hf0o63iV5HPBnvIsbHsKnqwiVXu7sc95qdIF5WSl/Eqj5vWryiUA= X-Gm-Gg: Acq92OGH8l7+VUgXTKFTb6JZzhjJt2DL7do14uNui6JOM+bYgwmqB8XvwKyHVzQyxoM JfTHJpsqG4diK82ZO0CX66zM6TlSWcBpJwj504wbp04TIsLplEMCahvFbIjKUs7QF40qDuZtOTf dn2Z/itEAM4EPcuciOHMKabaWZawL5OhTmJNm1O9Yy0Sfk+1nSH5XPCGGkMY83ypZXd234v/xAs mTrcR0ZfLi7oPG6Qde3aZIPh/foiRCzNqzns5tT/L7b+JnB+dBAyrE1ZMHhmDBFG+xU+ZX2ePin PZW0yeHG9kjrGRYLrm0+6WNceFjaADQ2vG6JKoqyGLSiJlEccOIj/Qdtp1OeNeiQ+q7bsUxmS0Z FA1OhudCrUuLsZmj2JCq7QoPI946jEQ+Hr5sGGoMsF79QeVroYWg42HqWD7dq9iXFJ8U9gSNde0 qVB76yD4z//zxcvieSxJhDRa/ghAEP3QcpbS2p8oq4p4wcCvs= X-Received: by 2002:a5d:6e84:0:b0:460:1695:89c9 with SMTP id ffacd0b85a97d-460218433b5mr6558176f8f.24.1780556349929; Wed, 03 Jun 2026 23:59:09 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2f67c6sm14160681f8f.16.2026.06.03.23.59.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 23:59:09 -0700 (PDT) Date: Thu, 4 Jun 2026 08:59:07 +0200 From: Petr Mladek To: Andy Shevchenko Cc: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>, Dmitry Antipov , linux-kernel@vger.kernel.org, Andrew Morton , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , rodrigo.alencar@analog.com, dlechner@baylibre.com, jic23@kernel.org Subject: Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible Message-ID: References: <20260602203706.103449-1-andriy.shevchenko@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed 2026-06-03 16:53:49, Andy Shevchenko wrote: > On Wed, Jun 03, 2026 at 12:51:09PM +0100, Rodrigo Alencar wrote: > > On 26/06/03 01:23PM, Petr Mladek wrote: > > > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote: > > > > Currently every new wrapper on _parse_integer_limit() will need a new name > > > > to share with users while keeping some optional arguments to be initialised > > > > explicitly. Since there is an attempt to expand this more, I decided to > > > > suggest this mini series to avoid namespace pollution and unneeded churn in > > > > the future. > > > > > > > > To expand this API more, the possible future change may be: > > > > > > > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res, > > > > - size_t max_chars); > > > > + size_t max_chars, $new_opt_arg); > > > > > > > > #define _parse_integer0(s, base, res, ...) \ > > > > - _parse_integer_limit(s, base, res, INT_MAX); > > > > + _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default); > > > > > > > > #define _parse_integer1(s, base, res, max_chars, ...) \ > > > > - _parse_integer_limit(s, base, res, max_chars); > > > > + _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default); > > > > > > > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...) \ > > > > + _parse_integer_limit(s, base, res, max_chars, new_opt_arg); > > > > > > I guess that this is about _parse_integer_limit_init() from > > > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/ > > > > > > I personally find > > > > > > _parse_integer(*s, base. *res) > > > _parse_integer_limit(*s, base, *res, max_chars) > > > _parse_integer_limit_init(*s, base, init, *res, max_chars) > > > > What could also be done is having a _parse_integer_ext() that would > > contain all the necessary arguments (one that should be indicated > > not to be used) and define all the other variations as static inline > > functions. I suppose that combines both ideas, being a pattern that > > is also used elsewhere: > > > > devm_regulator_get() > > devm_regulator_get_enable() > > devm_regulator_get_enable_optional() > > devm_regulator_get*() are public APIs and that split might make sense. The > _parse_integer() is internal to printf() implementation and wrappers around it, > so I don't think we should really be so picky. TL;DR: I think my approach is > good enough and makes not much of turbulence here, perhaps a comment would be > nice to have to explain the list of optional arguments. > > > > a bit more self-explanatory than > > > > > > _parse_integer(*s, base. *res) > > > _parse_integer(*s, base, *res, max_chars) > > > _parse_integer(*s, base, *res, max_chars, init) > > > > > > especially when the meaning of the arguments need not be obvious > > > when the function is used in the code. > > > > > > Also the macro magic increases the complexity of the code. > > > > > > On the other hand, I do not have strong opinion. It is not a big deal. > > > I am not going to block it. > > Would you give your tag in case Rodrigo wants to incorporate these into his > series and go via IIO tree? (I think that these two makes sense to put into > immutable branch/tag and share with the users). Feel free to use for both patches: Acked-by: Petr Mladek Best Regards, Petr