This flash part actually has 4 block protection bits.
Reported-by: Tudor Ambarus tudor.ambarus@microchip.com Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Michael Walle michael@walle.cc --- I didn't add the Fixes: tag because we depend on the 4bit BP support which was introduced in 5.7.
changes since v6: - new patch
drivers/mtd/spi-nor/sst.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c index e0af6d25d573..0ab07624fb73 100644 --- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = { SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) }, - { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) }, + { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, + SECT_4K | SPI_NOR_4BIT_BP) }, { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) }, { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2,
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.
Signed-off-by: Michael Walle michael@walle.cc
With the above addressed:
Reviewed-by: Tudor Ambarus tudor.ambarus@microchip.com
I didn't add the Fixes: tag because we depend on the 4bit BP support which was introduced in 5.7.
changes since v6:
- new patch
drivers/mtd/spi-nor/sst.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c index e0af6d25d573..0ab07624fb73 100644 --- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = { SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128,SECT_4K | SPI_NOR_4BIT_BP) }, { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) }, { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2,-- 2.20.1
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.
-michael
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.
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
On 12/3/20 1:00 AM, Michael Walle wrote:
--- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = { SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128,SECT_4K | SPI_NOR_4BIT_BP) },
And I would put 1/7 after 4/7, so that I can set the locking flags in some order: SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP. We first indicate that the flash supports locking, and then what kind of locking, BP3, and not the other way around.
anyway, just cosmetics
Am 2020-12-03 15:40, schrieb Tudor.Ambarus@microchip.com:
On 12/3/20 1:00 AM, Michael Walle wrote:
--- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = { SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128,SECT_4K | SPI_NOR_4BIT_BP) },And I would put 1/7 after 4/7, so that I can set the locking flags in some order: SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP. We first indicate that the flash supports locking, and then what kind of locking, BP3, and not the other way around.
If that patch shouldn't make it into stable, then yes. otherwise, I've put these patches first to not cause merge conflicts.
-michael
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Michael Walle -
Tudor.Ambarus＠microchip.com