[1/2] spi: spidev: Add Qualcomm spidev device compatible

  Add compatible string for Qualcomm spidev device (used for QCA4024).

Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
---
 drivers/spi/spidev.c | 2 ++
 1 file changed, 2 insertions(+)
  

On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
> Add compatible string for Qualcomm spidev device (used for QCA4024).

> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
>  	{ .name = "spi-authenta" },
>  	{ .name = "em3581" },
>  	{ .name = "si3210" },
> +	{ .name = "spidev" },
>  	{},

Why?

>  	{ .compatible = "lwn,bk4", .data = &spidev_of_check },
>  	{ .compatible = "menlo,m53cpld", .data = &spidev_of_check },
>  	{ .compatible = "micron,spi-authenta", .data = &spidev_of_check },
> +	{ .compatible = "qca,spidev", .data = &spidev_of_check },

No, this needs to correspond to the hardware being controlled via spidev
not to an implementation detail.  Any new compatibles also need to be
documented.

I'm also missing patch 2 of this series so don't know what's going on
there.
  

On Tue, Feb 06, 2024 at 02:01:27PM +0100, frut3k7 wrote:
> On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:

> > > +     { .compatible = "qca,spidev", .data = &spidev_of_check },

> > No, this needs to correspond to the hardware being controlled via spidev
> > not to an implementation detail.  Any new compatibles also need to be
> > documented.

> The device for which I want to add compatibility is originally used in the
> router and this is what the dts fragment looks like:

> 
>       spi@3 {
>         compatible = "qca,spidev";
>         reg = <0x00>;
>         spi-max-frequency = <0x16e3600>;
>       };
>     };

> According to this commit, Qualcomm use this compatibility:
> https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2

This is out of tree, it's not exactly a good guide for mainline.  The DT
should describe the hardware, not how some particular software stack
chooses to drive it.

> > I'm also missing patch 2 of this series so don't know what's going on
> > there.

> The second patch was sent only to the devicetree bindings project:
> https://lore.kernel.org/all/20240205191828.998783-1-frut3k7@gmail.com/
> It's probably done wrong...

You should send the bindings change along with the driver change, they
usually get merged together.
  

On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
> > Add compatible string for Qualcomm spidev device (used for QCA4024).
>
> > --- a/drivers/spi/spidev.c
> > +++ b/drivers/spi/spidev.c
> > @@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
> >       { .name = "spi-authenta" },
> >       { .name = "em3581" },
> >       { .name = "si3210" },
> > +     { .name = "spidev" },
> >       {},
>
> Why?
>
> >       { .compatible = "lwn,bk4", .data = &spidev_of_check },
> >       { .compatible = "menlo,m53cpld", .data = &spidev_of_check },
> >       { .compatible = "micron,spi-authenta", .data = &spidev_of_check },
> > +     { .compatible = "qca,spidev", .data = &spidev_of_check },
>
> No, this needs to correspond to the hardware being controlled via spidev
> not to an implementation detail.  Any new compatibles also need to be
> documented.


The device for which I want to add compatibility is originally used in
the router and this is what the dts fragment looks like:

    spi@78b8000 {
      #address-cells = <0x01>;
      #size-cells = <0x00>;
      clock-names = "core\0iface";
      clocks = <0x03 0x5c 0x03 0x54>;
      compatible = "qcom,spi-qup-v2.2.1";
      cs-select = <0x02>;
      dma-names = "tx\0rx";
      dmas = <0x06 0x12 0x06 0x13>;
      interrupts = <0x00 0x62 0x00>;
      pinctrl-0 = <0x08>;
      pinctrl-names = "default";
      quartz-reset-gpio = <0x09 0x15 0x01>;
      reg = <0x78b8000 0x600>;
      spi-max-frequency = <0x2faf080>;
      status = "ok";

      spi@3 {
        compatible = "qca,spidev";
        reg = <0x00>;
        spi-max-frequency = <0x16e3600>;
      };
    };

The first part has already been added:
https://lore.kernel.org/all/20231123121324.1046164-1-robimarko@gmail.com/

According to this commit, Qualcomm use this compatibility:
https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2

>
> I'm also missing patch 2 of this series so don't know what's going on
> there.


The second patch was sent only to the devicetree bindings project:
https://lore.kernel.org/all/20240205191828.998783-1-frut3k7@gmail.com/
It's probably done wrong...
  

On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 06, 2024 at 02:01:27PM +0100, frut3k7 wrote:
> > On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
>
> > > > +     { .compatible = "qca,spidev", .data = &spidev_of_check },
>
> > > No, this needs to correspond to the hardware being controlled via spidev
> > > not to an implementation detail.  Any new compatibles also need to be
> > > documented.
>
> > The device for which I want to add compatibility is originally used in the
> > router and this is what the dts fragment looks like:
>
> >
> >       spi@3 {
> >         compatible = "qca,spidev";
> >         reg = <0x00>;
> >         spi-max-frequency = <0x16e3600>;
> >       };
> >     };
>
> > According to this commit, Qualcomm use this compatibility:
> > https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2
>
> This is out of tree, it's not exactly a good guide for mainline.  The DT
> should describe the hardware, not how some particular software stack
> chooses to drive it.
>
Will changing from "spidev" to "qca4024" be enough?

> > > I'm also missing patch 2 of this series so don't know what's going on
> > > there.
>
> > The second patch was sent only to the devicetree bindings project:
> > https://lore.kernel.org/all/20240205191828.998783-1-frut3k7@gmail.com/
> > It's probably done wrong...
>
> You should send the bindings change along with the driver change, they
> usually get merged together.
  

On Tue, Feb 06, 2024 at 02:57:49PM +0100, frut3k7 wrote:
> On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <broonie@kernel.org> wrote:

> > This is out of tree, it's not exactly a good guide for mainline.  The DT
> > should describe the hardware, not how some particular software stack
> > chooses to drive it.

> Will changing from "spidev" to "qca4024" be enough?

Should be I think.
  

On Tue, Feb 6, 2024 at 3:10 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 06, 2024 at 02:57:49PM +0100, frut3k7 wrote:
> > On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > This is out of tree, it's not exactly a good guide for mainline.  The DT
> > > should describe the hardware, not how some particular software stack
> > > chooses to drive it.
>
> > Will changing from "spidev" to "qca4024" be enough?
>
> Should be I think.

Should both patches (spi and devicetree) be sent to two projects
(Linux SPI and Devicetree Bindings)?
  

On Tue, Feb 06, 2024 at 05:48:04PM +0100, frut3k7 wrote:

> Should both patches (spi and devicetree) be sent to two projects
> (Linux SPI and Devicetree Bindings)?

Yes.
  

On 07/02/2024 23:45, Paweł Owoc wrote:
> Add Qualcomm QCA4024 to trivial devices.
> 
> Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
> ---
>  Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 79dcd92c4a43..c6362e981920 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -309,6 +309,8 @@ properties:
>            - plx,pex8648
>              # Pulsedlight LIDAR range-finding sensor
>            - pulsedlight,lidar-lite-v2
> +            # Qualcomm QCA4024 Multi-mode Bluetooth and 802.15.4 SoC
> +          - qca,qca4024


As I wrote, Bluetooth chip is not a trivial device. This one
particular exposes several interfaces to the host, needs a clock and
power supply.

Best regards,
Krzysztof
  

On 15/02/2024 23:01, frut3k7 wrote:
> The device I use has the QCA4024 chip connected via the spi controller:
>         blsp1_spi4: spi@78b8000 {
>             compatible = "qcom,spi-qup-v2.2.1";
>             #address-cells = <1>;
>             #size-cells = <0>;
>             reg = <0x78b8000 0x600>;
>             interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
>             clocks = <&gcc GCC_BLSP1_QUP4_SPI_APPS_CLK>,
>                  <&gcc GCC_BLSP1_AHB_CLK>;
>             clock-names = "core", "iface";
>             dmas = <&blsp_dma 18>, <&blsp_dma 19>;
>             dma-names = "tx", "rx";
>             status = "disabled";
>         };
> 
> and apart from setting the frequency and gpio there is nothing else:
>         &blsp1_spi4 {
>             status = "okay";
> 
>             pinctrl-0 = <&spi_3_pins &quartz_pins>;
>             pinctrl-names = "default";
> 
>             /* Qualcomm QCA4024 IoT */
>             iot@3 {
>                 compatible = "qca,qca4024";
>                 reg = <0>;
>                 spi-max-frequency = <24000000>;

That's your downstream or fork DTS, not hardware description. You could
have several regulators not listed here, because your downstream has
always-on, or clocks which are not taken and works due to
assigned-clocks in other places... Sorry, that's not an argument. Never
use downstream DTS as proof how hardware looks. It is usually dis-proof,
that things are certainly missing.

Best regards,
Krzysztof
  

On 16/02/2024 14:39, Paweł Owoc wrote:
> To be clear, I don't want to add support for the QCA4024, I just want
> to use this SoC with its own firmware connected to another SoC
> (IPQ8072A) via spi.

I know and this does not change what I told you days ago: this is not a
trivial device, IMO. Please open the schematics or datasheet and check
its pins.

Best regards,
Krzysztof
  

On 16/02/2024 15:47, Krzysztof Kozlowski wrote:
> On 16/02/2024 14:39, Paweł Owoc wrote:
>> To be clear, I don't want to add support for the QCA4024, I just want
>> to use this SoC with its own firmware connected to another SoC
>> (IPQ8072A) via spi.
> 
> I know and this does not change what I told you days ago: this is not a
> trivial device, IMO. Please open the schematics or datasheet and check
> its pins.

To clarify: this is not a trivial, but "regular" device, so I expect
standalone binding and at least some basic check whether devices has
additional resources.

Best regards,
Krzysztof
  

On 17/02/2024 11:55, Paweł Owoc wrote:
> On Sat, Feb 17, 2024 at 11:31 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 17/02/2024 11:29, Paweł Owoc wrote:
>>> Can you point me to some example?
>>
>> Please stop top-posting. I really have no clue what you want here and
>> what you are referring to.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Is any bluetooth device connected via spi already supported?

No clue, we have thousands (~5k) of independent schema files. If you ask
about SPI devices, there are plenty as an examples. git grep for
spi-peripheral-props.

Best regards,
Krzysztof