[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6eecffe2-539f-f1a1-2008-3877c5f5c3ef@huawei.com>
Date: Fri, 4 Oct 2019 16:17:38 +0100
From: John Garry <john.garry@...wei.com>
To: <Tudor.Ambarus@...rochip.com>, <vigneshr@...com>,
<miquel.raynal@...tlin.com>, <richard@....at>,
<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: Fix direction of the write_sr() transfer
On 04/10/2019 12:31, John Garry wrote:
> On 04/10/2019 11:48, Tudor.Ambarus@...rochip.com wrote:
>> John, does this fix your problem?
>
> It fixes the problem in the flash_lock -u command no longer errors like
> this:
> root@...ntu:/home/john# sudo flash_lock -u /dev/mtd0
> flash_lock: error!: could not unlock device: /dev/mtd0
>
> However, with this change, even when the flash is unlocked I cannot
> write, so there is something else wrong. It's probably a bug in my
> under-development driver. I'm looking at it now.
Just to confirm, I tested an earlier HW version with my driver and flash
lock/unlock function is ok. There seems something wrong with the latest
HW version which I need to understand.
Anyway:
Tested-by: John Garry <john.garry@...wei.com>
Thanks,
John
>
>>
>> On 10/04/2019 01:47 PM, Tudor Ambarus - M18064 wrote:
>>> From: Tudor Ambarus <tudor.ambarus@...rochip.com>
>>>
>>> write_sr() sends data to the SPI memory, fix the direction.
>>>
>>> Fixes: b35b9a10362d ("mtd: spi-nor: Move m25p80 code in spi-nor.c")
>>> Reported-by: John Garry <john.garry@...wei.com>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@...rochip.com>
>>> ---
>>> drivers/mtd/spi-nor/spi-nor.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c
>>> b/drivers/mtd/spi-nor/spi-nor.c
>>> index 1d8621d43160..7acf4a93b592 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -487,7 +487,7 @@ static int write_sr(struct spi_nor *nor, u8 val)
>>> SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRSR, 1),
>>> SPI_MEM_OP_NO_ADDR,
>>> SPI_MEM_OP_NO_DUMMY,
>>> - SPI_MEM_OP_DATA_IN(1, nor->bouncebuf, 1));
>>> + SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
>>>
>>> return spi_mem_exec_op(nor->spimem, &op);
>>> }
>>>
>
Powered by blists - more mailing lists