[PATCH 1/2] spi: intel: Add default partition and name to the second chip

[PATCH 1/2] spi: intel: Add default partition and name to the second chip

[Mika Westerberg]

This should make it easier to identify the second chip and also allows
using "mtdparts=" and the like with this chip too.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index 3654ae35d2db..467d39bf00b4 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -1346,6 +1346,7 @@ static int intel_spi_read_desc(struct intel_spi *ispi)
 static int intel_spi_populate_chip(struct intel_spi *ispi)
 {
 	struct flash_platform_data *pdata;
+	struct mtd_partition *parts;
 	struct spi_board_info chip;
 	int ret;
 
@@ -1376,7 +1377,23 @@ static int intel_spi_populate_chip(struct intel_spi *ispi)
 	if (ispi->host->num_chipselect < 2)
 		return 0;
 
-	chip.platform_data = NULL;
+	pdata = devm_kzalloc(ispi->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	pdata->name = devm_kasprintf(ispi->dev, GFP_KERNEL, "%s-chip1",
+				     dev_name(ispi->dev));
+	pdata->nr_parts = 1;
+	parts = devm_kcalloc(ispi->dev, pdata->nr_parts, sizeof(*parts),
+			     GFP_KERNEL);
+	if (!parts)
+		return -ENOMEM;
+
+	parts[0].size = MTDPART_SIZ_FULL;
+	parts[0].name = "BIOS1";
+	pdata->parts = parts;
+
+	chip.platform_data = pdata;
 	chip.chip_select = 1;
 
 	if (!spi_new_device(ispi->host, &chip))
-- 
2.43.0

[PATCH 2/2] spi: intel: Keep the BIOS partition inside the first chip

[Mika Westerberg]

If there are two flash chips connected flash regions can refer to the
second chip too. In this case we may see the following warning:

  mtd: partition "BIOS" extends beyond the end of device "0000:00:1f.5" --
  	size truncated to 0x400000

For this reason, check the BIOS partition size against the chip size and
make sure it stays within the that.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index 467d39bf00b4..3e5dcf2b3c8a 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -1254,6 +1254,13 @@ static void intel_spi_fill_partition(struct intel_spi *ispi,
 		if (end > part->size)
 			part->size = end;
 	}
+
+	/*
+	 * Regions can refer to the second chip too so in this case we
+	 * just make the BIOS partition to occupy the whole chip.
+	 */
+	if (ispi->chip0_size && part->size > ispi->chip0_size)
+		part->size = MTDPART_SIZ_FULL;
 }
 
 static int intel_spi_read_desc(struct intel_spi *ispi)
@@ -1350,6 +1357,10 @@ static int intel_spi_populate_chip(struct intel_spi *ispi)
 	struct spi_board_info chip;
 	int ret;
 
+	ret = intel_spi_read_desc(ispi);
+	if (ret)
+		return ret;
+
 	pdata = devm_kzalloc(ispi->dev, sizeof(*pdata), GFP_KERNEL);
 	if (!pdata)
 		return -ENOMEM;
@@ -1369,10 +1380,6 @@ static int intel_spi_populate_chip(struct intel_spi *ispi)
 	if (!spi_new_device(ispi->host, &chip))
 		return -ENODEV;
 
-	ret = intel_spi_read_desc(ispi);
-	if (ret)
-		return ret;
-
 	/* Add the second chip if present */
 	if (ispi->host->num_chipselect < 2)
 		return 0;
-- 
2.43.0

Re: [PATCH 1/2] spi: intel: Add default partition and name to the second chip

[Mark Brown]

On Thu, 01 Feb 2024 14:16:37 +0200, Mika Westerberg wrote:
> This should make it easier to identify the second chip and also allows
> using "mtdparts=" and the like with this chip too.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: intel: Add default partition and name to the second chip
      commit: e58db3bcd93b9e0bf5068a29f7e1a97c29926830
[2/2] spi: intel: Keep the BIOS partition inside the first chip
      commit: 83c9c7ec8b914faf91567132ab197c54253c277f

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark