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 <[email protected]>
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
--
2.17.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 <[email protected]>
>
> 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
>
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 <[email protected]>
>>
>> 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/
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 <[email protected]>
>>>
>>> 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/
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/
>
>
--
Regards
Vignesh
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
>>
>>
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.
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
>
On Fri, 6 Sep 2019 15:58:41 +0100
John Garry <[email protected]> wrote:
> I don't think that it was appropriate to apply this patch in the end -
> maybe this could have been communicated better. If you check the
> subsequent discussion in this thread, it seems that completely new
> documentation is required:
>
> "Actually it seems like the whole file is obsolete and needs to be
> removed or replaced by proper documentation of the SPI MEM API."
>
> But nothing seems to be happening there...
Ah, OK, I lost track of that somewhere along the way.
Unless you object I'll leave it applied, it's not going to do any harm,
methinks.
jon
On Wed, 7 Aug 2019 00:06:23 +0800
John Garry <[email protected]> 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 <[email protected]>
So this appears to have languished for a month...applied now, sorry for
the delay.
Thanks,
jon
On 06/09/2019 15:52, Jonathan Corbet wrote:
> On Wed, 7 Aug 2019 00:06:23 +0800
> John Garry <[email protected]> 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 <[email protected]>
>
> So this appears to have languished for a month...applied now, sorry for
> the delay.
>
> Thanks,
>
> jon
>
> .
>
Hi Jon,
I don't think that it was appropriate to apply this patch in the end -
maybe this could have been communicated better. If you check the
subsequent discussion in this thread, it seems that completely new
documentation is required:
"Actually it seems like the whole file is obsolete and needs to be
removed or replaced by proper documentation of the SPI MEM API."
But nothing seems to be happening there...
Thanks,
John
On 09/06/2019 06:03 PM, Jonathan Corbet wrote:
> On Fri, 6 Sep 2019 15:58:41 +0100
> John Garry <[email protected]> wrote:
>
>> I don't think that it was appropriate to apply this patch in the end -
>> maybe this could have been communicated better. If you check the
>> subsequent discussion in this thread, it seems that completely new
>> documentation is required:
>>
>> "Actually it seems like the whole file is obsolete and needs to be
>> removed or replaced by proper documentation of the SPI MEM API."
>>
>> But nothing seems to be happening there...
>
> Ah, OK, I lost track of that somewhere along the way.
>
> Unless you object I'll leave it applied, it's not going to do any harm,
> methinks.
>
We can rework the documentation on top of this, no worries.
Cheers,
ta