From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 8847F342C8E for ; Sat, 21 Feb 2026 09:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771666809; cv=none; b=hQkkgg73QNHSj4MHUL2ntC4cw8wJjANZ1JJW/L3QNtD1NYsIS6PfWN+Jmq01Wb7XkOn8hbCeDj+wXFnCxbGpwmwL8Q3X9VY80MphbPf3YutaGUm9cZR9B87TKOK1/5mm7MsRl3VF5sU0dH3+Fl9Pw1wpChu6ANMSzHbnkALR7Bc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771666809; c=relaxed/simple; bh=kW2ZR8JhmkoxTITSUxpb+zzCswZPVMvQ2S4l4qYWBeA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=utx7aOU/CapFDBkNfn9J12ogH3p7uJRdC490ZSkKtomL49gcGY4TM5RH3ww1TO/Jwg3mJlJcyadowPgQCBRJHQmAEHkxW1LllP5P8ZPDI6uu2sy9KDIfc7b2riZh3VEL0wZWlZUsbRZAXvSvIYEkrA+NqHSFvd+DztOYY6YKewM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=d1oWoMDE; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d1oWoMDE" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48371119eacso28797165e9.2 for ; Sat, 21 Feb 2026 01:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771666807; x=1772271607; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6OTrcGA+pe/I4LHNfKbWhQqpu2uqCStywvB3RV+xvsk=; b=d1oWoMDELyLwZhnbBDb3iHURN8DmKtADRczY5cEMCodDOUKJKbJwjGOKZ6rdq4Wm7X gPXLCgoln8MUPSX76Gad82+OZiX4xQooVR+pSgwK4gCDsi5Vlrknjf00cuRDXLW4ZI5R hRW1D0Lm1/GdxWld8YHrnDm1SS/oCLVQvblU6oP2vqLv+IukMC1kLh5M+VdQYKlUGgHP 6x5EnveEHFoYh/Z4qUEXwoaIbXBEoXO4TOAqRPtcqjqO3jK2xy0VhW/oXxYe2lqQLCFm AAlM1ExnkhX7UKdnMv72y9Vz1y4DycopBqJoCAijSaDh1DPXlfMOFh8o1gKjXH/dwxuw 00qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771666807; x=1772271607; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6OTrcGA+pe/I4LHNfKbWhQqpu2uqCStywvB3RV+xvsk=; b=Xn7d4mRGJgLP5R9w3jDjQXsRfQxu2KmQXDOZ3vuNlbUaZc0kZP8k6675vpEN4xlz1Z CXwuw6ewUYZqIlzY0Ue9BtN6zdCbeHKuuFSSJ4DNGvF2oIyaRRhov/Pzjqq3jFGGRBkJ fUOTo56M15xzBqADmd4Hbjvn/RuDicH0rAg3uRiiLZHNG7XzDSiajutxqDfnZe798Qb8 8BtrsGNY/EKxkpaPbRWL63QC10GZC+OyqD2nWaio/0MBlylDdK5Mq9PJckjK3QF/j2xE WRB4i9HNx/8mSSMfOUBr9ppfFJObPVz9vOhSek+k8MfUz5/yEgYAGicoXkVZwPn3lI46 Xz4w== X-Forwarded-Encrypted: i=1; AJvYcCUMFfx0kswzjVv8NdCNNrnck+YzECcrQZI8nqRengZ4mN9TkVK3tCYTnQ2dYGIM0IIywR/H7t8rm973S/8=@vger.kernel.org X-Gm-Message-State: AOJu0YzOOPT30sSM6vORAMWnCCxstRLsQcMUrxwCcCUp5IqmvVdGXmKU wYY1t1GxozGuVMjohFMxXtNGxX4SWOOAbci+zA2uG3fKeLRMYn/rSOtI X-Gm-Gg: AZuq6aJ+3I+TAR/6XAsJXRwCE1jDKkvANfpKqHtES4RNyTbrxrXF4Dn6yoDP1Tt6xmh GTgYsGeUZvS4dm/os1dYDWH+MjZv8k0BQ75hLNS1wFXafzq4zF63AdOqaTUlP2STgsu6dHKnPCu NPTD//4XSMpbLvyKsfQGRHNaSHrnhMyRifaEx6DsPyHRvEJ17xbzgTPdwx8vaS+nji7QTPyZEAJ cKrgysVNnhz7aSCydzWu0pmvPeLqDy0NGNuxbPsqLBw3EzhMPQc61fxkKZPMH0+EgfJ3/7+8ns8 IRby4TwM2E3w8OokqpnYDmhsqhVEmYWN7ZGPhFpMlARku3w5ci+1LhQOvQ4wBCVwEXqC0FBY2FX 6py7VQPOfCLa9bNfHOiQLCaXUnlFz98Di0qDUFRz/86byll/MF1wLvH7tlyK78meVz0fa3RYD53 NGULF61RtQWU0hpWKum9zsdSztcalIe0KL1zXen6u74kWYvJRMzzQhpC5cOIKcU0FTjE/eQPp2F 3DhwQPa X-Received: by 2002:a05:600c:5020:b0:47e:e2ec:995b with SMTP id 5b1f17b1804b1-483a95fb29cmr44815955e9.9.1771666806876; Sat, 21 Feb 2026 01:40:06 -0800 (PST) Received: from jernej-laptop.localnet (86-58-126-118.dynamic.telemach.net. [86.58.126.118]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31efe02sm135100995e9.10.2026.02.21.01.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Feb 2026 01:40:06 -0800 (PST) From: Jernej =?UTF-8?B?xaBrcmFiZWM=?= To: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Chen-Yu Tsai , Samuel Holland , Richard Genoud Cc: Wentao Liang , Maxime Ripard , Thomas Petazzoni , linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Richard Genoud Subject: Re: [PATCH 3/6] mtd: rawnand: sunxi: do not count BBM bytes twice Date: Sat, 21 Feb 2026 10:21:55 +0100 Message-ID: <1947198.tdWV9SEqCh@jernej-laptop> In-Reply-To: <20260220161011.999642-4-richard.genoud@bootlin.com> References: <20260220161011.999642-1-richard.genoud@bootlin.com> <20260220161011.999642-4-richard.genoud@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dne petek, 20. februar 2026 ob 17:10:08 Srednjeevropski standardni =C4=8Das= je Richard Genoud napisal(a): > BBM is part of USER_DATA section, so we should remove it twice >=20 > This was working ok because we are on the safe size, advertising that > there was 2 bytes less available than reality. Missing "in" before "reality". >=20 > But we can't change old platforms, since it may lead to a different ECC > strength, so, introduce a legacy flag for old platforms, and switch the > new platforms to the correct count. There aren't any users of H6/H616 driver, right? If it would be, ECC streng= th can't be changed, since it can impact systems, which already use it. Best regards, Jernej >=20 > Signed-off-by: Richard Genoud > --- > drivers/mtd/nand/raw/sunxi_nand.c | 23 ++++++++++++++++++++--- > 1 file changed, 20 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sun= xi_nand.c > index 9c6e0625e34f..99d305bbda53 100644 > --- a/drivers/mtd/nand/raw/sunxi_nand.c > +++ b/drivers/mtd/nand/raw/sunxi_nand.c > @@ -281,6 +281,8 @@ static inline struct sunxi_nand_chip *to_sunxi_nand(s= truct nand_chip *nand) > * @has_ecc_block_512: If the ECC can handle 512B or only 1024B chuncks > * @has_ecc_clk: If the controller needs an ECC clock. > * @has_mbus_clk: If the controller needs a mbus clock. > + * @legacy_max_strength:If the maximize strength function was off by 2 b= ytes > + * NB: this should not be used in new controllers > * @reg_io_data: I/O data register > * @reg_ecc_err_cnt: ECC error counter register > * @reg_user_data: User data register > @@ -310,6 +312,7 @@ struct sunxi_nfc_caps { > bool has_ecc_block_512; > bool has_ecc_clk; > bool has_mbus_clk; > + bool legacy_max_strength; > unsigned int reg_io_data; > unsigned int reg_ecc_err_cnt; > unsigned int reg_user_data; > @@ -1811,10 +1814,22 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nan= d_chip *nand, > ecc->size =3D 1024; > nsectors =3D mtd->writesize / ecc->size; > =20 > - /* Reserve 2 bytes for the BBM */ > - bytes =3D (mtd->oobsize - 2) / nsectors; > + /* > + * The 2 BBM bytes should not be removed from the grand total, > + * because they are part of the USER_DATA_SZ. > + * But we can't modify that for older platform since it may > + * result in a stronger ECC at the end, and break the > + * compatibility. > + */ > + if (nfc->caps->legacy_max_strength) > + bytes =3D (mtd->oobsize - 2) / nsectors; > + else > + bytes =3D mtd->oobsize / nsectors; > =20 > - /* 4 non-ECC bytes are added before each ECC bytes section */ > + /* > + * USER_DATA_SZ non-ECC bytes are added before each ECC bytes > + * section, they contain the 2 BBM bytes > + */ > bytes -=3D USER_DATA_SZ; > =20 > /* and bytes has to be even. */ > @@ -2379,6 +2394,7 @@ static const u8 sunxi_user_data_len_h6[] =3D { > =20 > static const struct sunxi_nfc_caps sunxi_nfc_a10_caps =3D { > .has_ecc_block_512 =3D true, > + .legacy_max_strength =3D true, > .reg_io_data =3D NFC_REG_A10_IO_DATA, > .reg_ecc_err_cnt =3D NFC_REG_A10_ECC_ERR_CNT, > .reg_user_data =3D NFC_REG_A10_USER_DATA, > @@ -2400,6 +2416,7 @@ static const struct sunxi_nfc_caps sunxi_nfc_a10_ca= ps =3D { > static const struct sunxi_nfc_caps sunxi_nfc_a23_caps =3D { > .has_mdma =3D true, > .has_ecc_block_512 =3D true, > + .legacy_max_strength =3D true, > .reg_io_data =3D NFC_REG_A23_IO_DATA, > .reg_ecc_err_cnt =3D NFC_REG_A10_ECC_ERR_CNT, > .reg_user_data =3D NFC_REG_A10_USER_DATA, >=20