docs: mtd: Update spi nor reference driver
diff mbox series

Message ID 1565107583-68506-1-git-send-email-john.garry@huawei.com
State New
Headers show
Series
  • docs: mtd: Update spi nor reference driver
Related show

Commit Message

John Garry Aug. 6, 2019, 4:06 p.m. UTC
The reference driver no longer exists since commit 50f1242c6742 ("mtd:
fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c").

Update reference to spi-fsl-qspi.c driver.

Signed-off-by: John Garry <john.garry@huawei.com>

Comments

John Garry Aug. 6, 2019, 4:35 p.m. UTC | #1
On 06/08/2019 17:06, John Garry wrote:
> The reference driver no longer exists since commit 50f1242c6742 ("mtd:
> fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c").
>
> Update reference to spi-fsl-qspi.c driver.
>
> Signed-off-by: John Garry <john.garry@huawei.com>
>
> diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
> index f5333e3bf486..1f0437676762 100644
> --- a/Documentation/driver-api/mtd/spi-nor.rst
> +++ b/Documentation/driver-api/mtd/spi-nor.rst

In fact this document has many references to Freescale QuadSPI - could 
someone kindly review this complete document for up-to-date accuracy?

Thanks,
John

> @@ -59,7 +59,7 @@ Part III - How can drivers use the framework?
>
>  The main API is spi_nor_scan(). Before you call the hook, a driver should
>  initialize the necessary fields for spi_nor{}. Please see
> -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
> +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c
>  when you want to write a new driver for a SPI NOR controller.
>  Another API is spi_nor_restore(), this is used to restore the status of SPI
>  flash chip such as addressing mode. Call it whenever detach the driver from
>
Schrempf Frieder Aug. 6, 2019, 4:40 p.m. UTC | #2
Cc: +MTD/SPI-NOR/SPI maintainers

Hi John,

On 06.08.19 18:35, John Garry wrote:
> On 06/08/2019 17:06, John Garry wrote:
>> The reference driver no longer exists since commit 50f1242c6742 ("mtd:
>> fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c").
>>
>> Update reference to spi-fsl-qspi.c driver.
>>
>> Signed-off-by: John Garry <john.garry@huawei.com>
>>
>> diff --git a/Documentation/driver-api/mtd/spi-nor.rst 
>> b/Documentation/driver-api/mtd/spi-nor.rst
>> index f5333e3bf486..1f0437676762 100644
>> --- a/Documentation/driver-api/mtd/spi-nor.rst
>> +++ b/Documentation/driver-api/mtd/spi-nor.rst
> 
> In fact this document has many references to Freescale QuadSPI - could 
> someone kindly review this complete document for up-to-date accuracy?

The new driver spi-fsl-qspi.c is not a SPI NOR controller driver 
anymore. It is now a SPI controller driver that uses the SPI MEM API, so 
referencing it here is obsolete.

Actually it seems like the whole file is obsolete and needs to be 
removed or replaced by proper documentation of the SPI MEM API.

@Maintainers:
Maybe the docs under Documentation/driver-api/mtd should be officially 
maintained by the MTD subsystem (and added to MAINTAINERS). And if there 
will be some driver API docs for SPI MEM it should probably live in 
Documentation/driver-api/spi instead of Documentation/driver-api/mtd, as 
spi-mem.c itself is in drivers/spi.

Regards,
Frieder

> 
> Thanks,
> John
> 
>> @@ -59,7 +59,7 @@ Part III - How can drivers use the framework?
>>
>>  The main API is spi_nor_scan(). Before you call the hook, a driver 
>> should
>>  initialize the necessary fields for spi_nor{}. Please see
>> -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to 
>> fsl-quadspi.c
>> +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to 
>> spi-fsl-qspi.c
>>  when you want to write a new driver for a SPI NOR controller.
>>  Another API is spi_nor_restore(), this is used to restore the status 
>> of SPI
>>  flash chip such as addressing mode. Call it whenever detach the 
>> driver from
>>
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
John Garry Aug. 16, 2019, 10:20 a.m. UTC | #3
On 06/08/2019 17:40, Schrempf Frieder wrote:
> Cc: +MTD/SPI-NOR/SPI maintainers
>
> Hi John,
>
> On 06.08.19 18:35, John Garry wrote:
>> On 06/08/2019 17:06, John Garry wrote:
>>> The reference driver no longer exists since commit 50f1242c6742 ("mtd:
>>> fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c").
>>>
>>> Update reference to spi-fsl-qspi.c driver.
>>>
>>> Signed-off-by: John Garry <john.garry@huawei.com>
>>>
>>> diff --git a/Documentation/driver-api/mtd/spi-nor.rst
>>> b/Documentation/driver-api/mtd/spi-nor.rst
>>> index f5333e3bf486..1f0437676762 100644
>>> --- a/Documentation/driver-api/mtd/spi-nor.rst
>>> +++ b/Documentation/driver-api/mtd/spi-nor.rst
>>
>> In fact this document has many references to Freescale QuadSPI - could
>> someone kindly review this complete document for up-to-date accuracy?
>
> The new driver spi-fsl-qspi.c is not a SPI NOR controller driver
> anymore. It is now a SPI controller driver that uses the SPI MEM API, so
> referencing it here is obsolete.
>
> Actually it seems like the whole file is obsolete and needs to be
> removed or replaced by proper documentation of the SPI MEM API.

Hi,

Could someone kindly advise on the following:

I am looking at ACPI support only for an mtd spi nor driver we're 
targeting for mainline support.

So for the host, I could use a proprietary HID in the DSDT for matching 
in the kernel driver.

About the child spi flash devices, is the recommendation to just use 
PRP0001 HID and "jedec,spi-nor" compatible?

thanks,
John


>
> @Maintainers:
> Maybe the docs under Documentation/driver-api/mtd should be officially
> maintained by the MTD subsystem (and added to MAINTAINERS). And if there
> will be some driver API docs for SPI MEM it should probably live in
> Documentation/driver-api/spi instead of Documentation/driver-api/mtd, as
> spi-mem.c itself is in drivers/spi.
>
> Regards,
> Frieder
>
>>
>> Thanks,
>> John
>>
>>> @@ -59,7 +59,7 @@ Part III - How can drivers use the framework?
>>>
>>>  The main API is spi_nor_scan(). Before you call the hook, a driver
>>> should
>>>  initialize the necessary fields for spi_nor{}. Please see
>>> -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to
>>> fsl-quadspi.c
>>> +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to
>>> spi-fsl-qspi.c
>>>  when you want to write a new driver for a SPI NOR controller.
>>>  Another API is spi_nor_restore(), this is used to restore the status
>>> of SPI
>>>  flash chip such as addressing mode. Call it whenever detach the
>>> driver from
>>>
>>
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Vignesh Raghavendra Aug. 19, 2019, 4:39 a.m. UTC | #4
Hi,

On 16/08/19 3:50 PM, John Garry wrote:
> On 06/08/2019 17:40, Schrempf Frieder wrote:
[...]
> 
> Hi,
> 
> Could someone kindly advise on the following:
> 
> I am looking at ACPI support only for an mtd spi nor driver we're
> targeting for mainline support.
> 

If its a new driver, please add it under drivers/spi implementing SPI
MEM framework.
There are few drivers under drivers/spi that can be used as example.
(Search for "spi_mem_ops")

> So for the host, I could use a proprietary HID in the DSDT for matching
> in the kernel driver.
> 
> About the child spi flash devices, is the recommendation to just use
> PRP0001 HID and "jedec,spi-nor" compatible?
>

I am not quite familiar with ACPI systems, but child flash device should
use "jedec,spi-nor" as compatible.

Regards
Vignesh

> thanks,
> John
> 
> 
>>
>> @Maintainers:
>> Maybe the docs under Documentation/driver-api/mtd should be officially
>> maintained by the MTD subsystem (and added to MAINTAINERS). And if there
>> will be some driver API docs for SPI MEM it should probably live in
>> Documentation/driver-api/spi instead of Documentation/driver-api/mtd, as
>> spi-mem.c itself is in drivers/spi.
>>
>> Regards,
>> Frieder
>>
>>>
>>> Thanks,
>>> John
>>>
>>>> @@ -59,7 +59,7 @@ Part III - How can drivers use the framework?
>>>>
>>>>  The main API is spi_nor_scan(). Before you call the hook, a driver
>>>> should
>>>>  initialize the necessary fields for spi_nor{}. Please see
>>>> -drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to
>>>> fsl-quadspi.c
>>>> +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to
>>>> spi-fsl-qspi.c
>>>>  when you want to write a new driver for a SPI NOR controller.
>>>>  Another API is spi_nor_restore(), this is used to restore the status
>>>> of SPI
>>>>  flash chip such as addressing mode. Call it whenever detach the
>>>> driver from
>>>>
>>>
>>>
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
>
John Garry Aug. 20, 2019, 2:09 p.m. UTC | #5
On 19/08/2019 05:39, Vignesh Raghavendra wrote:
> Hi,
>
> On 16/08/19 3:50 PM, John Garry wrote:
>> On 06/08/2019 17:40, Schrempf Frieder wrote:
> [...]
>>
>> Hi,
>>
>> Could someone kindly advise on the following:
>>

Hi Vignesh,

>> I am looking at ACPI support only for an mtd spi nor driver we're
>> targeting for mainline support.
>>
>
> If its a new driver, please add it under drivers/spi implementing SPI
> MEM framework.
> There are few drivers under drivers/spi that can be used as example.
> (Search for "spi_mem_ops"

Ok, fine. I note that in doing this I would still be using the spi nor 
framework indirectly through the m25p80 driver.

>> So for the host, I could use a proprietary HID in the DSDT for matching
>> in the kernel driver.
>>
>> About the child spi flash devices, is the recommendation to just use
>> PRP0001 HID and "jedec,spi-nor" compatible?
>>
>
> I am not quite familiar with ACPI systems, but child flash device should
> use "jedec,spi-nor" as compatible.

Right, so to use SPI MEM framework, it looks like I will have to use 
PRP0001 and "jedec,spi-nor" as compatible.

My reluctance in using PRP0001 and compatible "jedec,spi-nor" is how 
other OS can understand this.

All the best,
John

>
> Regards
> Vignesh
>
>> thanks,
>> John
>>
>>
Mark Brown Aug. 20, 2019, 4:58 p.m. UTC | #6
On Tue, Aug 20, 2019 at 03:09:15PM +0100, John Garry wrote:
> On 19/08/2019 05:39, Vignesh Raghavendra wrote:
> > On 16/08/19 3:50 PM, John Garry wrote:

> > > About the child spi flash devices, is the recommendation to just use
> > > PRP0001 HID and "jedec,spi-nor" compatible?

> > I am not quite familiar with ACPI systems, but child flash device should
> > use "jedec,spi-nor" as compatible.

> Right, so to use SPI MEM framework, it looks like I will have to use PRP0001
> and "jedec,spi-nor" as compatible.

> My reluctance in using PRP0001 and compatible "jedec,spi-nor" is how other
> OS can understand this.

Last I heard Windows wasn't doing anything with PRP0001 but on the other
hand the idiomatic way to handle this for ACPI is as far as I can tell
to have what is essentially a board file loaded based on DMI information
without any real enumerability so there's no real conflict between the
two methods.
John Garry Aug. 21, 2019, 1:39 p.m. UTC | #7
On 20/08/2019 17:58, Mark Brown wrote:
> On Tue, Aug 20, 2019 at 03:09:15PM +0100, John Garry wrote:
>> On 19/08/2019 05:39, Vignesh Raghavendra wrote:
>>> On 16/08/19 3:50 PM, John Garry wrote:
>
>>>> About the child spi flash devices, is the recommendation to just use
>>>> PRP0001 HID and "jedec,spi-nor" compatible?
>
>>> I am not quite familiar with ACPI systems, but child flash device should
>>> use "jedec,spi-nor" as compatible.
>
>> Right, so to use SPI MEM framework, it looks like I will have to use PRP0001
>> and "jedec,spi-nor" as compatible.
>
>> My reluctance in using PRP0001 and compatible "jedec,spi-nor" is how other
>> OS can understand this.
>

Hi Mark,

> Last I heard Windows wasn't doing anything with PRP0001 but on the other
> hand the idiomatic way to handle this for ACPI is as far as I can tell
> to have what is essentially a board file loaded based on DMI information
> without any real enumerability so there's no real conflict between the
> two methods.

Fine, I'll consider this alt method further.

Thanks,
John

>

Patch
diff mbox series

diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index f5333e3bf486..1f0437676762 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -59,7 +59,7 @@  Part III - How can drivers use the framework?
 
 The main API is spi_nor_scan(). Before you call the hook, a driver should
 initialize the necessary fields for spi_nor{}. Please see
-drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
+drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c
 when you want to write a new driver for a SPI NOR controller.
 Another API is spi_nor_restore(), this is used to restore the status of SPI
 flash chip such as addressing mode. Call it whenever detach the driver from