spi: s3c64xx: use "cs-gpios" in spi node instead of "cs-gpio"

Currently, spi-s3c64xx.c needs "cs-gpio" chip select GPIO to be defined under "controller-data" node under each slave node.

&spi_x {
	cs-gpios <>;
	...
	slave_node {

		controller-data {
			cs-gpio = <>;
			...
		};
		...
	};
	...
};

Where as, SPI core and many other drivers uses "cs-gpios" for from device tree node.

Hence, make changes in spi-s3c64xx.c driver to make use of "cs-gpios" from SPI node(parent) instead of "cs-gpio" defined in slaves "controller-data"(child) node.

Also updates the Device tree Documentation.

Signed-off-by Naveen Krishna Chatradhi <[email protected]>

Cc Javier Martinez Canillas <[email protected]>

Cc Doug Anderson <[email protected]>

---
Changes since v1:
1. fixed a compilation warning thus squashing the other patch into this.
2. Updated device tree description in spi-samsung.txt

 .../devicetree/bindings/spi/spi-samsung.txt        |    8 ++-
 drivers/spi/spi-s3c64xx.c                          |   56 ++++++++++++--------
 2 files changed, 38 insertions(+), 26 deletions(-)

Documentation/devicetree/bindings/spi/spi-samsung.txt +2 -4

index 86aa061..13bfcb5 100644
@@ -42,15 +42,13 @@ Optional Board Specific Properties:
 - num-cs: Specifies the number of chip select lines supported. If
   not specified, the default number of chip select lines is set to 1.
 
+- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt)
+
 SPI Controller specific data in SPI slave nodes:
 
 - The spi slave nodes should provide the following information which is required
   by the spi controller.
 
-  - cs-gpio: A gpio specifier that specifies the gpio line used as
-    the slave select line by the spi controller. The format of the gpio
-    specifier depends on the gpio controller.
-
   - samsung,spi-feedback-delay: The sampling phase shift to be applied on the
     miso line (to account for any lag in the miso line). The following are the
     valid values.

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -1

 		w25q80bw at 0 {
 			#address-cells = <1>;

@@ -94,7 +93,6 @@ Example:
 			spi-max-frequency = <10000>;
 
 			controller-data {
-				cs-gpio = <&gpa2 5 1 0 3>;
 				samsung,spi-feedback-delay = <0>;
 			};
 

drivers/spi/spi-s3c64xx.c +24 -11

index 75a5696..4594dde 100644
@@ -750,47 +750,56 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
 }
 
 static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
-				struct spi_device *spi)
+				struct spi_device *spi,
+				struct s3c64xx_spi_csinfo *cs)
 {
-	struct s3c64xx_spi_csinfo *cs;
-	struct device_node *slave_np, *data_np = NULL;
-	struct s3c64xx_spi_driver_data *sdd;
+	struct device_node *data_np = NULL;
 	u32 fb_delay = 0;
 
-	sdd = spi_master_get_devdata(spi->master);
-	slave_np = spi->dev.of_node;
-	if (!slave_np) {
-		dev_err(&spi->dev, "device node not found\n");
+	data_np = of_get_child_by_name(spi->dev.of_node, "controller-data");
+	if (!data_np) {
+		dev_err(&spi->dev, "child node 'controller-data' not found\n");
 		return ERR_PTR(-EINVAL);
 	}
 
-	data_np = of_get_child_by_name(slave_np, "controller-data");
-	if (!data_np) {
-		dev_err(&spi->dev, "child node 'controller-data' not found\n");
+	of_property_read_u32(data_np, "samsung,spi-feedback-delay", &fb_delay);
+	cs->fb_delay = fb_delay;
+	of_node_put(data_np);
+
+	return cs;
+}
+
+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)
+{
+	struct device_node *parent_np = NULL;
+	struct s3c64xx_spi_driver_data *sdd;
+	struct s3c64xx_spi_csinfo *cs;
+
+	parent_np = of_get_parent(spi->dev.of_node);
+	if (!parent_np) {
+		dev_err(&spi->dev, "Parent node not found\n");
 		return ERR_PTR(-EINVAL);
 	}
 
+	sdd = spi_master_get_devdata(spi->master);
+
 	cs = kzalloc(sizeof(*cs), GFP_KERNEL);

drivers/spi/spi-s3c64xx.c +8 -7

 	if (!gpio_is_valid(cs->line)) {
 		dev_err(&spi->dev, "chip select gpio is not specified or invalid\n");
-		kfree(cs);
-		of_node_put(data_np);
+		of_node_put(parent_np);
 		return ERR_PTR(-EINVAL);
 	}
 
-	of_property_read_u32(data_np, "samsung,spi-feedback-delay", &fb_delay);
-	cs->fb_delay = fb_delay;
-	of_node_put(data_np);
-	return cs;
+	return s3c64xx_get_slave_ctrldata(spi, cs);
 }
 
 /*

@@ -806,9 +815,14 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 	struct s3c64xx_spi_info *sci;
 	int err;
 
+	if (!spi->dev.of_node) {
+		dev_err(&spi->dev, "device node not found\n");
+		return -EINVAL;
+	}
+
 	sdd = spi_master_get_devdata(spi->master);
 	if (!cs && spi->dev.of_node) {
-		cs = s3c64xx_get_slave_ctrldata(spi);
+		cs = s3c64xx_get_cs_gpios(spi);
 		spi->controller_data = cs;
 	}
 

Quoted 53 lines · Naveen Krishna Chatradhi

Currently, spi-s3c64xx.c needs "cs-gpio" chip select GPIO to be defined under "controller-data" node under each slave node.

&spi_x {
      cs-gpios <>;
      ...
      slave_node {

              controller-data {
                      cs-gpio = <>;
                      ...
              };
              ...
      };
      ...
};

Where as, SPI core and many other drivers uses "cs-gpios" for from device tree node.

Hence, make changes in spi-s3c64xx.c driver to make use of "cs-gpios" from SPI node(parent) instead of "cs-gpio" defined in slaves "controller-data"(child) node.

Also updates the Device tree Documentation.

Signed-off-by Naveen Krishna Chatradhi <[email protected]>

Cc Javier Martinez Canillas <[email protected]>

Cc Doug Anderson <[email protected]>

---
Changes since v1:
1. fixed a compilation warning thus squashing the other patch into this.
2. Updated device tree description in spi-samsung.txt

 .../devicetree/bindings/spi/spi-samsung.txt        |    8 ++-
 drivers/spi/spi-s3c64xx.c                          |   56 ++++++++++++--------
 2 files changed, 38 insertions(+), 26 deletions(-)

Documentation/devicetree/bindings/spi/spi-samsung.txt +2 -0

index 86aa061..13bfcb5 100644
@@ -42,15 +42,13 @@ Optional Board Specific Properties:
 - num-cs: Specifies the number of chip select lines supported. If
   not specified, the default number of chip select lines is set to 1.
 
+- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt)
+
 SPI Controller specific data in SPI slave nodes:
 
 - The spi slave nodes should provide the following information which is required
   by the spi controller.
 

Documentation/devicetree/bindings/spi/spi-samsung.txt Example: · line 86

Quoted 12 lines

Documentation/devicetree/bindings/spi/spi-samsung.txt +1 -4

-  - cs-gpio: A gpio specifier that specifies the gpio line used as
-    the slave select line by the spi controller. The format of the gpio
-    specifier depends on the gpio controller.
-
   - samsung,spi-feedback-delay: The sampling phase shift to be applied on the
     miso line (to account for any lag in the miso line). The following are the
     valid values.

@@ -85,6 +83,7 @@ Example:
              #size-cells = <0>;
              pinctrl-names = "default";
              pinctrl-0 = <&spi0_bus>;
+             cs-gpios = <&gpa2 5 1 0 3>;

While at it, please change the GPIO specifier format, this one is not valid any more.

Quoted 70 lines

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -1

              w25q80bw at 0 {
                      #address-cells = <1>;

@@ -94,7 +93,6 @@ Example:
                      spi-max-frequency = <10000>;
 
                      controller-data {
-                             cs-gpio = <&gpa2 5 1 0 3>;
                              samsung,spi-feedback-delay = <0>;
                      };
 

drivers/spi/spi-s3c64xx.c +25 -12

index 75a5696..4594dde 100644
@@ -750,47 +750,56 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
 }
 
 static struct s3c64xx_spi_csinfo *s3c64xx_get_slave_ctrldata(
-                             struct spi_device *spi)
+                             struct spi_device *spi,
+                             struct s3c64xx_spi_csinfo *cs)
 {
-     struct s3c64xx_spi_csinfo *cs;
-     struct device_node *slave_np, *data_np = NULL;
-     struct s3c64xx_spi_driver_data *sdd;
+     struct device_node *data_np = NULL;
      u32 fb_delay = 0;
 
-     sdd = spi_master_get_devdata(spi->master);
-     slave_np = spi->dev.of_node;
-     if (!slave_np) {
-             dev_err(&spi->dev, "device node not found\n");
+     data_np = of_get_child_by_name(spi->dev.of_node, "controller-data");
+     if (!data_np) {
+             dev_err(&spi->dev, "child node 'controller-data' not found\n");
              return ERR_PTR(-EINVAL);
      }
 
-     data_np = of_get_child_by_name(slave_np, "controller-data");
-     if (!data_np) {
-             dev_err(&spi->dev, "child node 'controller-data' not found\n");
+     of_property_read_u32(data_np, "samsung,spi-feedback-delay", &fb_delay);
+     cs->fb_delay = fb_delay;
+     of_node_put(data_np);
+
+     return cs;
+}
+
+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)
+{
+     struct device_node *parent_np = NULL;
+     struct s3c64xx_spi_driver_data *sdd;
+     struct s3c64xx_spi_csinfo *cs;
+
+     parent_np = of_get_parent(spi->dev.of_node);
+     if (!parent_np) {
+             dev_err(&spi->dev, "Parent node not found\n");
              return ERR_PTR(-EINVAL);
      }
 
+     sdd = spi_master_get_devdata(spi->master);
+
      cs = kzalloc(sizeof(*cs), GFP_KERNEL);
      if (!cs) {
-             of_node_put(data_np);
+             of_node_put(parent_np);
              return ERR_PTR(-ENOMEM);
      }
 

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_transfer_one(struct spi_master *master, · line 794

Quoted 4 lines

drivers/spi/spi-s3c64xx.c +1 -1

      /* The CS line is asserted/deasserted by the gpio pin */
      if (sdd->cs_gpio)
-             cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+             cs->line = of_get_named_gpio(parent_np, "cs-gpios", 0);

Can we support both "cs-gpio" and "cs-gpios" for backward compatibility ? After your change all DTBs using the original pattern will not work with new kernels any more. At least I would expect such backward compatibility maintained for few kernel releases.

Quoted 33 lines

drivers/spi/spi-s3c64xx.c +8 -7

      if (!gpio_is_valid(cs->line)) {
              dev_err(&spi->dev, "chip select gpio is not specified or invalid\n");
-             kfree(cs);
-             of_node_put(data_np);
+             of_node_put(parent_np);
              return ERR_PTR(-EINVAL);
      }
 
-     of_property_read_u32(data_np, "samsung,spi-feedback-delay", &fb_delay);
-     cs->fb_delay = fb_delay;
-     of_node_put(data_np);
-     return cs;
+     return s3c64xx_get_slave_ctrldata(spi, cs);
 }
 
 /*

@@ -806,9 +815,14 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
      struct s3c64xx_spi_info *sci;
      int err;
 
+     if (!spi->dev.of_node) {
+             dev_err(&spi->dev, "device node not found\n");
+             return -EINVAL;
+     }
+
      sdd = spi_master_get_devdata(spi->master);
      if (!cs && spi->dev.of_node) {
-             cs = s3c64xx_get_slave_ctrldata(spi);
+             cs = s3c64xx_get_cs_gpios(spi);
              spi->controller_data = cs;
      }
 

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_probe(struct platform_device *pdev) · line 1095

Quoted 7 lines

drivers/spi/spi-s3c64xx.c +1 -1

@@ -1077,7 +1091,7 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
      sdd->sfr_start = mem_res->start;
      sdd->cs_gpio = true;
      if (pdev->dev.of_node) {
-             if (!of_find_property(pdev->dev.of_node, "cs-gpio", NULL))
+             if (!of_find_property(pdev->dev.of_node, "cs-gpios", NULL))
                      sdd->cs_gpio = false;

Ditto.

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_probe(struct platform_device *pdev) · line 1097

Quoted 2 lines

drivers/spi/spi-s3c64xx.c +0 -0

              ret = of_alias_get_id(pdev->dev.of_node, "spi");

--
Thanks!
Sylwester

Quoted 4 lines

Can we support both "cs-gpio" and "cs-gpios" for backward compatibility ? After your change all DTBs using the original pattern will not work with new kernels any more. At least I would expect such backward compatibility maintained for few kernel releases.

The reason behind removing the "cs-gpio" or not providing backward compatibility was

1. Since spi-core started using "cs-gpios" string from spi device node several months ago.
The spi-s3c64xx.c driver is partially broken for more than 6 months.

2. Supporting "cs-gpio" would add extra bit of code.

I've corrected the dts files that were using "cs-gpio" under "controller-data"(child node)
to use "cs-gpio" from spi device node (parent node).

I will make another version if you insist.

Naveen / Sylwester,

Quoted 12 lines · Naveen Krishna Ch

Quoted 4 lines

Can we support both "cs-gpio" and "cs-gpios" for backward compatibility ? After your change all DTBs using the original pattern will not work with new kernels any more. At least I would expect such backward compatibility maintained for few kernel releases.

The reason behind removing the "cs-gpio" or not providing backward compatibility was

1. Since spi-core started using "cs-gpios" string from spi device node several months ago.
The spi-s3c64xx.c driver is partially broken for more than 6 months.

Quoted 7 lines

2. Supporting "cs-gpio" would add extra bit of code.

I've corrected the dts files that were using "cs-gpio" under "controller-data"(child node)
to use "cs-gpio" from spi device node (parent node).

I will make another version if you insist.

Yup, as near as I can tell this has been broken since (3146bee spi:
s3c64xx: Added provision for dedicated cs pin). That landed June 25th of 2013 into the SPI tree.

...so clearly nobody was really testing Samsung's SPI driver on ToT Linux. 1 year of unnoticed brokenness seems like enough time that we could do away with the old code. If someone comes out of the woodwork and claims a dire need to support the old binding then it can be added then.

In-tree users of this appear to be:

arch/arm/boot/dts/exynos4210-smdkv310.dts:
cs-gpio = <&gpc1 2 0>;
arch/arm/boot/dts/exynos4412-trats2.dts:
cs-gpio = <&gpb 5 0>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:
cs-gpio = <&gpa2 5 0>;

...and I guess nobody has bothered using the SPI flash on those boards for the last year?

Naveen / Sylwester,

Quoted 12 lines · Naveen Krishna Ch

Quoted 4 lines

Can we support both "cs-gpio" and "cs-gpios" for backward compatibility ? After your change all DTBs using the original pattern will not work with new kernels any more. At least I would expect such backward compatibility maintained for few kernel releases.

The reason behind removing the "cs-gpio" or not providing backward compatibility was

1. Since spi-core started using "cs-gpios" string from spi device node several months ago.
The spi-s3c64xx.c driver is partially broken for more than 6 months.

Quoted 7 lines

2. Supporting "cs-gpio" would add extra bit of code.

I've corrected the dts files that were using "cs-gpio" under "controller-data"(child node)
to use "cs-gpio" from spi device node (parent node).

I will make another version if you insist.

Yup, as near as I can tell this has been broken since (3146bee spi:
s3c64xx: Added provision for dedicated cs pin). That landed June 25th of 2013 into the SPI tree.

...so clearly nobody was really testing Samsung's SPI driver on ToT Linux. 1 year of unnoticed brokenness seems like enough time that we could do away with the old code. If someone comes out of the woodwork and claims a dire need to support the old binding then it can be added then.

In-tree users of this appear to be:

arch/arm/boot/dts/exynos4210-smdkv310.dts:
cs-gpio = <&gpc1 2 0>;
arch/arm/boot/dts/exynos4412-trats2.dts:
cs-gpio = <&gpb 5 0>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:
cs-gpio = <&gpa2 5 0>;

...and I guess nobody has bothered using the SPI flash on those boards for the last year?

Quoted 16 lines · Doug Anderson

Naveen / Sylwester,

Quoted 12 lines · Naveen Krishna Ch

Quoted 4 lines

Can we support both "cs-gpio" and "cs-gpios" for backward compatibility ? After your change all DTBs using the original pattern will not work with new kernels any more. At least I would expect such backward compatibility maintained for few kernel releases.

The reason behind removing the "cs-gpio" or not providing backward compatibility was

1. Since spi-core started using "cs-gpios" string from spi device node several months ago.
The spi-s3c64xx.c driver is partially broken for more than 6 months.

Quoted 5 lines

Quoted 5 lines

2. Supporting "cs-gpio" would add extra bit of code.

I've corrected the dts files that were using "cs-gpio" under "controller-data"(child node)
to use "cs-gpio" from spi device node (parent node).

Quoted 1 line

Quoted 1 line

I will make another version if you insist.

Quoted 19 lines

Yup, as near as I can tell this has been broken since (3146bee spi:
s3c64xx: Added provision for dedicated cs pin). That landed June 25th of 2013 into the SPI tree.

...so clearly nobody was really testing Samsung's SPI driver on ToT Linux. 1 year of unnoticed brokenness seems like enough time that we could do away with the old code. If someone comes out of the woodwork and claims a dire need to support the old binding then it can be added then.

In-tree users of this appear to be:

arch/arm/boot/dts/exynos4210-smdkv310.dts:
cs-gpio = <&gpc1 2 0>;
arch/arm/boot/dts/exynos4412-trats2.dts:
cs-gpio = <&gpb 5 0>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:
cs-gpio = <&gpa2 5 0>;

Quoted 2 lines

...and I guess nobody has bothered using the SPI flash on those boards for the last year?

I always try to warn people if they are breaking compatibility, but in this case I agree it is okay. Presumably no one expects BSD or vxworks support for this platform either?

For the binding change:

Acked-by Rob Herring <[email protected]>

Rob

Naveen,

Not a full review, but a few quick things I happened to notice:

Documentation/devicetree/bindings/spi/spi-samsung.txt Example: · line 96

Quoted 6 lines · Naveen Krishna Chatradhi

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -1

@@ -94,7 +93,6 @@ Example:
                        spi-max-frequency = <10000>;
 
                        controller-data {
-                               cs-gpio = <&gpa2 5 1 0 3>;
                                samsung,spi-feedback-delay = <0>;

In a future patch (not this one!) it might make sense to also move spi-feedback-delay out.

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_transfer_one(struct spi_master *master, · line 772

Quoted 1 line

drivers/spi/spi-s3c64xx.c +1 -0

+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)

I believe that you can make use of the fact that the SPI core already got these GPIOs for you. See of_spi_register_master(). Everything you need ought to be in master->num_chipselect and master->cs_gpios.

Strangely, it doesn't look like any other drivers use this, so possibly I'm confused...

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_setup(struct spi_device *spi) · line 821

Quoted 8 lines

drivers/spi/spi-s3c64xx.c +4 -0

@@ -806,9 +815,14 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
        struct s3c64xx_spi_info *sci;
        int err;
 
+       if (!spi->dev.of_node) {
+               dev_err(&spi->dev, "device node not found\n");
+               return -EINVAL;
+       }

This seems incredibly broken. You're saying that the SPI driver no longer works without the device tree? I don't think that's desirable, but I suppose I could be wrong.

Also note that you still left an "if" test below for trying to deal with the fact that there is no "of_node".

Naveen,

Not a full review, but a few quick things I happened to notice:

Quoted 3 lines · Naveen Krishna Chatradhi

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -0

@@ -94,7 +93,6 @@ Example:
                        spi-max-frequency = <10000>;
 

Documentation/devicetree/bindings/spi/spi-samsung.txt Example: · line 96

Quoted 3 lines

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -1

                        controller-data {
-                               cs-gpio = <&gpa2 5 1 0 3>;
                                samsung,spi-feedback-delay = <0>;

In a future patch (not this one!) it might make sense to also move spi-feedback-delay out.

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_transfer_one(struct spi_master *master, · line 772

Quoted 3 lines

drivers/spi/spi-s3c64xx.c +1 -0

+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)

I believe that you can make use of the fact that the SPI core already got these GPIOs for you. See of_spi_register_master(). Everything you need ought to be in master->num_chipselect and master->cs_gpios.

Strangely, it doesn't look like any other drivers use this, so possibly I'm confused...

Quoted 4 lines

drivers/spi/spi-s3c64xx.c +0 -0

@@ -806,9 +815,14 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
        struct s3c64xx_spi_info *sci;
        int err;
 

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_setup(struct spi_device *spi) · line 821

Quoted 4 lines

drivers/spi/spi-s3c64xx.c +4 -0

+       if (!spi->dev.of_node) {
+               dev_err(&spi->dev, "device node not found\n");
+               return -EINVAL;
+       }

This seems incredibly broken. You're saying that the SPI driver no longer works without the device tree? I don't think that's desirable, but I suppose I could be wrong.

Also note that you still left an "if" test below for trying to deal with the fact that there is no "of_node".

-Doug

Currently, spi-s3c64xx.c needs "cs-gpio" chip select GPIO to be defined under "controller-data" node under each slave node.

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -0

 		w25q80bw at 0 {
 			#address-cells = <1>;

drivers/spi/spi-s3c64xx.c +11 -0

+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)
+{
+	struct device_node *parent_np = NULL;
+	struct s3c64xx_spi_driver_data *sdd;
+	struct s3c64xx_spi_csinfo *cs;
+
+	parent_np = of_get_parent(spi->dev.of_node);
+	if (!parent_np) {
+		dev_err(&spi->dev, "Parent node not found\n");
 		return ERR_PTR(-EINVAL);
 	}
 
+	sdd = spi_master_get_devdata(spi->master);
+
 	cs = kzalloc(sizeof(*cs), GFP_KERNEL);

This is wrong. The "cs-gpios" property is supposed to be an array, indexed by chip select number of SPI devices (indicated by their "reg" properties).

Moreover, is there a need to parse this manually in this driver? I can see respective parsing code in of_spi_register_master().

Tomasz,

Quoted 4 lines · Tomasz Figa

This is wrong. The "cs-gpios" property is supposed to be an array, indexed by chip select number of SPI devices (indicated by their "reg" properties).

Quoted 2 lines

Moreover, is there a need to parse this manually in this driver? I can see respective parsing code in of_spi_register_master().

I noticed this too (see my response), but I was confused about the fact that nobody else uses the array created by of_spi_register_master(). Any idea why?

Quoted 7 lines · Doug Anderson

Tomasz,

Quoted 4 lines · Tomasz Figa

This is wrong. The "cs-gpios" property is supposed to be an array, indexed by chip select number of SPI devices (indicated by their "reg" properties).

Quoted 6 lines

Quoted 2 lines

Moreover, is there a need to parse this manually in this driver? I can see respective parsing code in of_spi_register_master().

I noticed this too (see my response), but I was confused about the fact that nobody else uses the array created by of_spi_register_master(). Any idea why?

Hmm, I can see of_spi_register_master() assigning allocated pointer to master->cs_gpios, which is then used in spi_add_device() as follows:

        if (master->cs_gpios)
                spi->cs_gpio = master->cs_gpios[spi->chip_select];

Hi Naveen,

Quoted 2 lines · Naveen Krishna Chatradhi

Currently, spi-s3c64xx.c needs "cs-gpio" chip select GPIO to be defined under "controller-data" node under each slave node.

[snip]

Documentation/devicetree/bindings/spi/spi-samsung.txt Example: · line 86

Quoted 5 lines

Documentation/devicetree/bindings/spi/spi-samsung.txt +1 -0

@@ -85,6 +83,7 @@ Example:
              #size-cells = <0>;
              pinctrl-names = "default";
              pinctrl-0 = <&spi0_bus>;
+             cs-gpios = <&gpa2 5 1 0 3>;

While at it, you might also update the example to something more appropriate on Samsung platforms, e.g. <&gpa2 5 0>;

Quoted 4 lines

Documentation/devicetree/bindings/spi/spi-samsung.txt +0 -0

              w25q80bw at 0 {
                      #address-cells = <1>;

[snip]

Quoted 15 lines

drivers/spi/spi-s3c64xx.c +11 -0

+static struct s3c64xx_spi_csinfo *s3c64xx_get_cs_gpios(struct spi_device *spi)
+{
+     struct device_node *parent_np = NULL;
+     struct s3c64xx_spi_driver_data *sdd;
+     struct s3c64xx_spi_csinfo *cs;
+
+     parent_np = of_get_parent(spi->dev.of_node);
+     if (!parent_np) {
+             dev_err(&spi->dev, "Parent node not found\n");
              return ERR_PTR(-EINVAL);
      }
 
+     sdd = spi_master_get_devdata(spi->master);
+
      cs = kzalloc(sizeof(*cs), GFP_KERNEL);

drivers/spi/spi-s3c64xx.c static int s3c64xx_spi_transfer_one(struct spi_master *master, · line 794

Quoted 10 lines

drivers/spi/spi-s3c64xx.c +2 -2

      if (!cs) {
-             of_node_put(data_np);
+             of_node_put(parent_np);
              return ERR_PTR(-ENOMEM);
      }
 
      /* The CS line is asserted/deasserted by the gpio pin */
      if (sdd->cs_gpio)
-             cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+             cs->line = of_get_named_gpio(parent_np, "cs-gpios", 0);

This is wrong. The "cs-gpios" property is supposed to be an array, indexed by chip select number of SPI devices (indicated by their "reg" properties).

Moreover, is there a need to parse this manually in this driver? I can see respective parsing code in of_spi_register_master().

Best regards,
Tomasz