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
bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
BCM6368 and BCM63268).
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
---
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
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 <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
---
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
bcm63xx-hsspi controller is present on several BMIPS SoCs (BCM6318, BCM6328,
BCM6362 and BCM63268).
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
---
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
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 <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
---
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
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 <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
> ---
Same comment as patch #1.
--
Florian
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 <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
> ---
> 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 <[email protected]>
--
Florian
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.
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
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?
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
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.