Airoha EN7523 specific bug
--------------------------
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. On the EN7523
SoC this may lead to booting in RESERVED boot mode.

It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are NOT affected.

Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. As result OS loading becomes
impossible.

Usage of UBI make things even worse. On attaching, UBI will detects
corruptions (because of wrong reading of odd pages) and will try to
recover. For recovering UBI will erase and write 'damaged' blocks with
a valid information. This will destroy all UBI data.

Non-DMA reading is OK.

This patch detects booting in reserved mode, turn off DMA and print big
fat warning.

Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/spi/spi-airoha-snfi.c | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-airoha-snfi.c b/drivers/spi/spi-airoha-snfi.c
index 8408aee9c06e..a2f2ae7c60d2 100644
--- a/drivers/spi/spi-airoha-snfi.c
+++ b/drivers/spi/spi-airoha-snfi.c
@@ -1013,6 +1013,11 @@ static const struct spi_controller_mem_ops airoha_snand_mem_ops = {
 	.dirmap_write = airoha_snand_dirmap_write,
 };
 
+static const struct spi_controller_mem_ops airoha_snand_nodma_mem_ops = {
+	.supports_op = airoha_snand_supports_op,
+	.exec_op = airoha_snand_exec_op,
+};
+
 static int airoha_snand_setup(struct spi_device *spi)
 {
 	struct airoha_snand_ctrl *as_ctrl;
@@ -1057,7 +1062,9 @@ static int airoha_snand_probe(struct platform_device *pdev)
 	struct airoha_snand_ctrl *as_ctrl;
 	struct device *dev = &pdev->dev;
 	struct spi_controller *ctrl;
+	bool dma_enable = true;
 	void __iomem *base;
+	u32 sfc_strap;
 	int err;
 
 	ctrl = devm_spi_alloc_host(dev, sizeof(*as_ctrl));
@@ -1092,12 +1099,31 @@ static int airoha_snand_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(as_ctrl->spi_clk),
 				     "unable to get spi clk\n");
 
-	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
-	if (err)
-		return err;
+	if (device_is_compatible(dev, "airoha,en7523-snand")) {
+		err = regmap_read(as_ctrl->regmap_ctrl,
+				  REG_SPI_CTRL_SFC_STRAP, &sfc_strap);
+		if (err)
+			return err;
+
+		if (!(sfc_strap & 0x04)) {
+			dma_enable = false;
+			dev_warn(dev, "Detected booting in RESERVED mode (UART_TXD was short to GND).\n");
+			dev_warn(dev, "This mode is known for incorrect DMA reading of some flashes.\n");
+			dev_warn(dev, "Usage of DMA for flash operations will be disabled to prevent data\n");
+			dev_warn(dev, "damage. Unplug your serial console and power cycle the board\n");
+			dev_warn(dev, "to boot with full performance.\n");
+		}
+	}
+
+	if (dma_enable) {
+		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
+		if (err)
+			return err;
+	}
 
 	ctrl->num_chipselect = 2;
-	ctrl->mem_ops = &airoha_snand_mem_ops;
+	ctrl->mem_ops = dma_enable ? &airoha_snand_mem_ops
+				   : &airoha_snand_nodma_mem_ops;
 	ctrl->bits_per_word_mask = SPI_BPW_MASK(8);
 	ctrl->mode_bits = SPI_RX_DUAL;
 	ctrl->setup = airoha_snand_setup;
-- 
2.51.0

On Tue, Nov 25, 2025 at 05:10:49AM +0300, Mikhail Kshevetskiy wrote:
> Airoha EN7523 specific bug
> --------------------------
> We found that some serial console may pull TX line to GROUND during board
> boot time. Airoha uses TX line as one of it's BOOT pins.

I know the term bootstrap, what does BOOT mean?

> On the EN7523 SoC this may lead to booting in RESERVED boot mode.
> 
> It was found that some flashes operates incorrectly in RESERVED mode.
> Micron and Skyhigh flashes are definitely affected by the issue,
> Winbond flashes are NOT affected.

NOT --> not

> Details:
> --------
> DMA reading of odd pages on affected flashes operates incorrectly. Page
> reading offset (start of the page) on hardware level is replaced by 0x10.
> Thus results in incorrect data reading. As result OS loading becomes
> impossible.
> 
> Usage of UBI make things even worse. On attaching, UBI will detects
> corruptions (because of wrong reading of odd pages) and will try to
> recover. For recovering UBI will erase and write 'damaged' blocks with
> a valid information. This will destroy all UBI data.
> 
> Non-DMA reading is OK.
> 
> This patch detects booting in reserved mode, turn off DMA and print big
> fat warning.

...

> -	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> -	if (err)
> -		return err;

> +	if (dma_enable) {
> +		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> +		if (err)
> +			return err;
> +	}

Why do you need this to be conditional? The settings of DMA mask should not
affect the (in)ability of the device to perform DMA. I.o.w. it should not
influence PIO mode. Can you confirm this?

-- 
With Best Regards,
Andy Shevchenko

On 11/25/25 10:18, Andy Shevchenko wrote:
> On Tue, Nov 25, 2025 at 05:10:49AM +0300, Mikhail Kshevetskiy wrote:
>> Airoha EN7523 specific bug
>> --------------------------
>> We found that some serial console may pull TX line to GROUND during board
>> boot time. Airoha uses TX line as one of it's BOOT pins.
> I know the term bootstrap, what does BOOT mean?

yes, it's bootstrap pin

>
>> On the EN7523 SoC this may lead to booting in RESERVED boot mode.
>>
>> It was found that some flashes operates incorrectly in RESERVED mode.
>> Micron and Skyhigh flashes are definitely affected by the issue,
>> Winbond flashes are NOT affected.
> NOT --> not
will fix
>
>> Details:
>> --------
>> DMA reading of odd pages on affected flashes operates incorrectly. Page
>> reading offset (start of the page) on hardware level is replaced by 0x10.
>> Thus results in incorrect data reading. As result OS loading becomes
>> impossible.
>>
>> Usage of UBI make things even worse. On attaching, UBI will detects
>> corruptions (because of wrong reading of odd pages) and will try to
>> recover. For recovering UBI will erase and write 'damaged' blocks with
>> a valid information. This will destroy all UBI data.
>>
>> Non-DMA reading is OK.
>>
>> This patch detects booting in reserved mode, turn off DMA and print big
>> fat warning.
> ...
>
>> -	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
>> -	if (err)
>> -		return err;
>> +	if (dma_enable) {
>> +		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
>> +		if (err)
>> +			return err;
>> +	}
> Why do you need this to be conditional? The settings of DMA mask should not
> affect the (in)ability of the device to perform DMA. I.o.w. it should not
> influence PIO mode. Can you confirm this?
>
no any particular reason, just see no sense to set mask if dma will not
be used


Regards,

Mikhail Kshevetskiy 

On Tue, Nov 25, 2025 at 01:04:12PM +0300, Mikhail Kshevetskiy wrote:
> On 11/25/25 10:18, Andy Shevchenko wrote:
> > On Tue, Nov 25, 2025 at 05:10:49AM +0300, Mikhail Kshevetskiy wrote:
> >> Airoha EN7523 specific bug
> >> --------------------------
> >> We found that some serial console may pull TX line to GROUND during board
> >> boot time. Airoha uses TX line as one of it's BOOT pins.
> > I know the term bootstrap, what does BOOT mean?
> 
> yes, it's bootstrap pin

Then use that term.

> >> On the EN7523 SoC this may lead to booting in RESERVED boot mode.
> >>
> >> It was found that some flashes operates incorrectly in RESERVED mode.
> >> Micron and Skyhigh flashes are definitely affected by the issue,
> >> Winbond flashes are NOT affected.
> > NOT --> not
> will fix

> >> Details:
> >> --------
> >> DMA reading of odd pages on affected flashes operates incorrectly. Page
> >> reading offset (start of the page) on hardware level is replaced by 0x10.
> >> Thus results in incorrect data reading. As result OS loading becomes
> >> impossible.
> >>
> >> Usage of UBI make things even worse. On attaching, UBI will detects
> >> corruptions (because of wrong reading of odd pages) and will try to
> >> recover. For recovering UBI will erase and write 'damaged' blocks with
> >> a valid information. This will destroy all UBI data.
> >>
> >> Non-DMA reading is OK.
> >>
> >> This patch detects booting in reserved mode, turn off DMA and print big
> >> fat warning.

...

> >> -	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> >> -	if (err)
> >> -		return err;
> >> +	if (dma_enable) {
> >> +		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> >> +		if (err)
> >> +			return err;
> >> +	}
> > Why do you need this to be conditional? The settings of DMA mask should not
> > affect the (in)ability of the device to perform DMA. I.o.w. it should not
> > influence PIO mode. Can you confirm this?
> >
> no any particular reason, just see no sense to set mask if dma will not
> be used

So, this is an unneeded churn in the patch. Device is [still] capable of DMA?
Yes. Set the mask. The DMA/PIO choice is done on the upper layer (as you do it
via ops).

-- 
With Best Regards,
Andy Shevchenko

On 11/25/25 13:14, Andy Shevchenko wrote:
> On Tue, Nov 25, 2025 at 01:04:12PM +0300, Mikhail Kshevetskiy wrote:
>> On 11/25/25 10:18, Andy Shevchenko wrote:
>>> On Tue, Nov 25, 2025 at 05:10:49AM +0300, Mikhail Kshevetskiy wrote:
>>>> Airoha EN7523 specific bug
>>>> --------------------------
>>>> We found that some serial console may pull TX line to GROUND during board
>>>> boot time. Airoha uses TX line as one of it's BOOT pins.
>>> I know the term bootstrap, what does BOOT mean?
>> yes, it's bootstrap pin
> Then use that term.
>
>>>> On the EN7523 SoC this may lead to booting in RESERVED boot mode.
>>>>
>>>> It was found that some flashes operates incorrectly in RESERVED mode.
>>>> Micron and Skyhigh flashes are definitely affected by the issue,
>>>> Winbond flashes are NOT affected.
>>> NOT --> not
>> will fix
>>>> Details:
>>>> --------
>>>> DMA reading of odd pages on affected flashes operates incorrectly. Page
>>>> reading offset (start of the page) on hardware level is replaced by 0x10.
>>>> Thus results in incorrect data reading. As result OS loading becomes
>>>> impossible.
>>>>
>>>> Usage of UBI make things even worse. On attaching, UBI will detects
>>>> corruptions (because of wrong reading of odd pages) and will try to
>>>> recover. For recovering UBI will erase and write 'damaged' blocks with
>>>> a valid information. This will destroy all UBI data.
>>>>
>>>> Non-DMA reading is OK.
>>>>
>>>> This patch detects booting in reserved mode, turn off DMA and print big
>>>> fat warning.
> ...

could you clarify what's wrong here?


>
>>>> -	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
>>>> -	if (err)
>>>> -		return err;
>>>> +	if (dma_enable) {
>>>> +		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
>>>> +		if (err)
>>>> +			return err;
>>>> +	}
>>> Why do you need this to be conditional? The settings of DMA mask should not
>>> affect the (in)ability of the device to perform DMA. I.o.w. it should not
>>> influence PIO mode. Can you confirm this?
>>>
>> no any particular reason, just see no sense to set mask if dma will not
>> be used
> So, this is an unneeded churn in the patch. Device is [still] capable of DMA?
> Yes. Set the mask. The DMA/PIO choice is done on the upper layer (as you do it
> via ops).
>

On Tue, Nov 25, 2025 at 05:20:44PM +0300, Mikhail Kshevetskiy wrote:
> On 11/25/25 13:14, Andy Shevchenko wrote:
> > On Tue, Nov 25, 2025 at 01:04:12PM +0300, Mikhail Kshevetskiy wrote:
> >> On 11/25/25 10:18, Andy Shevchenko wrote:
> >>> On Tue, Nov 25, 2025 at 05:10:49AM +0300, Mikhail Kshevetskiy wrote:

...

> could you clarify what's wrong here?
> 
> >>>> -	err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> >>>> -	if (err)
> >>>> -		return err;

Sure, just don't touch these lines. Only set the respective ops depending
on dma_enable.

With that done the patch will look better and less confusing about affection of
DMA mask setting on DMA operations (which are kinda orthogonal).

> >>>> +	if (dma_enable) {
> >>>> +		err = dma_set_mask(as_ctrl->dev, DMA_BIT_MASK(32));
> >>>> +		if (err)
> >>>> +			return err;
> >>>> +	}
> >>> Why do you need this to be conditional? The settings of DMA mask should not
> >>> affect the (in)ability of the device to perform DMA. I.o.w. it should not
> >>> influence PIO mode. Can you confirm this?
> >>>
> >> no any particular reason, just see no sense to set mask if dma will not
> >> be used
> > So, this is an unneeded churn in the patch. Device is [still] capable of DMA?
> > Yes. Set the mask. The DMA/PIO choice is done on the upper layer (as you do it
> > via ops).

-- 
With Best Regards,
Andy Shevchenko