spi: npcm-pspi: add Arbel NPCM8XX support

Add a compatible string for Nuvoton BMC NPCM845 PSPI.

Signed-off-by Tomer Maimon <[email protected]>

---
 Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +0 -0

index b98203ca656d..a4e72e52af59 100644

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +0 -0

  - #address-cells : should be 1. see spi-bus.txt
  - #size-cells : should be 0. see spi-bus.txt
  - specifies physical base address and size of the register.

Signature · 1 line

2.33.0

Quoted 12 lines · Tomer Maimon

Add a compatible string for Nuvoton BMC NPCM845 PSPI.

Signed-off-by Tomer Maimon <[email protected]>

---
 Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +0 -0

index b98203ca656d..a4e72e52af59 100644

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt Nuvoton NPCM Peripheral Serial Peripheral Interface(PSPI) controller driver · line 6

Quoted 5 lines

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +1 -1

@@ -3,7 +3,8 @@ Nuvoton NPCM Peripheral Serial Peripheral Interface(PSPI) controller driver
 Nuvoton NPCM7xx SOC support two PSPI channels.
 
 Required properties:
- - compatible : "nuvoton,npcm750-pspi" for NPCM7XX BMC
+ - compatible : "nuvoton,npcm750-pspi" for Poleg NPCM7XX.

Who/What is Polog? Board/BMC vendor? If so, that should not be in SoC bindings.

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt Nuvoton NPCM Peripheral Serial Peripheral Interface(PSPI) controller driver · line 7

Quoted 1 line

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +1 -0

+                             "nuvoton,npcm845-pspi" for Arbel NPCM8XX.

Same for Arbel.

To answer your question on fallback, just put:

    "nuvoton,npcm845-pspi", "nuvoton,npcm750-pspi" for NPCM8XX BMC

Quoted 9 lines

Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt +0 -1

  - #address-cells : should be 1. see spi-bus.txt
  - #size-cells : should be 0. see spi-bus.txt
  - specifies physical base address and size of the register.
--

2.33.0

Quoted 3 lines

To answer your question on fallback, just put:

    "nuvoton,npcm845-pspi", "nuvoton,npcm750-pspi" for NPCM8XX BMC

In the document?
because I don't remember doing so in other documents that I use fallback.

I need to do it in ymal files as well?

Add Nuvoton BMC NPCM845 NPCM Peripheral SPI (PSPI) support.

Signed-off-by Tomer Maimon <[email protected]>

---
 drivers/spi/spi-npcm-pspi.c | 1 +
 1 file changed, 1 insertion(+)

drivers/spi/spi-npcm-pspi.c +0 -0

index 1668a347e003..7f2e4d1b0d43 100644

drivers/spi/spi-npcm-pspi.c static int npcm_pspi_remove(struct platform_device *pdev) · line 446

Quoted 3 lines · Tomer Maimon

static const struct of_device_id npcm_pspi_match[] = {

drivers/spi/spi-npcm-pspi.c +1 -0

 	{ .compatible = "nuvoton,npcm750-pspi", .data = NULL },
+	{ .compatible = "nuvoton,npcm845-pspi", .data = NULL },

The devices look compatible, so why not reusing 750 compatible and adding more specific upfront only in the bindings instead?

Quoted 8 lines · Krzysztof Kozlowski

drivers/spi/spi-npcm-pspi.c static int npcm_pspi_remove(struct platform_device *pdev) · line 446

Quoted 3 lines · Tomer Maimon

static const struct of_device_id npcm_pspi_match[] = {

drivers/spi/spi-npcm-pspi.c +1 -0

 	{ .compatible = "nuvoton,npcm750-pspi", .data = NULL },
+	{ .compatible = "nuvoton,npcm845-pspi", .data = NULL },

The devices look compatible, so why not reusing 750 compatible and adding more specific upfront only in the bindings instead?

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Quoted 4 lines · Mark Brown

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Yes, the bindings document should be rephrased but we were living like that for few years. :)

Quoted 9 lines · Krzysztof Kozlowski

Quoted 4 lines · Mark Brown

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Yes, the bindings document should be rephrased but we were living like that for few years. :)

The binding document as it stands only has one compatible, there's no existing problem with it other than the YAML conversion. If we're adding something new that requires a fallback we should be explicit about that rather than have something that's actively misleading where previously things were clear. I don't mind if we add the compatible to the driver or document the requirement for the fallback but we should do one of the two.

Hi Mark and Krzysztof,

Thanks for your reply,

Quoted 12 lines · Mark Brown

Quoted 9 lines · Krzysztof Kozlowski

Quoted 4 lines · Mark Brown

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Yes, the bindings document should be rephrased but we were living like that for few years. :)

Quoted 7 lines

The binding document as it stands only has one compatible, there's no existing problem with it other than the YAML conversion. If we're adding something new that requires a fallback we should be explicit about that rather than have something that's actively misleading where previously things were clear. I don't mind if we add the compatible to the driver or document the requirement for the fallback but we should do one of the two.

is V2 good enough? adding the compatible to the driver and the document? Or should we use fallback?
If fallback is choosen, can you explain how I should do it?

Quoted 25 lines · Tomer Maimon

Hi Mark and Krzysztof,

Thanks for your reply,

Quoted 12 lines · Mark Brown

Quoted 9 lines · Krzysztof Kozlowski

Quoted 4 lines · Mark Brown

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Yes, the bindings document should be rephrased but we were living like that for few years. :)

Quoted 7 lines

The binding document as it stands only has one compatible, there's no existing problem with it other than the YAML conversion. If we're adding something new that requires a fallback we should be explicit about that rather than have something that's actively misleading where previously things were clear. I don't mind if we add the compatible to the driver or document the requirement for the fallback but we should do one of the two.

Quoted 3 lines

is V2 good enough? adding the compatible to the driver and the document? Or should we use fallback?
If fallback is choosen, can you explain how I should do it?

I propose to use fallback. The preferred way is to convert it to DT schema and then add new device support (so two commits). Other acceptable way is to rephrase the TXT so it clearly states desired compatibles - one for old device, two for new devices. There are plenty of examples in current sources.

Best regards,
Krzysztof

Hi Krzysztof,

Thanks for your explanation.

Quoted 31 lines · Krzysztof Kozlowski

Quoted 25 lines · Tomer Maimon

Hi Mark and Krzysztof,

Thanks for your reply,

Quoted 12 lines · Mark Brown

Quoted 9 lines · Krzysztof Kozlowski

Quoted 4 lines · Mark Brown

...with a fallback list required by the bindings so the driver actually binds. Note that bindings are currently not in YAML format so there'd be even less enforcement of that than normal, and as they're currently written the bindings don't require fallback.

Yes, the bindings document should be rephrased but we were living like that for few years. :)

Quoted 7 lines

The binding document as it stands only has one compatible, there's no existing problem with it other than the YAML conversion. If we're adding something new that requires a fallback we should be explicit about that rather than have something that's actively misleading where previously things were clear. I don't mind if we add the compatible to the driver or document the requirement for the fallback but we should do one of the two.

Quoted 3 lines

is V2 good enough? adding the compatible to the driver and the document? Or should we use fallback?
If fallback is choosen, can you explain how I should do it?

Quoted 5 lines

I propose to use fallback. The preferred way is to convert it to DT schema and then add new device support (so two commits). Other acceptable way is to rephrase the TXT so it clearly states desired compatibles - one for old device, two for new devices. There are plenty of examples in current sources.

Appreciate if you could clarify.
in case we use DT-schema, we dont describe the fallback like we doing in txt document?
I mean that in the yaml file we should describe the NPCM PSPI compatible property as follow:
compatible:
enum:
- nuvoton,npcm750-pspi
- nuvoton,npcm845-pspi

If yes, how should the user know that he needs to use fallback incase is using nuvoton,npcm845-pspi? only from the device tree?

This patch set adds Arbel NPCM8XX Peripheral SPI (PSPI) support to PSPI NPCM driver.

This patch set was separated from the full duplex patch.
https://lore.kernel.org/lkml/[email protected]/

Addressed comments from:
- Mark Brown : https://www.spinics.net/lists/kernel/msg4447178.html

[...]