mtd: m25p80: fix some module and documentation issues
Subsystems (2)
cover mtd: m25p80: fix some module and documentation issues
Hi,
There were a few mistakes and improvements pointed out at various points in this thread, subject:
spi: OF module autoloading is still broken
(was: Re: m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" breaks module autoloading)
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062369.html
https://lkml.org/lkml/2015/11/12/574
That thread covers some other interesting issues that are still not solved, but let's fix the ones we can here in MTD right now.
Regards,
Brian
Brian Norris (3):
mtd: m25p80: fix module autoloading for "jedec,spi-nor" and "spi-nor"
mtd: m25p80: replace leftover "nor-jedec" with "spi-nor" in comments
doc: dt: mtd: stop referring to driver code for spi-nor IDs
.../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 ++++++++++++++++++++-- drivers/mtd/devices/m25p80.c | 17 +++++-- 2 files changed, 64 insertions(+), 9 deletions(-)
Signature · 6 lines
2.6.0.rc2.230.g3dd15c0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/3 mtd: m25p80: fix module autoloading for "jedec,spi-nor" and "spi-nor"
Commit 43163022927b ("mtd: m25p80: allow arbitrary OF matching for "jedec,spi-nor"") moved the "jedec,spi-nor" handling from the spi_device_id table to the of_match_table, to better handle matching complex device tree compatible strings. With that patch, device tree support works as expected when m25p80.c is built into the kernel.
However, that commit ignored the fact that:
(1) (non-DT) platform devices might want to use the "spi-nor" string for matching with this driver, rather than picking an arbitrary one like "m25p80"
(2) the core SPI uevent/modalias code doesn't yet support kernel module autoloading via of_match_table strings; so for DT-based devices, it will only report (part of) the first compatible string used
Problem (1) has been reported previously, and I forgot to patch it up afterward.
Problem (2) was noticed recently here:
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062369.html
https://lkml.org/lkml/2015/11/12/574
Specifically, this patch fixes m25p80.ko module autoloading for cases like this:
flash@xxx {
compatible = "jedec,spi-nor";
...
};because modalias of "spi:spi-nor" (the only module loading info provided by the SPI core for this device) will now be listed as an alias in m25p80.ko.
Notably, it does *not* help cases like this:
flash@xxx {
compatible = "vendor,shiny-new-device", "jedec,spi-nor";
...
};unless we also list "shiny-new-device" in m25p_ids[]. There has been discussion on future work for this issue here:
https://lkml.org/lkml/2015/11/12/574
---
Tested module autoload with each of the following:
compatible = "m25p80"; compatible = "jedec,spi-nor";
drivers/mtd/devices/m25p80.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/mtd/devices/m25p80.c +10 -1
@@ -179,7 +179,7 @@ static int m25p_probe(struct spi_device *spi)struct m25p *flash;struct spi_nor *nor;enum read_mode mode =SPI_NOR_NORMAL ; -char *flash_name =NULL ; +char *flash_name;int ret; data =dev_get_platdata (&spi->dev);
@@ -219,6 +219,8 @@ static int m25p_probe(struct spi_device *spi)*/ if (data && data->type) flash_name = data->type; +else if (!strcmp (spi->modalias,"spi-nor" )) + flash_name =NULL ;/* auto-detect */ else flash_name = spi->modalias;
@@ -253,6 +255,13 @@ static int m25p_remove(struct spi_device *spi)*/ static const struct spi_device_id m25p_ids[] = {/* +* Allow non-DT platform devices to bind to the "spi-nor" modalias, and +* hack around the fact that the SPI core does not provide uevent +* matching for .of_match_table +*/ + {"spi-nor" }, + +/* * Entries not used in DTs that should be safe to drop after replacing * them with "nor-jedec" in platform data. */
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
Re: [PATCH 1/3] mtd: m25p80: fix module autoloading for "jedec,spi-nor" and "spi-nor"
Hello Brian,
Quoted 6 lines · Brian Norris
Commit
43163022927b("mtd: m25p80: allow arbitrary OF matching for "jedec,spi-nor"") moved the "jedec,spi-nor" handling from thespi_device_idtable to theof_match_table, to better handle matching complex device tree compatible strings. With that patch, device tree support works as expected whenm25p80.cis built into the kernel.
Quoted 9 lines
However, that commit ignored the fact that:
(1) (non-DT) platform devices might want to use the "spi-nor" string for matching with this driver, rather than picking an arbitrary one like "m25p80"
(2) the core SPI uevent/modalias code doesn't yet support kernel module autoloading viaof_match_tablestrings; so for DT-based devices, it will only report (part of) the first compatible string used
Very nice changelog message!
Patch looks good to me.
Best regards,
Signature · 3 lines
Javier Martinez Canillas Open Source Group Samsung Research America
PATCH 2/3 mtd: m25p80: replace leftover "nor-jedec" with "spi-nor" in comments
In reply to Brian NorrisI overlooked a few comments in commit 8947e396a829 ("Documentation: dt:
mtd: replace "nor-jedec" binding with "jedec, spi-nor""). Fix these up now.
--- drivers/mtd/devices/m25p80.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mtd/devices/m25p80.c +3 -3
@@ -263,13 +263,13 @@ static const struct spi_device_id m25p_ids[] = {/* * Entries not used in DTs that should be safe to drop after replacing -* them with "nor-jedec" in platform data. +* them with "spi-nor" in platform data. */ {"s25sl064a"}, {"w25x16"}, {"m25p10"}, {"m25px64"},/* -* Entries that were used in DTs without "nor-jedec" fallback and should -* be kept for backward compatibility. +* Entries that were used in DTs without "jedec,spi-nor" fallback and +* should be kept for backward compatibility. */ {"at25df321a"}, {"at25df641"}, {"at26df081a"}, {"mr25h256"},
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
Re: [PATCH 2/3] mtd: m25p80: replace leftover "nor-jedec" with "spi-nor" in comments
Hello Brian,
Quoted 7 lines · Brian Norris
I overlooked a few comments in commit
8947e396a829("Documentation: dt:
mtd: replace "nor-jedec" binding with "jedec, spi-nor""). Fix these up now.Suggested-by Javier Martinez Canillas <[email protected]>Signed-off-by Brian Norris <[email protected]>---
Best regards,
Signature · 3 lines
Javier Martinez Canillas Open Source Group Samsung Research America
PATCH 3/3 doc: dt: mtd: stop referring to driver code for spi-nor IDs
In reply to Brian NorrisPull the supported chip names from drivers/mtd/devices/m25p80.c and stop pointing readers to Linux code.
Also (although I see this habit repeated throughout the Documentation/devicetree/bindings/ tree), stop using the title "driver" in this file, when we're trying explicitly to describe hardware, not software.
--- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 ++++++++++++++++++++-- 1 file changed, 51 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +51 -5
@@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows. Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641 + at26df081a + mr25h256 + mx25l4005a + mx25l1606e + mx25l6405d + mx25l12805d + mx25l25635e + n25q064 + n25q128a11 + n25q128a13 + n25q512a + s25fl256s1 + s25fl512s + s25sl12801 + s25fl008k + s25fl064k + sst25vf040b + m25p40 + m25p80 + m25p16 + m25p32 + m25p64 + m25p128 + w25x80 + w25x32 + w25q32 + w25q32dw + w25q80bl + w25q128 + w25q256 + + The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec + - reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
Signature · 6 lines
2.6.0.rc2.230.g3dd15c0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Quoted 10 lines · Brian Norris
Pull the supported chip names from
drivers/mtd/devices/m25p80.cand stop pointing readers to Linux code.Also (although I see this habit repeated throughout the
Documentation/devicetree/bindings/tree), stop using the title "driver" in this file, when we're trying explicitly to describe hardware, not software.Signed-off-by Brian Norris <[email protected]>Cc <[email protected]>
Thanks for the clean-up.
Quoted 82 lines
--- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 ++++++++++++++++++++-- 1 file changed, 51 insertions(+), 5 deletions(-)Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +51
-5@@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows. Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641 + at26df081a + mr25h256 + mx25l4005a + mx25l1606e + mx25l6405d + mx25l12805d + mx25l25635e + n25q064 + n25q128a11 + n25q128a13 + n25q512a + s25fl256s1 + s25fl512s + s25sl12801 + s25fl008k + s25fl064k + sst25vf040b + m25p40 + m25p80 + m25p16 + m25p32 + m25p64 + m25p128 + w25x80 + w25x32 + w25q32 + w25q32dw + w25q80bl + w25q128 + w25q256 + + The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec + - reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate atSignature · 6 lines
2.6.0.rc2.230.g3dd15c0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
In reply to Brian NorrisHello Brian,
Quoted 5 lines · Brian Norris
Pull the supported chip names from
drivers/mtd/devices/m25p80.cand stop pointing readers to Linux code.Also (although I see this habit repeated throughout the
Documentation/devicetree/bindings/tree), stop using the title "driver"
Agreed.
Quoted 17 lines
in this file, when we're trying explicitly to describe hardware, not software.
Signed-off-by Brian Norris <[email protected]>Cc <[email protected]>--- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 ++++++++++++++++++++-- 1 file changed, 51 insertions(+), 5 deletions(-)Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +1
-1@@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 8
Quoted 10 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +2
-4Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows.
Here says that the compatible string consists of manufacturer and name...
Quoted 27 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +25
-0Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641 + at26df081a + mr25h256 + mx25l4005a + mx25l1606e + mx25l6405d + mx25l12805d + mx25l25635e + n25q064 + n25q128a11 + n25q128a13 + n25q512a + s25fl256s1 + s25fl512s + s25sl12801 + s25fl008k + s25fl064k + sst25vf040b + m25p40 + m25p80 + m25p16 + m25p32
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 45
Quoted 10 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +10
-0+ m25p64 + m25p128 + w25x80 + w25x32 + w25q32 + w25q32dw + w25q80bl + w25q128 + w25q256 +
... but the entries in the list don't have a manufacturer. I know this is due backward compatibility because as we discussed in the thread mentioned in the cover letter, the SPI core didn't use the manufacturer and that implementation detail leaked into the DTBs.
But I think that either only the correct list with vendor should be added to the DT binding docs (but make sure that backward compatibility in the driver and SPI core is maintained) or both the wrong and correct list should be documented and the former be marked as deprecated.
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 58
Quoted 13 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +13
-0+ The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec +
Same here, I would prefer if the DT binding make it clear that not having a vendor is wrong and is only documented to maintain backward compatibility.
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 61
Quoted 4 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +0
-0- reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
Best regards,
Signature · 7 lines
Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Hi,
Quoted 28 lines · Javier Martinez Canillas
Quoted 8 lines · Brian Norris
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +1
-1@@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chipsDocumentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 8
Quoted 10 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +2
-4Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows.Here says that the compatible string consists of manufacturer and name...
Quoted 6 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +4
-0Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641
[...]
Quoted 11 lines
+
... but the entries in the list don't have a manufacturer. I know this is due backward compatibility because as we discussed in the thread mentioned in the cover letter, the SPI core didn't use the manufacturer and that implementation detail leaked into the DTBs.
But I think that either only the correct list with vendor should be added to the DT binding docs (but make sure that backward compatibility in the driver and SPI core is maintained) or both the wrong and correct list should be documented and the former be marked as deprecated.
First, note that the list says "Supported chip *names*" (not "Supported compatible values"). It does not attempt to specify the full compatible value, and that's intentional.
Second, I believe it is hard to determine after-the-fact what all the reasonable pairings of vendors might be. For some of these parts, various companies have produced parts under the same chip ID -- usually because one company bought another. For most chips though, this probably isn't a problem, so I could probably pick reasonable vendor pairings.
IOW, there isn't just "a wrong" and "a correct" list; there's a (probably?) correct list and an enormous space of "I don't know what people might have put here" list. It's nearly unbounded, but even a reasonable list might get pretty large. So in practice, we'd essentially be sacrificing completeness for...what reason?
Quoted 14 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 58
Quoted 13 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +13
-0+ The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec +
Quoted 2 lines
Same here, I would prefer if the DT binding make it clear that not having a vendor is wrong and is only documented to maintain backward compatibility.
The doc never says anything about not including the vendor. It says
"May include a device-specific string consisting of the manufacturer and name of the chip"
and it lists the chip names. So if someone is actually following the documentation, they will include a vendor. The vendor names are not listed because they're really not relevant to the implementation. But I could try to include them.
Quoted 4 lines
Quoted 4 lines
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
So, what makes sense? I can make a separate list of vendors (my preference), or even try to pair up vendors with chip names (even if it's sometimes an N:1 relationship). But I don't see that really buying us much, since the implementation never has (and probably never will) enforce this. What do you think?
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas
Reviewed-byRe: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Hello Brian,
Quoted 39 lines · Brian Norris
Hi,
Quoted 28 lines · Javier Martinez Canillas
Quoted 8 lines · Brian Norris
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +1
-1@@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chipsDocumentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 8
Quoted 10 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +2
-4Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows.Here says that the compatible string consists of manufacturer and name...
Quoted 6 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +4
-0Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641[...]
Quoted 7 lines
+
... but the entries in the list don't have a manufacturer. I know this is due backward compatibility because as we discussed in the thread mentioned in the cover letter, the SPI core didn't use the manufacturer and that implementation detail leaked into the DTBs.
Quoted 9 lines
Quoted 4 lines
But I think that either only the correct list with vendor should be added to the DT binding docs (but make sure that backward compatibility in the driver and SPI core is maintained) or both the wrong and correct list should be documented and the former be marked as deprecated.
First, note that the list says "Supported chip *names*" (not "Supported compatible values"). It does not attempt to specify the full compatible value, and that's intentional.
Right, sorry I missed that subtlety.
Quoted 6 lines
Second, I believe it is hard to determine after-the-fact what all the reasonable pairings of vendors might be. For some of these parts, various companies have produced parts under the same chip ID -- usually because one company bought another. For most chips though, this probably isn't a problem, so I could probably pick reasonable vendor pairings.
Quoted 6 lines
IOW, there isn't just "a wrong" and "a correct" list; there's a (probably?) correct list and an enormous space of "I don't know what people might have put here" list. It's nearly unbounded, but even a reasonable list might get pretty large. So in practice, we'd essentially be sacrificing completeness for...what reason?
I see.
Quoted 19 lines
Quoted 14 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt line 58
Quoted 13 lines
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +13
-0+ The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec +Quoted 2 lines
Same here, I would prefer if the DT binding make it clear that not having a vendor is wrong and is only documented to maintain backward compatibility.
The doc never says anything about not including the vendor. It says
Quoted 8 lines
"May include a device-specific string consisting of the manufacturer and name of the chip"
and it lists the chip names. So if someone is actually following the documentation, they will include a vendor. The vendor names are not listed because they're really not relevant to the implementation. But I could try to include them.
My goal was to start forcing people to use a complete compatible string to avoid the "garbage,chip-name" that you mentioned in the other thread.
The vendor are not relevant in the current implementation because how the SPI core is implemented but I think that shouldn't affect the accuracy on which hardware is described in the DT.
Quoted 11 lines
Quoted 4 lines
Quoted 4 lines
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate atSo, what makes sense? I can make a separate list of vendors (my preference), or even try to pair up vendors with chip names (even if it's sometimes an N:1 relationship). But I don't see that really buying us much, since the implementation never has (and probably never will) enforce this. What do you think?
Yes, you are right that is hard to come with a reasonable list specially since the vendor and chip relation could be N:1 as you said.
$SUBJECT is definitely an improvement over the current doc that mentions the "m25p_ids" table in the driver though. So we can update later the DT binding once / if the SPI core is modified to report proper OF modalias so OF-only drivers can get rid of their SPI id table.
So for this patch:
Best regards,
Signature · 7 lines
Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · Brian Norris
Hi,
There were a few mistakes and improvements pointed out at various points in this thread, subject:
spi: OF module autoloading is still broken
(was: Re: m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" breaks module autoloading)
Quoted 8 lines
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062369.html
https://lkml.org/lkml/2015/11/12/574That thread covers some other interesting issues that are still not solved, but let's fix the ones we can here in MTD right now.
Regards,
Brian
Pushed all to l2-mtd.git