From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (mailout.nod.at [116.203.167.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07C023793D0 for ; Thu, 7 May 2026 07:50:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.167.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778140256; cv=none; b=MpV/ylywL949CL9sNkA4SbxB4BSosUcqaIZ2tQ47BSPQpxqc5fF/kxnc5+WL6vDrjurvVFffk6AuqSPDexULQ0Acr1Qk4R02CNQybWYmF3gO+l9FTxGGT8vo27Hm2prP8ohQ+K1yBnXItSRvlT3aeh04ptQrZY4Wd6eqrpwlvnA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778140256; c=relaxed/simple; bh=SWxZcOUDQa69EEDVWiAcHl6cT8iOZK+7mjQaXz2Dzxk=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=FA9bnpLIBamRVv7quzU00dEGlZFktsUdAvUUdrUZQ/gvoqvl61Mus9cv2H0es5kKdFsBPREo/i9f0ocxFxjDQ66x8S7Ol/65R9wRIzOJQw+xPSuooyI+DtYNvAPfBpvxMySuF5ytrIlw/oC4sZzMkkjRIYEHogWNTtnbCNrajec= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=116.203.167.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 06E62298580; Thu, 7 May 2026 09:50:52 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bRTtseI6MBTk; Thu, 7 May 2026 09:50:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 68C5E298599; Thu, 7 May 2026 09:50:51 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tBLSlF4l2gkp; Thu, 7 May 2026 09:50:51 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 37FCF298580; Thu, 7 May 2026 09:50:51 +0200 (CEST) Date: Thu, 7 May 2026 09:50:50 +0200 (CEST) From: Richard Weinberger To: chengzhihao1 Cc: "haoyu.lu" , Miquel Raynal , Vignesh Raghavendra , linux-mtd , linux-kernel Message-ID: <874282979.1642.1778140250921.JavaMail.zimbra@nod.at> In-Reply-To: <7c4bf8d4-c561-f5bf-fc7f-3e384fe1a9e6@huawei.com> References: <20260507032308.16485-1-hechushiguitu666@gmail.com> <20260507032308.16485-2-hechushiguitu666@gmail.com> <7c4bf8d4-c561-f5bf-fc7f-3e384fe1a9e6@huawei.com> Subject: Re: [PATCH 2/2] ubi: build: replace simple_strtoul with kstrtoul in bytes_str_to_int() 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF150 (Linux)/8.8.12_GA_3809) Thread-Topic: build: replace simple_strtoul with kstrtoul in bytes_str_to_int() Thread-Index: KPRiefLPJDGCgZTMYyyjVKrrR9sr+g== ----- Urspr=C3=BCngliche Mail ----- > Von: "chengzhihao1" > An: "haoyu.lu" , "Miquel Raynal" , "richard" , > "Vignesh Raghavendra" > CC: "linux-mtd" , "linux-kernel" > Gesendet: Donnerstag, 7. Mai 2026 09:45:24 > Betreff: Re: [PATCH 2/2] ubi: build: replace simple_strtoul with kstrtoul= in bytes_str_to_int() > =E5=9C=A8 2026/5/7 11:23, haoyu.lu =E5=86=99=E9=81=93: >> From: Haoyu Lu >>=20 >> Replace the deprecated simple_strtoul() with kstrtoul() in the >> bytes_str_to_int() helper function. Since kstrtoul() rejects trailing >> non-numeric characters (such as the G/M/K suffixes), the numeric prefix >> is first extracted with strspn() and then parsed separately before >> handling the suffix. >>=20 >> This provides proper error handling through the kstrto* family while >> preserving the existing suffix semantics for byte count parameters. >>=20 >> Note: the original simple_strtoul() with base=3D0 accepted hexadecimal >> (0x prefix) and octal (0 prefix) formats, while kstrtoul() with base=3D1= 0 >> only supports decimal. This is not a practical concern since MTD byte >> count parameters are always specified as decimal values in boot >> parameters. > The ubi could be loaded by module insertion, many vendors set param > 'vid_hdr_offs' to save space. We cannot make the assumption that all > users use the decimal system. That's a good point! In general I'm not fond of such changes. They change code for the sake of changing code without fixing actual issues. I'll happily accept patches that point out real issues with the current usage of various string functions, though. Thanks, //richard