The @data buffer is 5 bytes, not 4, it has been extended for the need of
devices with an extra ID bytes.

Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/mtd/spinand.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 927c10d7876958276a841a9f1278a74deeb89944..1c741145e49717169152854718f784e0e519ea92 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -287,7 +287,7 @@ struct spinand_device;
 
 /**
  * struct spinand_id - SPI NAND id structure
- * @data: buffer containing the id bytes. Currently 4 bytes large, but can
+ * @data: buffer containing the id bytes. Currently 5 bytes large, but can
  *	  be extended if required
  * @len: ID length
  */

-- 
2.51.0

On 10/31/25 6:26 PM, Miquel Raynal wrote:
> The @data buffer is 5 bytes, not 4, it has been extended for the need of
> devices with an extra ID bytes.
> 
> Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs")

no fixes tag for documentation.

with that:
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

(commit msg can be updated to smth like "update kernel doc comment" too)

> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  include/linux/mtd/spinand.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
> index 927c10d7876958276a841a9f1278a74deeb89944..1c741145e49717169152854718f784e0e519ea92 100644
> --- a/include/linux/mtd/spinand.h
> +++ b/include/linux/mtd/spinand.h
> @@ -287,7 +287,7 @@ struct spinand_device;
>  
>  /**
>   * struct spinand_id - SPI NAND id structure
> - * @data: buffer containing the id bytes. Currently 4 bytes large, but can
> + * @data: buffer containing the id bytes. Currently 5 bytes large, but can
>   *	  be extended if required
>   * @len: ID length
>   */
>

On 05/11/2025 at 16:57:39 +01, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> On 10/31/25 6:26 PM, Miquel Raynal wrote:
>> The @data buffer is 5 bytes, not 4, it has been extended for the need of
>> devices with an extra ID bytes.
>> 
>> Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs")
>
> no fixes tag for documentation.
>
> with that:
> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>
> (commit msg can be updated to smth like "update kernel doc comment"
> too)

I partially disagree. Tell me if I'm wrong, but may I guess that you
have backports in mind? As opposed to backporting comment fixes which
might not make much sense indeed, _fixing_ a comment makes sense. We
know that stable maintainers, even though they ask people to Cc stable
for backports, they automatically pick with the help of AI almost any
commit with a Fixes tag. I believe it is wrong to not mark such commit
and even change the title (because "fix" in the title may also lead to
an automatic backport) to circumvent their tooling. The tooling must
adapt, not the accuracy of the commits. Plus, backporting this kind of
commit is harmless, so I wouldn't care too much?

Thanks,
Miquèl

On 11/19/25 7:18 PM, Miquel Raynal wrote:
> On 05/11/2025 at 16:57:39 +01, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> 
>> On 10/31/25 6:26 PM, Miquel Raynal wrote:
>>> The @data buffer is 5 bytes, not 4, it has been extended for the need of
>>> devices with an extra ID bytes.
>>>
>>> Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs")
>>
>> no fixes tag for documentation.
>>
>> with that:
>> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>
>> (commit msg can be updated to smth like "update kernel doc comment"
>> too)
> 
> I partially disagree. Tell me if I'm wrong, but may I guess that you
> have backports in mind? As opposed to backporting comment fixes which


yes, I was thinking on stable rules, where trivial fixes like this,
are not accepted. But you didn't cc stable, so I think that's fine.

> might not make much sense indeed, _fixing_ a comment makes sense. We
> know that stable maintainers, even though they ask people to Cc stable
> for backports, they automatically pick with the help of AI almost any
> commit with a Fixes tag. I believe it is wrong to not mark such commit
> and even change the title (because "fix" in the title may also lead to
> an automatic backport) to circumvent their tooling. The tooling must
> adapt, not the accuracy of the commits. Plus, backporting this kind of
> commit is harmless, so I wouldn't care too much?

okay