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@microchip.com:
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@microchip.com Cc: stable@vger.kernel.org # 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.