On Thu, Dec 03, 2020 at 03:08:49PM +0000, Tudor.Ambarus@microchip.com wrote:
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.
Your understanding is correct. But note that we might accidentally pick it up with the Fixes: tag at a later date, so be aware that you might want to make the text in the changelog really obvious that it should not go into a stable kernel, and why not (hint, if you have a Fixes: tag, that's usually a good reason _to_ include it...)
thanks,
greg k-h