[PATCH v3 0/4] spi: bcm63xx: add BMIPS support

[PATCH v3 0/4] spi: bcm63xx: add BMIPS support

[Álvaro Fernández Rojas]

BCM63xx SPI and HSSPI controller are present on several BMIPS SoCs (BCM6318,
BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268).

v3: use devm_reset_control_get_optional_exclusive
v2: use devm_reset_control_get_exclusive

Álvaro Fernández Rojas (4):
  spi: bcm63xx-spi: add reset support
  spi: bcm63xx-spi: allow building for BMIPS
  spi: bcm63xx-hsspi: add reset support
  spi: bcm63xx-hsspi: allow building for BMIPS

 drivers/spi/Kconfig             |  4 ++--
 drivers/spi/spi-bcm63xx-hsspi.c | 17 +++++++++++++++++
 drivers/spi/spi-bcm63xx.c       | 17 +++++++++++++++++
 3 files changed, 36 insertions(+), 2 deletions(-)

-- 
2.27.0

[PATCH v3 1/4] spi: bcm63xx-spi: add reset support

[Álvaro Fernández Rojas]

bcm63xx arch resets the SPI controller at early boot. However, bmips arch
needs to perform a reset when probing the driver.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 v3: use devm_reset_control_get_optional_exclusive
 v2: use devm_reset_control_get_exclusive

 drivers/spi/spi-bcm63xx.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
index 0f1b10a4ef0c..92e88901189c 100644
--- a/drivers/spi/spi-bcm63xx.c
+++ b/drivers/spi/spi-bcm63xx.c
@@ -18,6 +18,7 @@
 #include <linux/err.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
+#include <linux/reset.h>
 
 /* BCM 6338/6348 SPI core */
 #define SPI_6348_RSET_SIZE		64
@@ -493,6 +494,7 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
 	struct bcm63xx_spi *bs;
 	int ret;
 	u32 num_cs = BCM63XX_SPI_MAX_CS;
+	struct reset_control *reset;
 
 	if (dev->of_node) {
 		const struct of_device_id *match;
@@ -529,6 +531,15 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
 		return PTR_ERR(clk);
 	}
 
+	reset = devm_reset_control_get_optional_exclusive(dev, NULL);
+	if (IS_ERR(reset)) {
+		ret = PTR_ERR(reset);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev,
+				"failed to get reset controller: %d\n", ret);
+		return ret;
+	}
+
 	master = spi_alloc_master(dev, sizeof(*bs));
 	if (!master) {
 		dev_err(dev, "out of memory\n");
@@ -579,6 +590,12 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
 	if (ret)
 		goto out_err;
 
+	ret = reset_control_reset(reset);
+	if (ret) {
+		dev_err(dev, "unable to reset device: %d\n", ret);
+		goto out_clk_disable;
+	}
+
 	bcm_spi_writeb(bs, SPI_INTR_CLEAR_ALL, SPI_INT_STATUS);
 
 	/* register and we are done */
-- 
2.27.0

Re: [PATCH v3 1/4] spi: bcm63xx-spi: add reset support

[Florian Fainelli]

On 6/16/2020 12:02 AM, Álvaro Fernández Rojas wrote:
> bcm63xx arch resets the SPI controller at early boot. However, bmips arch
> needs to perform a reset when probing the driver.
> 
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
>  v3: use devm_reset_control_get_optional_exclusive
>  v2: use devm_reset_control_get_exclusive
> 
>  drivers/spi/spi-bcm63xx.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
> index 0f1b10a4ef0c..92e88901189c 100644
> --- a/drivers/spi/spi-bcm63xx.c
> +++ b/drivers/spi/spi-bcm63xx.c
> @@ -18,6 +18,7 @@
>  #include <linux/err.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/of.h>
> +#include <linux/reset.h>
>  
>  /* BCM 6338/6348 SPI core */
>  #define SPI_6348_RSET_SIZE		64
> @@ -493,6 +494,7 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
>  	struct bcm63xx_spi *bs;
>  	int ret;
>  	u32 num_cs = BCM63XX_SPI_MAX_CS;
> +	struct reset_control *reset;
>  
>  	if (dev->of_node) {
>  		const struct of_device_id *match;
> @@ -529,6 +531,15 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
>  		return PTR_ERR(clk);
>  	}
>  
> +	reset = devm_reset_control_get_optional_exclusive(dev, NULL);
> +	if (IS_ERR(reset)) {
> +		ret = PTR_ERR(reset);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(dev,
> +				"failed to get reset controller: %d\n", ret);
> +		return ret;
> +	}

When the controller is optional, you don't need to do that manual error
checking, as it does that for you already. You can only do:

if (IS_ERR(reset))
	return PTR_ERR(reset);

and that's it. With that fixed in v4, you can add:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

[PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Álvaro Fernández Rojas]

bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
BCM6368 and BCM63268).

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
 v3: no changes
 v2: no changes

 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 8f1f8fca79e3..a9896e388355 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -149,7 +149,7 @@ config SPI_BCM2835AUX
 
 config SPI_BCM63XX
 	tristate "Broadcom BCM63xx SPI controller"
-	depends on BCM63XX || COMPILE_TEST
+	depends on BCM63XX || BMIPS_GENERIC || COMPILE_TEST
 	help
 	  Enable support for the SPI controller on the Broadcom BCM63xx SoCs.
 
-- 
2.27.0

Re: [PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Tue, Jun 16, 2020 at 09:02:21AM +0200, Álvaro Fernández Rojas wrote:
> bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
> BCM6368 and BCM63268).

Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code.  Modifying existing
commits creates problems for other users building on top of those
commits so it's best practice to only change pubished git commits if
absolutely essential.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Florian Fainelli]

On 6/16/2020 10:07 AM, Mark Brown wrote:
> On Tue, Jun 16, 2020 at 09:02:21AM +0200, Álvaro Fernández Rojas wrote:
>> bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
>> BCM6368 and BCM63268).
> 
> Please do not submit new versions of already applied patches, please
> submit incremental updates to the existing code.  Modifying existing
> commits creates problems for other users building on top of those
> commits so it's best practice to only change pubished git commits if
> absolutely essential.
> 

In Alvaro's defense, you applied the patches despite me requesting that
specific changes be made (use the optional reset control API variant).

Having a FAQ entry about what your expectations as a subsystem
maintainer are (ala netdev-FAQ.rst) could save you time along the way.
-- 
Florian

Re: [PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Tue, Jun 16, 2020 at 10:15:15AM -0700, Florian Fainelli wrote:
> On 6/16/2020 10:07 AM, Mark Brown wrote:

> > Please do not submit new versions of already applied patches, please
> > submit incremental updates to the existing code.  Modifying existing
> > commits creates problems for other users building on top of those
> > commits so it's best practice to only change pubished git commits if
> > absolutely essential.

> In Alvaro's defense, you applied the patches despite me requesting that
> specific changes be made (use the optional reset control API variant).

I applied only the two patches that you'd acked, not the reset patches
which had problems.

> Having a FAQ entry about what your expectations as a subsystem
> maintainer are (ala netdev-FAQ.rst) could save you time along the way.

Incremental updates are the default AFAICT?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Florian Fainelli]

On 6/16/2020 10:25 AM, Mark Brown wrote:
> On Tue, Jun 16, 2020 at 10:15:15AM -0700, Florian Fainelli wrote:
>> On 6/16/2020 10:07 AM, Mark Brown wrote:
> 
>>> Please do not submit new versions of already applied patches, please
>>> submit incremental updates to the existing code.  Modifying existing
>>> commits creates problems for other users building on top of those
>>> commits so it's best practice to only change pubished git commits if
>>> absolutely essential.
> 
>> In Alvaro's defense, you applied the patches despite me requesting that
>> specific changes be made (use the optional reset control API variant).
> 
> I applied only the two patches that you'd acked, not the reset patches
> which had problems.

Indeed, sorry for not reading your commit message properly, I believe I
request that before, cannot the "applied" response just reply with the
patches *applied* and not *all* part of the series?

> 
>> Having a FAQ entry about what your expectations as a subsystem
>> maintainer are (ala netdev-FAQ.rst) could save you time along the way.
> 
> Incremental updates are the default AFAICT?
> 

It really depends if the maintainer is willing to rewrite his tree
history, some people do, some people do not, especially if nothing has
been submitted to Linus yet.
-- 
Florian

Re: [PATCH v3 2/4] spi: bcm63xx-spi: allow building for BMIPS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Tue, Jun 16, 2020 at 10:31:16AM -0700, Florian Fainelli wrote:
> On 6/16/2020 10:25 AM, Mark Brown wrote:

> >> In Alvaro's defense, you applied the patches despite me requesting that
> >> specific changes be made (use the optional reset control API variant).

> > I applied only the two patches that you'd acked, not the reset patches
> > which had problems.

> Indeed, sorry for not reading your commit message properly, I believe I
> request that before, cannot the "applied" response just reply with the
> patches *applied* and not *all* part of the series?

You might've mentioned it to someone else using b4 but not me - AFAICT
it's not configurable.  I can see arguments either way TBH, but I do
agree that the current output could be confusing and if nothing else the
wording could be better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v3 3/4] spi: bcm63xx-hsspi: add reset support

[Álvaro Fernández Rojas]

bcm63xx arch resets the HSSPI controller at early boot. However, bmips arch
needs to perform a reset when probing the driver.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 v3: use devm_reset_control_get_optional_exclusive
 v2: use devm_reset_control_get_exclusive

 drivers/spi/spi-bcm63xx-hsspi.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/spi/spi-bcm63xx-hsspi.c b/drivers/spi/spi-bcm63xx-hsspi.c
index 6c235306c0e4..45e2b0942e64 100644
--- a/drivers/spi/spi-bcm63xx-hsspi.c
+++ b/drivers/spi/spi-bcm63xx-hsspi.c
@@ -20,6 +20,7 @@
 #include <linux/spi/spi.h>
 #include <linux/mutex.h>
 #include <linux/of.h>
+#include <linux/reset.h>
 
 #define HSSPI_GLOBAL_CTRL_REG			0x0
 #define GLOBAL_CTRL_CS_POLARITY_SHIFT		0
@@ -334,6 +335,7 @@ static int bcm63xx_hsspi_probe(struct platform_device *pdev)
 	struct clk *clk, *pll_clk = NULL;
 	int irq, ret;
 	u32 reg, rate, num_cs = HSSPI_SPI_MAX_CS;
+	struct reset_control *reset;
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0)
@@ -348,10 +350,25 @@ static int bcm63xx_hsspi_probe(struct platform_device *pdev)
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
+	reset = devm_reset_control_get_optional_exclusive(dev, NULL);
+	if (IS_ERR(reset)) {
+		ret = PTR_ERR(reset);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev,
+				"failed to get reset controller: %d\n", ret);
+		return ret;
+	}
+
 	ret = clk_prepare_enable(clk);
 	if (ret)
 		return ret;
 
+	ret = reset_control_reset(reset);
+	if (ret) {
+		dev_err(dev, "unable to reset device: %d\n", ret);
+		goto out_disable_clk;
+	}
+
 	rate = clk_get_rate(clk);
 	if (!rate) {
 		pll_clk = devm_clk_get(dev, "pll");
-- 
2.27.0

Re: [PATCH v3 3/4] spi: bcm63xx-hsspi: add reset support

[Florian Fainelli]

On 6/16/2020 12:02 AM, Álvaro Fernández Rojas wrote:
> bcm63xx arch resets the HSSPI controller at early boot. However, bmips arch
> needs to perform a reset when probing the driver.
> 
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---

Same comment as patch #1.
-- 
Florian

[PATCH v3 4/4] spi: bcm63xx-hsspi: allow building for BMIPS

[Álvaro Fernández Rojas]

bcm63xx-hsspi controller is present on several BMIPS SoCs (BCM6318, BCM6328,
BCM6362 and BCM63268).

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
 v3: no changes
 v2: no changes

 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a9896e388355..500774fe1351 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,7 +155,7 @@ config SPI_BCM63XX
 
 config SPI_BCM63XX_HSSPI
 	tristate "Broadcom BCM63XX HS SPI controller driver"
-	depends on BCM63XX || ARCH_BCM_63XX || COMPILE_TEST
+	depends on BCM63XX || BMIPS_GENERIC || ARCH_BCM_63XX || COMPILE_TEST
 	help
 	  This enables support for the High Speed SPI controller present on
 	  newer Broadcom BCM63XX SoCs.
-- 
2.27.0