On 12/3/20 4:39 PM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Am 2020-12-03 15:34, schrieb Tudor.Ambarus@xxxxxxxxxxxxx: >> On 12/3/20 1:00 AM, Michael Walle wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> This flash part actually has 4 block protection bits. >>> >>> Reported-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx> >>> Cc: stable@xxxxxxxxxxxxxxx # v5.7+ >> >> While the patch is correct according to the datasheet, it was >> not tested, so it's not a candidate for stable. I would update >> the commit message to indicate that the the patch was made >> solely on datasheet info and not tested, I would add the fixes >> tag, and strip cc-ing to stable. > > What is the difference? Any commit with a Fixes tag will also land > in the stable trees. Just that it will cause compile errors for > kernel older than 5.7. > > So if you don't want to have it in stable then you must not add > a Fixes: tag either. > Documentation/process/stable-kernel-rules.rst doesn't say that the Fixes tag is a guarantee that a patch will hit the stable kernels. Since this patch was not tested, it's not a candidate for stable as per the first rule. It's a theoretical fix, because it should indeed fix the locking as per the datasheet. Even for theoretical fixes, I would like to know what commit broke the functionality, and that's why I asked for the Fixes tag. We don't want the patch in stable, so that's why I said that I would indicate in the commit message that it was not tested, and that I would strip the cc to stable. Maybe it's just my understanding. Others may help.
