* [PATCH v1 2/2] ARM: dts: aspeed: mihawk: Add 8 tmp401 thermal sensor
From: Ben Pai @ 2020-06-05 10:06 UTC (permalink / raw)
To: joel, devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Ben Pai, claire_ku
Signed-off-by: Ben Pai <Ben_Pai@wistron.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 40 +++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
index 25ffe65fbdc0..5bf1f13dda3b 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
@@ -834,6 +834,11 @@
line-name = "smbus0";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus9_mux232: i2c@1 {
@@ -854,6 +859,11 @@
line-name = "smbus1";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus9_mux233: i2c@2 {
@@ -897,6 +907,11 @@
line-name = "smbus2";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus9_mux236: i2c@1 {
@@ -917,6 +932,11 @@
line-name = "smbus3";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus9_mux237: i2c@2 {
@@ -979,6 +999,11 @@
line-name = "smbus4";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus10_mux240: i2c@1 {
@@ -999,6 +1024,11 @@
line-name = "smbus5";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus10_mux241: i2c@2 {
@@ -1042,6 +1072,11 @@
line-name = "smbus6";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus10_mux244: i2c@1 {
@@ -1062,6 +1097,11 @@
line-name = "smbus7";
};
};
+
+ tmp431@4c {
+ compatible = "ti,tmp401";
+ reg = <0x4c>;
+ };
};
bus10_mux245: i2c@2 {
--
2.17.1
---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient.
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Michael Walle @ 2020-06-05 10:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <CAHp75Vd-R3yqhq88-whY6vdDhESpzvFCsbi-ygSTjfXfUzOrtg@mail.gmail.com>
Hi Andy,
Am 2020-06-05 10:01, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 12:16 AM Michael Walle <michael@walle.cc> wrote:
>>
>> Add the core support for the board management controller found on the
>> SMARC-sAL28 board. It consists of the following functions:
>> - watchdog
>> - GPIO controller
>> - PWM controller
>> - fan sensor
>> - interrupt controller
>>
>> At the moment, this controller is used on the Kontron SMARC-sAL28
>> board.
>>
>> Please note that the MFD driver is defined as bool in the Kconfig
>> because the next patch will add interrupt support.
>
> ...
>
>> +config MFD_SL28CPLD
>> + bool "Kontron sl28 core driver"
>> + depends on I2C=y
>
> Why not module?
There are users of the interupt lines provided by the interrupt
controller.
For example, the gpio-button driver. If this is compiled into the kernel
(which it is by default in the arm64 defconfig), probing will fail
because
the interrupt is not found. Is there a better way for that? I guess the
same
is true for the GPIO driver.
>
>> + depends on OF
>
> I didn't find an evidence this is needed.
see below.
>
> No Compile Test?
ok
>> + select REGMAP_I2C
>> + select MFD_CORE
>
> ...
>
>> +#include <linux/of_platform.h>
>
> No evidence of user of this.
> I think you meant mod_devicetable.h.
devm_of_platform_populate(), so I need CONFIG_OF, too right?
>> +static struct i2c_driver sl28cpld_driver = {
>> + .probe_new = sl28cpld_probe,
>> + .driver = {
>> + .name = "sl28cpld",
>> + .of_match_table = of_match_ptr(sl28cpld_of_match),
>
> Drop of_match_ptr(). It has a little sense in this context (depends
> OF).
> It will have a little sense even if you drop depends OF b/c you will
> introduce a compiler warning.
ok
>
>> + },
>> +};
--
-michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Michael Walle @ 2020-06-05 9:51 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree, Linus Walleij, Thierry Reding, Jason Cooper,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, linux-gpio, Rob Herring, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon,
Greg Kroah-Hartman, linux-kernel, Li Yang, broonie, Shawn Guo
In-Reply-To: <20200605065709.GD3714@dell>
Hi Lee,
thanks for the review.
Am 2020-06-05 08:57, schrieb Lee Jones:
> Mark, what do you think?
>
> On Thu, 04 Jun 2020, Michael Walle wrote:
>
>> Add the core support for the board management controller found on the
>> SMARC-sAL28 board. It consists of the following functions:
>> - watchdog
>> - GPIO controller
>> - PWM controller
>> - fan sensor
>> - interrupt controller
>>
>> At the moment, this controller is used on the Kontron SMARC-sAL28
>> board.
>>
>> Please note that the MFD driver is defined as bool in the Kconfig
>> because the next patch will add interrupt support.
>>
>> Signed-off-by: Michael Walle <michael@walle.cc>
>> ---
>> drivers/mfd/Kconfig | 19 ++++++++++
>> drivers/mfd/Makefile | 2 ++
>> drivers/mfd/sl28cpld.c | 79
>> ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 100 insertions(+)
>> create mode 100644 drivers/mfd/sl28cpld.c
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 4f8b73d92df3..5c0cd514d197 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
>> If you have an SGI Origin, Octane, or a PCI IOC3 card,
>> then say Y. Otherwise say N.
>>
>> +config MFD_SL28CPLD
>> + bool "Kontron sl28 core driver"
>
> "Kontron SL28 Core Driver"
ok
>
>> + depends on I2C=y
>> + depends on OF
>> + select REGMAP_I2C
>> + select MFD_CORE
>> + help
>> + This option enables support for the board management controller
>> + found on the Kontron sl28 CPLD. You have to select individual
>
> I can't find any reference to the "Kontron sl28 CPLD" online.
>
> Is there a datasheet?
Unfortunately not.
>> + functions, such as watchdog, GPIO, etc, under the corresponding
>> menus
>> + in order to enable them.
>> +
>> + Currently supported boards are:
>> +
>> + Kontron SMARC-sAL28
>> +
>> + To compile this driver as a module, choose M here: the module will
>> be
>> + called sl28cpld.
>> +
>> endmenu
>> endif
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 9367a92f795a..be59fb40aa28 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
>> obj-$(CONFIG_MFD_STMFX) += stmfx.o
>>
>> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
>> +
>> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o
>> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
>> new file mode 100644
>> index 000000000000..a23194bb6efa
>> --- /dev/null
>> +++ b/drivers/mfd/sl28cpld.c
>> @@ -0,0 +1,79 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * MFD core for the sl28cpld.
>
> Ideally this would match the Kconfig subject line.
ok
>
>> + * Copyright 2019 Kontron Europe GmbH
>
> This is out of date.
ok
>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/module.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/regmap.h>
>> +
>> +#define SL28CPLD_VERSION 0x03
>> +#define SL28CPLD_MIN_REQ_VERSION 14
>> +
>> +struct sl28cpld {
>> + struct device *dev;
>> + struct regmap *regmap;
>> +};
>
> Why do you need this structure?
see below
>> +static const struct regmap_config sl28cpld_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .reg_stride = 1,
>> +};
>> +
>> +static int sl28cpld_probe(struct i2c_client *i2c)
>> +{
>> + struct sl28cpld *sl28cpld;
>> + struct device *dev = &i2c->dev;
>> + unsigned int cpld_version;
>> + int ret;
>> +
>> + sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
>> + if (!sl28cpld)
>> + return -ENOMEM;
>> +
>> + sl28cpld->regmap = devm_regmap_init_i2c(i2c,
>> &sl28cpld_regmap_config);
>> + if (IS_ERR(sl28cpld->regmap))
>> + return PTR_ERR(sl28cpld->regmap);
>
> This is now a shared memory allocator and not an MFD at all.
>
> I'm clamping down on these type of drivers!
>
> Please find a better way to accomplish this.
>
> Potentially using "simple-mfd" and "simple-regmap".
>
> The former already exists and does what you want. The latter doesn't
> yet exist, but could solve your and lots of other contributor's
> issues.
Mh, the former doesn't provide a regmap, correct? Most MMIO drivers
won't
need it, but this is an I2C device. So yes, I could come up with a
"simple-regmap" proposal. I guess that should go into drivers/mfd/
because
it is more than just adding one line, i.e. you would have to configure
the
regmap and its different interfaces.
But how would you model that version check below for example? (Not that
I'm
very keen of it.)
>
> Heck maybe I'll implement it myself if this keeps happening.
>
>> + ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION,
>> &cpld_version);
>> + if (ret)
>> + return ret;
>> +
>> + if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
>> + dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
>> + return -ENODEV;
>> + }
>> +
>> + sl28cpld->dev = dev;
>> + i2c_set_clientdata(i2c, sl28cpld);
>
> If the struct definition is in here, how do you use it elsewhere?
I wanted to store the regmap somewhere, but because there are no users,
I'll
drop that.
>> + dev_info(dev, "successfully probed. CPLD version %d\n",
>> cpld_version);
>> +
>> + return devm_of_platform_populate(&i2c->dev);
>> +}
>> +
>> +static const struct of_device_id sl28cpld_of_match[] = {
>> + { .compatible = "kontron,sl28cpld-r1", },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
>> +
>> +static struct i2c_driver sl28cpld_driver = {
>> + .probe_new = sl28cpld_probe,
>> + .driver = {
>> + .name = "sl28cpld",
>> + .of_match_table = of_match_ptr(sl28cpld_of_match),
>> + },
>> +};
>> +module_i2c_driver(sl28cpld_driver);
>> +
>> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
>> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
>> +MODULE_LICENSE("GPL");
--
-michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drivers/perf: hisi: Fix wrong value for all counters enable
From: Shaokun Zhang @ 2020-06-05 9:43 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Shaokun Zhang, Mark Rutland, Will Deacon
In L3C uncore PMU drivers, bit16 is used to control all counters enable &
disable. Wrong value is given in the driver and its default value is 1'b1,
it can work because each PMU counter has its own control bits too.
Let's fix the wrong value.
Fixes: 2940bc433370 ("perf: hisi: Add support for HiSilicon SoC L3C PMU driver")
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
---
drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
index 8dd1278bec04..7719ae4e2c56 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
@@ -35,7 +35,7 @@
/* L3C has 8-counters */
#define L3C_NR_COUNTERS 0x8
-#define L3C_PERF_CTRL_EN 0x20000
+#define L3C_PERF_CTRL_EN 0x10000
#define L3C_EVTYPE_NONE 0xff
/*
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 6/6] PCI: uniphier: Use devm_platform_ioremap_resource_byname()
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
Use devm_platform_ioremap_resource_byname() to simplify the code a bit.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 8356dd3..233d624 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -456,8 +456,7 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.atu_base))
priv->pci.atu_base = NULL;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
- priv->base = devm_ioremap_resource(dev, res);
+ priv->base = devm_platform_ioremap_resource_byname(pdev, "link");
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 5/6] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
Even if phy driver doesn't probe, the error message can't be distinguished
from other errors. This displays error message caused by the phy driver
explicitly.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index c37a968..8356dd3 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -470,8 +470,12 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
return PTR_ERR(priv->rst);
priv->phy = devm_phy_optional_get(dev, "pcie-phy");
- if (IS_ERR(priv->phy))
- return PTR_ERR(priv->phy);
+ if (IS_ERR(priv->phy)) {
+ ret = PTR_ERR(priv->phy);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get phy (%d)\n", ret);
+ return ret;
+ }
platform_set_drvdata(pdev, priv);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 4/6] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
This gets iATU register area from reg property. In Synopsys DWC version
4.80 or later, since iATU register area is separated from core register
area, this area is necessary to get from DT independently.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 5ce2479..c37a968 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -451,6 +451,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.dbi_base))
return PTR_ERR(priv->pci.dbi_base);
+ priv->pci.atu_base =
+ devm_platform_ioremap_resource_byname(pdev, "atu");
+ if (IS_ERR(priv->pci.atu_base))
+ priv->pci.atu_base = NULL;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/6] dt-bindings: PCI: uniphier: Add iATU register description
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsys DWC version 4.80 or later.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
"dbi" - controller configuration registers
"link" - SoC-specific glue layer registers
"config" - PCIe configuration space
+ "atu" - iATU registers for DWC version 4.80 or later
- clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
- resets: A phandle to the reset line for PCIe glue layer including
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
The misc interrupts consisting of PME, AER, and Link event, is handled
by INTx handler, however, these interrupts should be also handled by
MSI handler.
This adds the function uniphier_pcie_misc_isr() that handles misc
interrupts, which is called from both INTx and MSI handlers.
This function detects PME and AER interrupts with the status register,
and invoke PME and AER drivers related to MSI.
And this sets the mask for misc interrupts from INTx if MSI is enabled
and sets the mask for misc interrupts from MSI if MSI is disabled.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 57 ++++++++++++++++++++++++------
1 file changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a5401a0..5ce2479 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -44,7 +44,9 @@
#define PCL_SYS_AUX_PWR_DET BIT(8)
#define PCL_RCV_INT 0x8108
+#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
#define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
#define PCL_CFG_BW_MGT_STATUS BIT(4)
#define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
#define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
@@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
{
- writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+ u32 val;
+
+ val = PCL_RCV_INT_ALL_ENABLE;
+ if (pci_msi_enabled())
+ val |= PCL_RCV_INT_ALL_INT_MASK;
+ else
+ val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+ writel(val, priv->base + PCL_RCV_INT);
writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
}
@@ -231,32 +241,56 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
.map = uniphier_pcie_intx_map,
};
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp, bool is_msi)
{
- struct pcie_port *pp = irq_desc_get_handler_data(desc);
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
- struct irq_chip *chip = irq_desc_get_chip(desc);
- unsigned long reg;
- u32 val, bit, virq;
+ u32 val, virq;
- /* INT for debug */
val = readl(priv->base + PCL_RCV_INT);
if (val & PCL_CFG_BW_MGT_STATUS)
dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
+
if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
- if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
- dev_dbg(pci->dev, "Root Error\n");
- if (val & PCL_CFG_PME_MSI_STATUS)
- dev_dbg(pci->dev, "PME Interrupt\n");
+
+ if (is_msi) {
+ if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
+ dev_dbg(pci->dev, "Root Error Status\n");
+
+ if (val & PCL_CFG_PME_MSI_STATUS)
+ dev_dbg(pci->dev, "PME Interrupt\n");
+
+ if (val & (PCL_CFG_AER_RC_ERR_MSI_STATUS |
+ PCL_CFG_PME_MSI_STATUS)) {
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+ }
writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_msi_host_isr(struct pcie_port *pp)
+{
+ uniphier_pcie_misc_isr(pp, true);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long reg;
+ u32 val, bit, virq;
/* INTx */
chained_irq_enter(chip, desc);
+ uniphier_pcie_misc_isr(pp, false);
+
val = readl(priv->base + PCL_RCV_INTX);
reg = FIELD_GET(PCL_RCV_INTX_ALL_STATUS, val);
@@ -330,6 +364,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
.host_init = uniphier_pcie_host_init,
+ .msi_host_isr = uniphier_pcie_msi_host_isr,
};
static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/6] PCI: uniphier: Add features for UniPhier PCIe host controller
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
This series adds some features for UniPhier PCIe host controller.
- Add support for PME and AER invoked by MSI interrupt
- Add iATU register view support for PCIe version >= 4.80
- Add an error message when failing to get phy driver
This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.
Changes since v3:
- Move msi_host_isr() call into dw_handle_msi_irq()
- Move uniphier_pcie_misc_isr() call into the guard of chained_irq
- Use a bool argument is_msi instead of pci_msi_enabled()
- Consolidate handler calls for the same interrupt
- Fix typos in commit messages
Changes since v2:
- Avoid printing phy error message in case of EPROBE_DEFER
- Fix iATU register mapping method
- dt-bindings: Add Acked-by: line
- Fix typos in commit messages
- Use devm_platform_ioremap_resource_byname()
Changes since v1:
- Add check if struct resource is NULL
- Fix warning in the type of dev_err() argument
Kunihiko Hayashi (6):
PCI: dwc: Add msi_host_isr() callback
PCI: uniphier: Add misc interrupt handler to invoke PME and AER
dt-bindings: PCI: uniphier: Add iATU register description
PCI: uniphier: Add iATU register support
PCI: uniphier: Add error message when failed to get phy
PCI: uniphier: Use devm_platform_ioremap_resource_byname()
.../devicetree/bindings/pci/uniphier-pcie.txt | 1 +
drivers/pci/controller/dwc/pcie-designware-host.c | 3 +
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-uniphier.c | 73 +++++++++++++++++-----
4 files changed, 63 insertions(+), 15 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/6] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-06-05 9:44 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591350276-15816-1-git-send-email-hayashi.kunihiko@socionext.com>
This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.
For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 3 +++
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 0a4a5aa..026edb1 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -83,6 +83,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
u32 status, num_ctrls;
irqreturn_t ret = IRQ_NONE;
+ if (pp->ops->msi_host_isr)
+ pp->ops->msi_host_isr(pp);
+
num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
for (i = 0; i < num_ctrls; i++) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 656e00f..e741967 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
void (*scan_bus)(struct pcie_port *pp);
void (*set_num_vectors)(struct pcie_port *pp);
int (*msi_host_init)(struct pcie_port *pp);
+ void (*msi_host_isr)(struct pcie_port *pp);
};
struct pcie_port {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 12/25] clk: bcm: rpi: Use CCF boundaries instead of rolling our own
From: Nicolas Saenz Julienne @ 2020-06-05 9:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel
In-Reply-To: <20200605092802.xkoazjnin7xyqkoy@gilmour.lan>
[-- Attachment #1.1: Type: text/plain, Size: 3014 bytes --]
On Fri, 2020-06-05 at 11:28 +0200, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Thu, Jun 04, 2020 at 08:02:22PM +0200, Nicolas Saenz Julienne wrote:
> > On Wed, 2020-05-27 at 17:45 +0200, Maxime Ripard wrote:
> > > The raspberrypi firmware clock driver has a min_rate / max_rate clamping
> > > by
> > > storing the info it needs in a private structure.
> > >
> > > However, the CCF already provides such a facility, so we can switch to it
> > > to remove the boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > ---
> > > drivers/clk/bcm/clk-raspberrypi.c | 18 ++++++++----------
> > > 1 file changed, 8 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> > > raspberrypi.c
> > > index a20492fade6a..e135ad28d38d 100644
> > > --- a/drivers/clk/bcm/clk-raspberrypi.c
> > > +++ b/drivers/clk/bcm/clk-raspberrypi.c
> > > @@ -36,9 +36,6 @@ struct raspberrypi_clk {
> > > struct rpi_firmware *firmware;
> > > struct platform_device *cpufreq;
> > >
> > > - unsigned long min_rate;
> > > - unsigned long max_rate;
> > > -
> > > struct clk_hw pllb;
> > > };
> > >
> > > @@ -142,13 +139,11 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw
> > > *hw, unsigned long rate,
> > > static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
> > > struct clk_rate_request *req)
> > > {
> > > - struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
> > > - pllb);
> > > u64 div, final_rate;
> > > u32 ndiv, fdiv;
> > >
> > > /* We can't use req->rate directly as it would overflow */
> > > - final_rate = clamp(req->rate, rpi->min_rate, rpi->max_rate);
> > > + final_rate = clamp(req->rate, req->min_rate, req->max_rate);
> > >
> > > div = (u64)final_rate << A2W_PLL_FRAC_BITS;
> > > do_div(div, req->best_parent_rate);
> > > @@ -215,12 +210,15 @@ static int raspberrypi_register_pllb(struct
> > > raspberrypi_clk *rpi)
> > > dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
> > > min_rate, max_rate);
> > >
> > > - rpi->min_rate = min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
> > > - rpi->max_rate = max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
> > > -
> > > rpi->pllb.init = &init;
> > >
> > > - return devm_clk_hw_register(rpi->dev, &rpi->pllb);
> > > + ret = devm_clk_hw_register(rpi->dev, &rpi->pllb);
> > > + if (!ret)
> > > + clk_hw_set_rate_range(&rpi->pllb,
> > > + min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
> > > + max_rate *
> > > RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
> >
> > Isn't there a potential race here? Albeit unlikely, cpufreq could show
> > up and call clk_round_rate() in between the registration and you
> > setting the ranges.
>
> IIRC, driver's probe are not called in parallel but in sequence, so we
> should be covered here.
Right, of course.
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
From: Andy Shevchenko @ 2020-06-05 9:33 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree, Linus Walleij, Thierry Reding, Jason Cooper,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Michael Walle, Rob Herring, Shawn Guo
In-Reply-To: <20200605084915.GE3714@dell>
On Fri, Jun 5, 2020 at 11:51 AM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 04 Jun 2020, Michael Walle wrote:
...
> > + cycle = state->duty_cycle * config->max_duty_cycle;
> > + do_div(cycle, state->period);
>
> Forgive my ignorance (I'm new here!), but what are these 2 lines
> doing? Here we are multiplying the current duty_cycle with the
> maximum value, then dividing by the period.
>
> So in the case of PWM_MODE_1KHZ with a 50% duty cycle, you'd have:
>
> (500000 * 0x20[16]) / 1000000 = [0x10]16
>
> Thus, the above gives as a proportional representation of the maximum
> valid value for placement into the cycle control register(s), right?
>
> Either way (whether I'm correct or not), I think it would be nice to
> mention this in a comment. Maybe even clarify with a simple example.
IIRC PWM has a helper for that (to calc period based on PWM state and
new duty cycle %).
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* How to use FIQ on rpi zero? (second try)
From: Sietse Achterop @ 2020-06-05 9:32 UTC (permalink / raw)
To: linux-arm-kernel
Hello List,
I'm having trouble with using FIQ interrupts with the ARM timer on raspberypi zero, (BCM2835 chip).
I created a kernel module, and the test version of this driver can be found in
https://github.com/SietseAchterop/Batradio/blob/master/batradio_module/fiqtest_4.c
I made sure that FIQ is not used by USB by adding
dwc_otg.fiq_fsm_enable=0 dwc_otg.fiq_enable=0 dwc_otg.nak_holdoff=0
to cmdline.txt in /boot
I first tried to use the regular sequence of functions to use.
In the init function:
claim_fiq, set_fiq_regs, enable_fiq
In the exit function
disable_fiq, release_fiq.
But I cannot find which iqr number to use, e.g. using irq_of_parse_and_map
I tried several values. 0, 64, but nothing works.
So instead of enable/disable I directly set the timer interrupt via the IRQFIQ register.
This works, a bit.
The fiq_handler only resets the ARM timer, increments a timer and toggles a LED.
I see the timer counting, the fiq being called.
But the rpi fairly quickly crashes.
In the, sometimes, 10 seconds that it runs I see the led flashing very irregular.
What is wrong here?
Has the irregularity something to do with suspend/resume?
Please find below the relevant snippets from the init and exit function of the driver.
And also the fiq_handler.
Thanks in advance,
Sietse
====== init_bat
.....
// directly set ARM timer registers
TIMCNTR = 0x0000000; // stop timer
TIMLOAD = 100000-1; // load value
TIMCINT = 0; // clear interrupt
ret = claim_fiq(&bat_fh);
if (ret) {
printk("batradio: claim_fiq failed.\n");
return ret;
}
set_fiq_handler(&batradio_handler, &batradio_handler_end - &batradio_handler);
regs.ARM_r8 = (long)gpiospi;
regs.ARM_r9 = (long)irqtimer;
regs.ARM_r10 = (long)0;
set_fiq_regs(®s);
TIMCNTR = 0x000000A2; // start timer with interrupt, 23 bit counter
IRQFIQ = 0xC0; // timer interrupt to fiq directly via register
//enable_fiq(64);
....
====== exit_bat
....
IRQFIQ = 0x00;
TIMCNTR = 0x003E0000;
//disable_fiq(64);
....
====== batradio fiq handler
.text
.global batradio_handler
.global batradio_handler_end
batradio_handler:
stmdb sp!, {r6-r7}
mov r6, #0
str r6, [r9, #0x40C] // TIMCINT = 0 // clear interrupt
mov r7, #0x2000 // 1 << CNVST
add r10, r10, #1
ands r6, r10, #0x0001 // set toggle speed
bne off
str r7, [r8, #40] // led on
ldmia sp!, {r6-r7}
subs pc, lr, #4
off: str r7, [r8, #28] // led off
ldmia sp!, {r6-r7}
subs pc, lr, #4
batradio_handler_end:
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 12/25] clk: bcm: rpi: Use CCF boundaries instead of rolling our own
From: Maxime Ripard @ 2020-06-05 9:28 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Tim Gover, Dave Stevenson, linux-kernel, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel
In-Reply-To: <e096d89ab881d69b2477b209838a308f9de114b1.camel@suse.de>
Hi Nicolas,
On Thu, Jun 04, 2020 at 08:02:22PM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-05-27 at 17:45 +0200, Maxime Ripard wrote:
> > The raspberrypi firmware clock driver has a min_rate / max_rate clamping by
> > storing the info it needs in a private structure.
> >
> > However, the CCF already provides such a facility, so we can switch to it
> > to remove the boilerplate.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > drivers/clk/bcm/clk-raspberrypi.c | 18 ++++++++----------
> > 1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> > raspberrypi.c
> > index a20492fade6a..e135ad28d38d 100644
> > --- a/drivers/clk/bcm/clk-raspberrypi.c
> > +++ b/drivers/clk/bcm/clk-raspberrypi.c
> > @@ -36,9 +36,6 @@ struct raspberrypi_clk {
> > struct rpi_firmware *firmware;
> > struct platform_device *cpufreq;
> >
> > - unsigned long min_rate;
> > - unsigned long max_rate;
> > -
> > struct clk_hw pllb;
> > };
> >
> > @@ -142,13 +139,11 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw
> > *hw, unsigned long rate,
> > static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
> > struct clk_rate_request *req)
> > {
> > - struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
> > - pllb);
> > u64 div, final_rate;
> > u32 ndiv, fdiv;
> >
> > /* We can't use req->rate directly as it would overflow */
> > - final_rate = clamp(req->rate, rpi->min_rate, rpi->max_rate);
> > + final_rate = clamp(req->rate, req->min_rate, req->max_rate);
> >
> > div = (u64)final_rate << A2W_PLL_FRAC_BITS;
> > do_div(div, req->best_parent_rate);
> > @@ -215,12 +210,15 @@ static int raspberrypi_register_pllb(struct
> > raspberrypi_clk *rpi)
> > dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
> > min_rate, max_rate);
> >
> > - rpi->min_rate = min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
> > - rpi->max_rate = max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
> > -
> > rpi->pllb.init = &init;
> >
> > - return devm_clk_hw_register(rpi->dev, &rpi->pllb);
> > + ret = devm_clk_hw_register(rpi->dev, &rpi->pllb);
> > + if (!ret)
> > + clk_hw_set_rate_range(&rpi->pllb,
> > + min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE,
> > + max_rate *
> > RPI_FIRMWARE_PLLB_ARM_DIV_RATE);
>
> Isn't there a potential race here? Albeit unlikely, cpufreq could show
> up and call clk_round_rate() in between the registration and you
> setting the ranges.
IIRC, driver's probe are not called in parallel but in sequence, so we
should be covered here.
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Russell King - ARM Linux admin @ 2020-06-05 9:27 UTC (permalink / raw)
To: Neal Liu
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Marc Zyngier,
Matt Mackall, Sean Wang, lkml, wsd_upstream, Rob Herring,
linux-mediatek@lists.infradead.org, Linux Crypto Mailing List,
Greg Kroah-Hartman, Matthias Brugger,
Crystal Guo (郭晶), Ard Biesheuvel, Linux ARM
In-Reply-To: <1591347582.21704.9.camel@mtkswgap22>
On Fri, Jun 05, 2020 at 04:59:42PM +0800, Neal Liu wrote:
> On Fri, 2020-06-05 at 09:09 +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> > > On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > > > This kind of thing is something that ARM have seems to shy away from
> > > > doing - it's a point I brought up many years ago when the whole
> > > > trustzone thing first appeared with its SMC call. Those around the
> > > > conference table were not interested - ARM seemed to prefer every
> > > > vendor to do off and do their own thing with the SMC interface.
> > >
> > > Does that mean it make sense to model a sec-rng driver, and get each
> > > vendor's SMC function id by DT node?
> >
> > _If_ vendors have already gone off and decided to use different SMC
> > function IDs for this, while keeping the rest of the SMC interface
> > the same, then the choice has already been made.
> >
> > I know on 32-bit that some of the secure world implementations can't
> > be changed; they're burnt into the ROM. I believe on 64-bit that isn't
> > the case, which makes it easier to standardise.
> >
> > Do you have visibility of how this SMC is implemented in the secure
> > side? Is it in ATF, and is it done as a vendor hack or is there an
> > element of generic implementation to it? Has it been submitted
> > upstream to the main ATF repository?
> >
>
> Take MediaTek as an example, some SoCs are implemented in ATF, some of
> them are implemented in TEE. We have no plan to make generic
> implementation in "secure world".
I think you have your answer right there - by _not_ making the API
generic and giving no motivation to use it, different vendors are
going to do different things (maybe even with a different API as well)
so there's no point the kernel driver pretending to be a generic
driver. If the driver isn't going to be generic, I see little point in
the SMC function number being in DT.
I think that as a _whole_ is a big mistake - there should be a generic
kernel driver for this, and there should be a standardised interface to
it through firmware. So, I would encourage you to try to get it
accepted one way or another amongst vendors as a standardised
interface.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Neal Liu @ 2020-06-05 8:59 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Marc Zyngier,
Matt Mackall, Sean Wang, lkml, wsd_upstream, Rob Herring,
linux-mediatek@lists.infradead.org, Linux Crypto Mailing List,
Greg Kroah-Hartman, Matthias Brugger,
Crystal Guo (郭晶), Ard Biesheuvel, Linux ARM
In-Reply-To: <20200605080905.GF1551@shell.armlinux.org.uk>
On Fri, 2020-06-05 at 09:09 +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> > On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > > This kind of thing is something that ARM have seems to shy away from
> > > doing - it's a point I brought up many years ago when the whole
> > > trustzone thing first appeared with its SMC call. Those around the
> > > conference table were not interested - ARM seemed to prefer every
> > > vendor to do off and do their own thing with the SMC interface.
> >
> > Does that mean it make sense to model a sec-rng driver, and get each
> > vendor's SMC function id by DT node?
>
> _If_ vendors have already gone off and decided to use different SMC
> function IDs for this, while keeping the rest of the SMC interface
> the same, then the choice has already been made.
>
> I know on 32-bit that some of the secure world implementations can't
> be changed; they're burnt into the ROM. I believe on 64-bit that isn't
> the case, which makes it easier to standardise.
>
> Do you have visibility of how this SMC is implemented in the secure
> side? Is it in ATF, and is it done as a vendor hack or is there an
> element of generic implementation to it? Has it been submitted
> upstream to the main ATF repository?
>
Take MediaTek as an example, some SoCs are implemented in ATF, some of
them are implemented in TEE. We have no plan to make generic
implementation in "secure world".
Due to there must have different implementation in secure world for
vendors, we plan to provide a generic SMC interface in secure rng kernel
driver for more flexibility.
Vendors can decide which "secure world" they want (HYP/ATF/TEE) by
different smc/hvc and different SMC function IDs in DT node.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: imx6: add missing put_device() call in imx6q_suspend_init()
From: yukuai (C) @ 2020-06-05 9:08 UTC (permalink / raw)
To: Markus Elfring, kernel, linux-arm-kernel, linux-imx
Cc: Anson Huang, Yi Zhang, Fabio Estevam, Sascha Hauer,
kernel-janitors, Russell King, LKML, Shawn Guo
In-Reply-To: <cf810c93-297c-c02c-9bba-8c3d097b8e31@web.de>
On 2020/6/5 3:07, Markus Elfring wrote:
>> if of_find_device_by_node() succeed, imx6q_suspend_init() doesn't have a
>> corresponding put_device(). Thus add a jump target to fix the exception
>> handling for this function implementation.
>
> Do you find a previous update suggestion useful?
>
> ARM: imx6: Add missing put_device() call in imx6q_suspend_init()
> https://lore.kernel.org/linux-arm-kernel/5acd7308-f6e1-4b1e-c744-bb2e5fdca1be@web.de/
> https://lore.kernel.org/patchwork/patch/1151158/
> https://lkml.org/lkml/2019/11/9/125
Hi, Markus
It is useful indeed. Although I didn't run cocci script, since it can
produce too many false result which is hard to filter out.
BTW, I see you haver done the work already, I guess I won't send any
patches related to 'missing put_device after of_find_device_by_node()'.
Any idea why these pathes didn't get applied ?
Best regards,
Yu Kuai
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dma-direct: provide the ability to reserve per-numa CMA
From: Dan Carpenter @ 2020-06-05 8:57 UTC (permalink / raw)
To: Song Bao Hua (Barry Song)
Cc: Dan Carpenter, lkp@intel.com, catalin.marinas@arm.com,
kbuild@lists.01.org, John Garry, linux-kernel@vger.kernel.org,
Linuxarm, iommu@lists.linux-foundation.org, Jonathan Cameron,
kbuild-all@lists.01.org, robin.murphy@arm.com, hch@lst.de,
linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
In-Reply-To: <B926444035E5E2439431908E3842AFD24E0011@DGGEMI525-MBS.china.huawei.com>
On Fri, Jun 05, 2020 at 06:04:31AM +0000, Song Bao Hua (Barry Song) wrote:
>
>
> > -----Original Message-----
> > From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> > Sent: Thursday, June 4, 2020 11:37 PM
> > To: kbuild@lists.01.org; Song Bao Hua (Barry Song)
> > <song.bao.hua@hisilicon.com>; hch@lst.de; m.szyprowski@samsung.com;
> > robin.murphy@arm.com; catalin.marinas@arm.com
> > Cc: lkp@intel.com; Dan Carpenter <error27@gmail.com>;
> > kbuild-all@lists.01.org; iommu@lists.linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> > <linuxarm@huawei.com>; Jonathan Cameron
> > <jonathan.cameron@huawei.com>; John Garry <john.garry@huawei.com>
> > Subject: Re: [PATCH 1/3] dma-direct: provide the ability to reserve per-numa
> > CMA
> >
> > Hi Barry,
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Barry-Song/support-per-numa-CM
> > A-for-ARM-server/20200603-104821
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > for-next/core
> > config: x86_64-randconfig-m001-20200603 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Dan, thanks! Good catch!
> as this patch has not been in mainline yet, is it correct to add these "reported-by" in patch v2?
These are just an automated email from the zero day bot. I look over
the Smatch warnings and then forward them on.
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/11] pwm: add support for sl28cpld PWM controller
From: Lee Jones @ 2020-06-05 8:49 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Jason Cooper,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, linux-gpio, Mark Brown, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon,
Greg Kroah-Hartman, linux-kernel, Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <20200604211039.12689-6-michael@walle.cc>
On Thu, 04 Jun 2020, Michael Walle wrote:
> Add support for the PWM controller of the sl28cpld board management
> controller. This is part of a multi-function device driver.
>
> The controller has one PWM channel and can just generate four distinct
> frequencies.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> drivers/pwm/Kconfig | 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-sl28cpld.c | 201 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 212 insertions(+)
> create mode 100644 drivers/pwm/pwm-sl28cpld.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index cb8d739067d2..a39371c11ff6 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -437,6 +437,16 @@ config PWM_SIFIVE
> To compile this driver as a module, choose M here: the module
> will be called pwm-sifive.
>
> +config PWM_SL28CPLD
> + tristate "Kontron sl28 PWM support"
> + depends on MFD_SL28CPLD
> + help
> + Generic PWM framework driver for board management controller
> + found on the Kontron sl28 CPLD.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sl28cpld.
> +
> config PWM_SPEAR
> tristate "STMicroelectronics SPEAr PWM support"
> depends on PLAT_SPEAR || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index a59c710e98c7..c479623724e8 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
> +obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
> obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
> obj-$(CONFIG_PWM_SPRD) += pwm-sprd.o
> obj-$(CONFIG_PWM_STI) += pwm-sti.o
> diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
> new file mode 100644
> index 000000000000..d82303f509f5
> --- /dev/null
> +++ b/drivers/pwm/pwm-sl28cpld.c
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * sl28cpld PWM driver.
> + *
> + * Copyright 2019 Kontron Europe GmbH
This is out of date.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regmap.h>
> +
> +/*
> + * PWM timer block registers.
> + */
> +#define PWM_CTRL 0x00
> +#define PWM_ENABLE BIT(7)
> +#define PWM_MODE_250HZ 0
> +#define PWM_MODE_500HZ 1
> +#define PWM_MODE_1KHZ 2
> +#define PWM_MODE_2KHZ 3
> +#define PWM_MODE_MASK GENMASK(1, 0)
> +#define PWM_CYCLE 0x01
> +#define PWM_CYCLE_MAX 0x7f
> +
> +struct sl28cpld_pwm {
> + struct pwm_chip pwm_chip;
> + struct regmap *regmap;
> + u32 offset;
> +};
> +
> +struct sl28cpld_pwm_periods {
> + u8 ctrl;
> + unsigned long duty_cycle;
> +};
> +
> +struct sl28cpld_pwm_config {
> + unsigned long period_ns;
> + u8 max_duty_cycle;
> +};
Also, instead of hand rolling your own structure here, I think it
would be prudent to re-use something that already exists. Seeing as
this will be used to describe possible state, perhaps 'struct
pwm_state' would be suitable - leaving polarity and enabled
unpopulated of course.
Ah wait (sorry, thinking allowed and on-the-fly here), what is
max_duty_cycle here? I assume this does not have the same
meaning/value-type as the one in 'struct pwm_state'. What does
max_duty_cycle represent in your use-case?
> +static struct sl28cpld_pwm_config sl28cpld_pwm_config[] = {
> + [PWM_MODE_250HZ] = { .period_ns = 4000000, .max_duty_cycle = 0x80 },
> + [PWM_MODE_500HZ] = { .period_ns = 2000000, .max_duty_cycle = 0x40 },
> + [PWM_MODE_1KHZ] = { .period_ns = 1000000, .max_duty_cycle = 0x20 },
> + [PWM_MODE_2KHZ] = { .period_ns = 500000, .max_duty_cycle = 0x10 },
> +};
Tiny nit: If you lined these up from the '{'s it would be easier to
see/compare the period_ns values at first glance, rather than having
to count the ' 's and '0's.
> +static inline struct sl28cpld_pwm *to_sl28cpld_pwm(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct sl28cpld_pwm, pwm_chip);
> +}
Why not save yourself the trouble and just:
struct sl28cpld_pwm *pwm = dev_get_drvdata(chip->dev);
> +static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
> + static struct sl28cpld_pwm_config *config;
> + unsigned int reg;
> + unsigned long cycle;
Why is this 'long' here and 'long long' in *_apply()?
> + unsigned int mode;
> +
> + regmap_read(spc->regmap, spc->offset + PWM_CTRL, ®);
> +
> + state->enabled = reg & PWM_ENABLE;
> +
> + mode = FIELD_GET(PWM_MODE_MASK, reg);
> + config = &sl28cpld_pwm_config[mode];
> + state->period = config->period_ns;
> +
> + regmap_read(spc->regmap, spc->offset + PWM_CYCLE, ®);
> + cycle = reg * config->period_ns;
> + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(cycle,
> + config->max_duty_cycle);
> +}
> +
> +static int sl28cpld_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct sl28cpld_pwm *spc = to_sl28cpld_pwm(chip);
> + struct sl28cpld_pwm_config *config;
> + unsigned long long cycle;
> + int ret;
> + int mode;
> + u8 ctrl;
> +
> + /* update config, first search best matching period */
Please use correct grammar (less full stops) in comments.
> + for (mode = 0; mode < ARRAY_SIZE(sl28cpld_pwm_config); mode++) {
> + config = &sl28cpld_pwm_config[mode];
> + if (state->period == config->period_ns)
> + break;
> + }
> +
> + if (mode == ARRAY_SIZE(sl28cpld_pwm_config))
> + return -EINVAL;
> +
> + ctrl = FIELD_PREP(PWM_MODE_MASK, mode);
> + if (state->enabled)
> + ctrl |= PWM_ENABLE;
> +
> + cycle = state->duty_cycle * config->max_duty_cycle;
> + do_div(cycle, state->period);
Forgive my ignorance (I'm new here!), but what are these 2 lines
doing? Here we are multiplying the current duty_cycle with the
maximum value, then dividing by the period.
So in the case of PWM_MODE_1KHZ with a 50% duty cycle, you'd have:
(500000 * 0x20[16]) / 1000000 = [0x10]16
Thus, the above gives as a proportional representation of the maximum
valid value for placement into the cycle control register(s), right?
Either way (whether I'm correct or not), I think it would be nice to
mention this in a comment. Maybe even clarify with a simple example.
> + /*
> + * The hardware doesn't allow to set max_duty_cycle if the
> + * 250Hz mode is enabled. But since this is "all-high" output
> + * just use the 500Hz mode with the duty cycle to max value.
> + */
> + if (cycle == config->max_duty_cycle) {
> + ctrl &= ~PWM_MODE_MASK;
> + ctrl |= FIELD_PREP(PWM_MODE_MASK, PWM_MODE_500HZ);
> + cycle = PWM_CYCLE_MAX;
> + }
This is being executed even when 250Hz mode is not enabled.
Is that by design? If so, it doesn't match the comment.
> + ret = regmap_write(spc->regmap, spc->offset + PWM_CTRL, ctrl);
> + if (ret)
> + return ret;
> +
> + return regmap_write(spc->regmap, spc->offset + PWM_CYCLE, (u8)cycle);
> +}
> +
> +static const struct pwm_ops sl28cpld_pwm_ops = {
> + .apply = sl28cpld_pwm_apply,
> + .get_state = sl28cpld_pwm_get_state,
> + .owner = THIS_MODULE,
> +};
> +
> +static int sl28cpld_pwm_probe(struct platform_device *pdev)
> +{
> + struct sl28cpld_pwm *pwm;
This is super confusing. Here you call it 'pwm', but when you bring
the data to the fore for consumption, you call it something different
('spc') for some reason.
Is there logic behind this?
> + struct pwm_chip *chip;
> + int ret;
> +
> + if (!pdev->dev.parent)
> + return -ENODEV;
> +
> + pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
> + if (!pwm)
> + return -ENOMEM;
> +
> + pwm->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!pwm->regmap)
> + return -ENODEV;
> +
> + ret = device_property_read_u32(&pdev->dev, "reg", &pwm->offset);
Really? Can you use the 'reg' property in this way?
Side question:
Do any of your child address spaces actually overlap/intersect?
> + if (ret)
> + return -EINVAL;
> +
> + /* initialize struct pwm_chip */
Proper grammar please.
> + chip = &pwm->pwm_chip;
> + chip->dev = &pdev->dev;
> + chip->ops = &sl28cpld_pwm_ops;
> + chip->base = -1;
> + chip->npwm = 1;
> +
> + ret = pwmchip_add(&pwm->pwm_chip);
> + if (ret < 0)
Is '> 0' even valid?
Suggest "!ret" here, as you have done above.
> + return ret;
> +
> + platform_set_drvdata(pdev, pwm);
> +
> + return 0;
> +}
> +
> +static int sl28cpld_pwm_remove(struct platform_device *pdev)
> +{
> + struct sl28cpld_pwm *pwm = platform_get_drvdata(pdev);
> +
> + return pwmchip_remove(&pwm->pwm_chip);
> +}
> +
> +static const struct of_device_id sl28cpld_pwm_of_match[] = {
> + { .compatible = "kontron,sl28cpld-pwm" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_pwm_of_match);
> +
> +static const struct platform_device_id sl28cpld_pwm_id_table[] = {
> + {"sl28cpld-pwm"},
Spaces either side of the "'s please.
> + {},
> +};
> +MODULE_DEVICE_TABLE(platform, sl28cpld_pwm_id_table);
What are you using this for?
> +static struct platform_driver sl28cpld_pwm_driver = {
> + .probe = sl28cpld_pwm_probe,
> + .remove = sl28cpld_pwm_remove,
> + .id_table = sl28cpld_pwm_id_table,
> + .driver = {
> + .name = KBUILD_MODNAME,
Please just use the quoted name in full.
> + .of_match_table = sl28cpld_pwm_of_match,
> + },
> +};
> +module_platform_driver(sl28cpld_pwm_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld PWM Driver");
"SL28CPLD" ?
> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] spi: bcm2835: Enable shared interrupt support
From: Nicolas Saenz Julienne @ 2020-06-05 8:46 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Scott Branden, lukas, Ray Jui, Mark Brown,
open list:SPI SUBSYSTEM, Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200604212819.715-1-f.fainelli@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5683 bytes --]
Hi Florian,
Thanks for taking over this!
On Thu, 2020-06-04 at 14:28 -0700, Florian Fainelli wrote:
> The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
> SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
I think this isn't 100% correct. SPI0 has its own interrupt, but SPI[3-6] share
the same interrupt.
> For the BCM2835 case which is deemed performance critical, we would like
> to continue using an interrupt handler which does not have the extra
> comparison on BCM2835_SPI_CS_INTR.
>
> To support that requirement the common interrupt handling code between
> the shared and non-shared interrupt paths is split into a
> bcm2835_spi_interrupt_common() and both bcm2835_spi_interrupt() as well
> as bcm2835_spi_shared_interrupt() make use of it.
>
> During probe, we determine if there is at least another instance of this
> SPI controller, and if there is, then we install a shared interrupt
> handler.
As there was pushback to use a different compatible string for an otherwise
identical IP, I think it's a good compromise.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
>
> - identify other available SPI nodes to determine if we need to set-up
> interrupt sharing. This needs to happen for the very first instance
> since we cannot know for the first instance whether interrupt sharing
> is needed or not.
>
> drivers/spi/spi-bcm2835.c | 61 ++++++++++++++++++++++++++++++++-------
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> index 237bd306c268..0288b5b3de1e 100644
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -361,11 +361,10 @@ static void bcm2835_spi_reset_hw(struct spi_controller
> *ctlr)
> bcm2835_wr(bs, BCM2835_SPI_DLEN, 0);
> }
>
> -static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
> +static inline irqreturn_t bcm2835_spi_interrupt_common(struct spi_controller
> *ctlr,
> + u32 cs)
Keep in mind the new 100 character limit.
> {
> - struct spi_controller *ctlr = dev_id;
> struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
> - u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
>
> /*
> * An interrupt is signaled either if DONE is set (TX FIFO empty)
> @@ -394,6 +393,27 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
> +{
> + struct spi_controller *ctlr = dev_id;
> + struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
> + u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
> +
> + return bcm2835_spi_interrupt_common(ctlr, cs);
> +}
> +
> +static irqreturn_t bcm2835_spi_shared_interrupt(int irq, void *dev_id)
> +{
> + struct spi_controller *ctlr = dev_id;
> + struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
> + u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
> +
> + if (!(cs & BCM2835_SPI_CS_INTR))
> + return IRQ_NONE;
> +
> + return bcm2835_spi_interrupt_common(ctlr, cs);
> +}
> +
> static int bcm2835_spi_transfer_one_irq(struct spi_controller *ctlr,
> struct spi_device *spi,
> struct spi_transfer *tfr,
> @@ -1287,12 +1307,37 @@ static int bcm2835_spi_setup(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id bcm2835_spi_match[] = {
> + { .compatible = "brcm,bcm2835-spi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
> +
> static int bcm2835_spi_probe(struct platform_device *pdev)
> {
> + irq_handler_t bcm2835_spi_isr_func = bcm2835_spi_interrupt;
> struct spi_controller *ctlr;
> + unsigned long flags = 0;
> + struct device_node *dn;
> struct bcm2835_spi *bs;
> int err;
>
> + /* On BCM2711 there can be multiple SPI controllers enabled sharing the
> + * same interrupt line, but we also want to minimize the overhead if
> + * there is no need to support interrupt sharing. If we find at least
> + * another available instane (not counting the one we are probed from),
"instance"
> + * then we assume that interrupt sharing is necessary.
> + */
> + for_each_compatible_node(dn, NULL, bcm2835_spi_match[0].compatible) {
> + err = of_device_is_available(dn) && dn != pdev->dev.of_node;
nit: maybe err is not the ideal variable name here.
> + of_node_put(dn);
> + if (err) {
> + flags = IRQF_SHARED;
> + bcm2835_spi_isr_func = bcm2835_spi_shared_interrupt;
> + break;
> + }
> + }
> +
> ctlr = spi_alloc_master(&pdev->dev, ALIGN(sizeof(*bs),
> dma_get_cache_alignment()));
> if (!ctlr)
> @@ -1344,8 +1389,8 @@ static int bcm2835_spi_probe(struct platform_device
> *pdev)
> bcm2835_wr(bs, BCM2835_SPI_CS,
> BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
>
> - err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt, 0,
> - dev_name(&pdev->dev), ctlr);
> + err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_isr_func,
> + flags, dev_name(&pdev->dev), ctlr);
> if (err) {
> dev_err(&pdev->dev, "could not request IRQ: %d\n", err);
> goto out_dma_release;
> @@ -1400,12 +1445,6 @@ static void bcm2835_spi_shutdown(struct platform_device
> *pdev)
> dev_err(&pdev->dev, "failed to shutdown\n");
> }
>
> -static const struct of_device_id bcm2835_spi_match[] = {
> - { .compatible = "brcm,bcm2835-spi", },
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
> -
> static struct platform_driver bcm2835_spi_driver = {
> .driver = {
> .name = DRV_NAME,
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Jian-Hong Pan @ 2020-06-05 8:44 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-arm-kernel, devicetree, Linux Kernel, dri-devel,
Daniel Drake, Eric Anholt, bcm-kernel-feedback-list,
linux-rpi-kernel, Linux Upstreaming Team, linux-clk,
Nicolas Saenz Julienne, linux-i2c
In-Reply-To: <20200602110442.2ceuymhwuomvjj6i@gilmour>
Maxime Ripard <maxime@cerno.tech> 於 2020年6月2日 週二 下午7:04寫道：
>
> Hi,
>
> On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道：
> > >
> > > Hi Daniel,
> > >
> > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > > want.
> > > >
> > > > That would be great, although given the potentially inconsistent
> > > > results we've been seeing so far it would be great if you could
> > > > additionally push a git branch somewhere.
> > > > That way we can have higher confidence that we are applying exactly
> > > > the same patches to the same base etc.
> > >
> > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > > that.
> > >
> > > I've pushed my current branch here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> >
> > Thanks to Maxime!
> >
> > I have tried your repository on branch rpi4-kms. The DRM VC4 is used!
> > But got some issues:
> > 1. Some weird error message in dmesg. Not sure it is related, or not
> > [ 5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> > HDMI state machine clock
> > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389
>
> That's a deferred probing. The first time the HDMI driver is being
> probed, the firmware clock driver has not been probed yet. It's making
> another attempt later on, which succeeds.
>
> > 2. The screen flashes suddenly sometimes.
I append drm.debug=0x3 to boot command. Whenever, the screen flashes,
I notice the logs like this:
Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling
vblank on crtc 3, ret: 0
Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1)
Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling
vblank on crtc 3
Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
auth=1, DRM_IOCTL_MODE_CURSOR
Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
auth=1, DRM_IOCTL_MODE_CURSOR2
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1)
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1)
Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling
vblank on crtc 3, ret: 0
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2)
Here is the full log
https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56
> > 3. The higher resolutions, like 1920x1080 ... are lost after hot
> > re-plug HDMI cable (HDMI0)
I should explain this in more detail. Here are the steps to reproduce
this issue:
1. Before unplug the HDMI cable from HDMI0 port.
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 521mm x 293mm
1920x1080 60.00*+ 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 59.90
1280x960 60.00
1152x864 75.00
1280x720 60.00 50.00 59.94
1440x576 50.00
1024x768 75.03 70.07 60.00
1440x480 60.00 59.94
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)
2. Unplug the HDMI cable from HDMI0 port.
3. Plug the HDMI cable to **HDMI1** port.
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 521mm x 293mm
1920x1080 60.00*+ 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 59.90
1280x960 60.00
1152x864 75.00
1280x720 60.00 50.00 59.94
1440x576 50.00
1024x768 75.03 70.07 60.00
1440x480 60.00 59.94
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
4. Unplug the HDMI cable from **HDMI1** port.
5. Plug the HDMI cable back to HDMI0 port.
$ xrandr
Screen 0: minimum 320 x 200, current 1368 x 768, maximum 2048 x 2048
HDMI-1 connected primary 1368x768+0+0 (normal left inverted right x
axis y axis) 0mm x 0mm
1368x768 59.88*
1360x768 59.80
1280x800 59.81
1152x864 60.00
1280x720 59.86
1024x768 60.00
1024x576 59.90
960x540 59.63
800x600 60.32
800x450 59.82
700x450 59.88
640x480 59.94
684x384 59.88 59.85
680x384 59.80 59.96
640x400 59.88 59.98
576x432 60.06
640x360 59.86 59.83
512x384 60.00
512x288 60.00 59.92
480x270 59.63 59.82
400x300 60.32
320x240 60.05
HDMI-2 disconnected (normal left inverted right x axis y axis)
Jian-Hong Pan
> I'm not sure on how to exactly reproduce those issues (or what they are)
> though, can you expand on this?
>
> Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/43] drm/cma-helper: Rename symbols from drm_cma_gem_ to drm_gem_cma_
From: Laurent Pinchart @ 2020-06-05 8:40 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied,
linus.walleij, liviu.dudau, stefan, philippe.cornu, paul,
benjamin.gaignard, mihail.atanassov, sam, alexandre.torgue, marex,
festevam, abrodkin, ludovic.desroches, xinliang.liu,
kong.kongxinwei, tomi.valkeinen, james.qian.wang, joel, linux-imx,
p.zabel, puck.chen, s.hauer, alison.wang, maarten.lankhorst,
mripard, john.stultz, jsarha, wens, vincent.abriou, kernel,
linux-arm-kernel, mcoquelin.stm32, noralf, bbrezillon, andrew,
dri-devel, yannick.fertre, kieran.bingham+renesas, daniel,
khilman, zourongrong, shawnguo, brian.starkey
In-Reply-To: <20200605073247.4057-2-tzimmermann@suse.de>
Hi Thomas,
Thank you for the patch.
On Fri, Jun 05, 2020 at 09:32:05AM +0200, Thomas Zimmermann wrote:
> This fixes the naming of several symbols within CMA helpers. No functional
> changes are made.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Thank you for the patch.
Speaking of naming, I wish we could rename drm_gem_cma_* to something
else, as those helpers don't use CMA directly (and may not use it at
all), but I think that would be too much intrusive changes for too
little gain :-(
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +-
> drivers/gpu/drm/drm_gem_cma_helper.c | 10 +++++-----
> include/drm/drm_gem_cma_helper.h | 4 ++--
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 6b27242b9ee3c..5e7ea0459d018 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -188,7 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
>
> static struct drm_driver aspeed_gfx_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_create_object = drm_cma_gem_create_object_default_funcs,
> + .gem_create_object = drm_gem_cma_create_object_default_funcs,
> .dumb_create = drm_gem_cma_dumb_create,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c
> index b3db3ca7bd7a7..842e2fa332354 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -572,7 +572,7 @@ void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vunmap);
>
> -static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
> +static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
> .free = drm_gem_cma_free_object,
> .print_info = drm_gem_cma_print_info,
> .get_sg_table = drm_gem_cma_prime_get_sg_table,
> @@ -581,7 +581,7 @@ static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
> };
>
> /**
> - * drm_cma_gem_create_object_default_funcs - Create a CMA GEM object with a
> + * drm_gem_cma_create_object_default_funcs - Create a CMA GEM object with a
> * default function table
> * @dev: DRM device
> * @size: Size of the object to allocate
> @@ -593,7 +593,7 @@ static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
> * A pointer to a allocated GEM object or an error pointer on failure.
> */
> struct drm_gem_object *
> -drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size)
> +drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size)
> {
> struct drm_gem_cma_object *cma_obj;
>
> @@ -601,11 +601,11 @@ drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size)
> if (!cma_obj)
> return NULL;
>
> - cma_obj->base.funcs = &drm_cma_gem_default_funcs;
> + cma_obj->base.funcs = &drm_gem_cma_default_funcs;
>
> return &cma_obj->base;
> }
> -EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
> +EXPORT_SYMBOL(drm_gem_cma_create_object_default_funcs);
>
> /**
> * drm_gem_cma_prime_import_sg_table_vmap - PRIME import another driver's
> diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
> index 947ac95eb24a9..64b7e9d42129a 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -107,7 +107,7 @@ void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj);
> void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
>
> struct drm_gem_object *
> -drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size);
> +drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size);
>
> /**
> * DRM_GEM_CMA_VMAP_DRIVER_OPS - CMA GEM driver operations ensuring a virtual
> @@ -118,7 +118,7 @@ drm_cma_gem_create_object_default_funcs(struct drm_device *dev, size_t size);
> * imported buffers.
> */
> #define DRM_GEM_CMA_VMAP_DRIVER_OPS \
> - .gem_create_object = drm_cma_gem_create_object_default_funcs, \
> + .gem_create_object = drm_gem_cma_create_object_default_funcs, \
> .dumb_create = drm_gem_cma_dumb_create, \
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/5] bus: stm32: Introduce firewall controller helpers
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
The goal of these helpers are to offer an interface for the
hardware blocks controlling bus accesses rights.
Bus firewall controllers are typically used to control if a
hardware block can perform read or write operations on bus.
Smarter firewall controllers could be able to define accesses
rights per hardware blocks to control where they can read
or write.
Firewall controller configurations are provided in device node,
parsed by the helpers and send to the driver to apply them.
Each controller may need different number and type of inputs
to configure the firewall so device-tree properties size have to
be define by using "#firewall-cells".
Firewall configurations properties have to be named "firewall-X"
on device node.
"firewall-names" keyword can also be used to give a name to
a specific configuration.
Example of device-tree:
ctrl0: firewall@0 {
#firewall-cells = <2>;
};
foo: foo@0 {
firewall-names = "default", "setting1";
firewall-0 = <&ctrl0 1 2>;
firewall-1 = <&ctrl0 3 4>;
};
Configurations could be applied with functions like
firewall_set_config_by_index() or firewall_set_config_by_name().
firewall_set_default_config() function will apply the
configuration named "default" (if existing) or the configuration
with index 0 (i.e. firewall-0).
Drivers could register/unregister themselves be calling
firewall_register/firewall_unregister functions.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
version 4:
- use bus API
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 2 +
drivers/bus/stm32/Kconfig | 3 +
drivers/bus/stm32/Makefile | 1 +
drivers/bus/stm32/firewall.c | 251 +++++++++++++++++++++++++++++++++++++++++++
drivers/bus/stm32/firewall.h | 66 ++++++++++++
6 files changed, 325 insertions(+)
create mode 100644 drivers/bus/stm32/Kconfig
create mode 100644 drivers/bus/stm32/Makefile
create mode 100644 drivers/bus/stm32/firewall.c
create mode 100644 drivers/bus/stm32/firewall.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 6d4e4497b59b..843b356322d9 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -203,4 +203,6 @@ config DA8XX_MSTPRI
source "drivers/bus/fsl-mc/Kconfig"
source "drivers/bus/mhi/Kconfig"
+source "drivers/bus/stm32/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 05f32cd694a4..5e0e34b10235 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -37,3 +37,5 @@ obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
# MHI
obj-$(CONFIG_MHI_BUS) += mhi/
+
+obj-$(CONFIG_MACH_STM32MP157) += stm32/
\ No newline at end of file
diff --git a/drivers/bus/stm32/Kconfig b/drivers/bus/stm32/Kconfig
new file mode 100644
index 000000000000..57221e833e2d
--- /dev/null
+++ b/drivers/bus/stm32/Kconfig
@@ -0,0 +1,3 @@
+config FIREWALL_CONTROLLERS
+ bool "Support of bus firewall controllers"
+ depends on OF
diff --git a/drivers/bus/stm32/Makefile b/drivers/bus/stm32/Makefile
new file mode 100644
index 000000000000..eb6b978d6450
--- /dev/null
+++ b/drivers/bus/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_FIREWALL_CONTROLLERS) += firewall.o
diff --git a/drivers/bus/stm32/firewall.c b/drivers/bus/stm32/firewall.c
new file mode 100644
index 000000000000..234571b8ad11
--- /dev/null
+++ b/drivers/bus/stm32/firewall.c
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "firewall.h"
+
+struct firewall_device {
+ struct device dev;
+ struct firewall_ops *ops;
+};
+
+struct device firewall_bus = {
+ .init_name = "firewall",
+};
+
+static inline struct firewall_device *to_firewall_device(struct device *d)
+{
+ return container_of(d, struct firewall_device, dev);
+}
+
+static struct bus_type firewall_bus_type = {
+ .name = "firewall",
+};
+
+static struct firewall_device *firewall_from_node(struct device_node *np)
+{
+ struct device *dev;
+
+ dev = bus_find_device_by_of_node(&firewall_bus_type, np);
+
+ return dev ? to_firewall_device(dev) : NULL;
+}
+
+/**
+ * firewall_dt_has_default
+ *
+ * Check if the device node provide firewall configuration
+ *
+ * @np: device node with possible firewall configuration
+ *
+ * Return: true is firewall-0 property exist in the device node
+ */
+static bool firewall_dt_has_default(struct device_node *np)
+{
+ struct property *prop;
+ int size;
+
+ if (!np)
+ return false;
+
+ prop = of_find_property(np, "firewall-0", &size);
+
+ return prop ? true : false;
+}
+
+/**
+ * firewall_set_config_by_index
+ *
+ * Set a firewall controller configuration based on given index.
+ *
+ * @np: device node with firewall configuration to apply.
+ * @index: the index of the configuration in device node.
+ *
+ * Return: 0 if OK, -EPROBE_DEFER if waiting for firewall controller to be
+ * registered or negative value on other errors.
+ */
+int firewall_set_config_by_index(struct device_node *np, int index)
+{
+ char *propname;
+ int configs, i, err = 0;
+
+ if (!np)
+ return 0;
+
+ propname = kasprintf(GFP_KERNEL, "firewall-%d", index);
+ configs = of_count_phandle_with_args(np, propname, "#firewall-cells");
+ if (configs < 0) {
+ err = -EINVAL;
+ goto error;
+ }
+
+ for (i = 0; i < configs; i++) {
+ struct firewall_device *firewall;
+ struct of_phandle_args args;
+
+ err = of_parse_phandle_with_args(np, propname,
+ "#firewall-cells",
+ i, &args);
+ if (err)
+ goto error;
+
+ /* Test if the controller is (or will be) available */
+ if (!of_device_is_available(args.np)) {
+ of_node_put(args.np);
+ continue;
+ }
+
+ firewall = firewall_from_node(args.np);
+ of_node_put(args.np);
+
+ /* Firewall is not yet registered */
+ if (!firewall) {
+ err = -EPROBE_DEFER;
+ goto error;
+ }
+
+ err = firewall->ops->set_config(&firewall->dev, &args);
+ if (err)
+ goto error;
+ }
+
+error:
+ kfree(propname);
+ return err;
+}
+EXPORT_SYMBOL_GPL(firewall_set_config_by_index);
+
+/**
+ * firewall_set_config_by_name
+ *
+ * Set a firwall controller configuration based on given name.
+ *
+ * @np: device node with firewall configuration to apply.
+ * @name: the name of the configuration in device node.
+ *
+ * Return: 0 if OK, -EPROBE_DEFER if waiting for firewall controller to be
+ * registered or negative value on other errors.
+ */
+int firewall_set_config_by_name(struct device_node *np, char *name)
+{
+ const char *configname;
+ int count, i;
+
+ count = of_property_count_strings(np, "firewall-names");
+ for (i = 0; i < count; i++) {
+ int err;
+
+ err = of_property_read_string_index(np,
+ "firewall-names",
+ i, &configname);
+ if (err)
+ return err;
+
+ if (strcmp(name, configname))
+ continue;
+
+ return firewall_set_config_by_index(np, i);
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(firewall_set_config_by_name);
+
+/**
+ * firewall_set_default_config
+ *
+ * Set the default configuration for device.
+ * First try to apply configuration named "default", if it fails
+ * or doesn't exist, try to apply firewall-0 configuration.
+ *
+ * @np: device node with firewall configuration to apply.
+ *
+ * Return: 0 if OK, -EPROBE_DEFER if waiting for firewall controller to be
+ * registered or negative value on other errors.
+ */
+int firewall_set_default_config(struct device_node *np)
+{
+ int ret;
+
+ /* Nothing to do if device node doesn't contain at least
+ * one configuration
+ */
+ if (!firewall_dt_has_default(np))
+ return 0;
+
+ ret = firewall_set_config_by_name(np, "default");
+ if (!ret || (ret == -EPROBE_DEFER))
+ return ret;
+
+ return firewall_set_config_by_index(np, 0);
+}
+EXPORT_SYMBOL_GPL(firewall_set_default_config);
+
+/**
+ * firewall_register
+ *
+ * Register a firewall controller.
+ *
+ * @np: node implementing firewall controller.
+ * @ops: firewall controller operations.
+ *
+ * Return: a pointer on the device if OK or NULL on error.
+ */
+struct device *firewall_register(struct device_node *np,
+ struct firewall_ops *ops)
+{
+ struct firewall_device *firewall;
+
+ if (!np || !ops || !ops->set_config)
+ return NULL;
+
+ firewall = kzalloc(sizeof(*firewall), GFP_KERNEL);
+ if (!firewall)
+ return NULL;
+
+ device_initialize(&firewall->dev);
+ firewall->dev.init_name = devm_kstrdup(&firewall->dev,
+ np->name, GFP_KERNEL);
+ firewall->dev.bus = &firewall_bus_type;
+ firewall->dev.parent = &firewall_bus;
+ firewall->dev.of_node = np;
+ firewall->ops = ops;
+
+ if (device_add(&firewall->dev)) {
+ kfree(firewall);
+ return NULL;
+ }
+
+ return &firewall->dev;
+}
+EXPORT_SYMBOL_GPL(firewall_register);
+
+static int __init firewall_init(void)
+{
+ int ret;
+
+ ret = device_register(&firewall_bus);
+ if (ret) {
+ put_device(&firewall_bus);
+ return ret;
+ }
+
+ ret = bus_register(&firewall_bus_type);
+ if (ret)
+ device_unregister(&firewall_bus);
+
+ return ret;
+}
+
+/* Init early since drivers really need to configure firewall early */
+core_initcall(firewall_init);
diff --git a/drivers/bus/stm32/firewall.h b/drivers/bus/stm32/firewall.h
new file mode 100644
index 000000000000..ea38f9f7e4ee
--- /dev/null
+++ b/drivers/bus/stm32/firewall.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#ifndef _FIREWALL_H_
+#define _FIREWALL_H_
+
+#include <linux/device.h>
+#include <linux/of.h>
+
+/**
+ * struct firewall_ops
+ *
+ * Firewall controller operations structure to be filled by drivers.
+ */
+struct firewall_ops {
+ /**
+ * @set_config:
+ *
+ * Driver callback to set a firewall configuration on a controller.
+ * Configuration arguments are provided in out_args parameter.
+ *
+ * Return: 0 on success, a negative error code on failure.
+ */
+ int (*set_config)(struct device *dev, struct of_phandle_args *out_args);
+};
+
+#ifdef CONFIG_FIREWALL_CONTROLLERS
+
+int firewall_set_config_by_index(struct device_node *np, int index);
+int firewall_set_config_by_name(struct device_node *np, char *name);
+int firewall_set_default_config(struct device_node *np);
+
+struct device *firewall_register(struct device_node *np,
+ struct firewall_ops *ops);
+
+#else
+
+static inline int firewall_set_config_by_index(struct device_node *np,
+ int index)
+{
+ return 0;
+}
+
+static inline int firewall_set_config_by_name(struct device_node *np,
+ char *name)
+{
+ return 0;
+}
+
+static inline int firewall_set_default_config(struct device_node *np)
+{
+ return 0;
+}
+
+static inline struct device *firewall_register(struct device_node *np,
+ struct firewall_ops *ops)
+{
+ return NULL;
+}
+
+#endif
+
+#endif /* _FIREWALL_H_ */
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 4/5] bus: stm32: Add stm32 ETZPC firewall bus controller
From: Benjamin Gaignard @ 2020-06-05 8:33 UTC (permalink / raw)
To: robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij, gregkh
Cc: Benjamin Gaignard, tomase, linux-kernel, stefano.stabellini,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200605083348.13880-1-benjamin.gaignard@st.com>
Add STM32 Extended TrustZone Protection bus controller.
For each of device-tree nodes it will check and apply
firewall configuration. If it doesn't match the device
will not be probed by platform bus.
A device could be configured to be accessible by trusted world,
co-processor or non-secure world.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/bus/stm32/Kconfig | 8 ++
drivers/bus/stm32/Makefile | 1 +
drivers/bus/stm32/stm32-etzpc.c | 163 ++++++++++++++++++++++++++++
include/dt-bindings/bus/stm32/stm32-etzpc.h | 90 +++++++++++++++
4 files changed, 262 insertions(+)
create mode 100644 drivers/bus/stm32/stm32-etzpc.c
create mode 100644 include/dt-bindings/bus/stm32/stm32-etzpc.h
diff --git a/drivers/bus/stm32/Kconfig b/drivers/bus/stm32/Kconfig
index 57221e833e2d..5dc6e2504de5 100644
--- a/drivers/bus/stm32/Kconfig
+++ b/drivers/bus/stm32/Kconfig
@@ -1,3 +1,11 @@
config FIREWALL_CONTROLLERS
bool "Support of bus firewall controllers"
depends on OF
+
+config STM32_ETZPC
+ bool "STM32 ETZPC bus controller"
+ depends on MACH_STM32MP157
+ select FIREWALL_CONTROLLERS
+ help
+ Select y to enable STM32 Extended TrustZone Protection
+ Controller (ETZPC)
diff --git a/drivers/bus/stm32/Makefile b/drivers/bus/stm32/Makefile
index eb6b978d6450..d42e99b5865e 100644
--- a/drivers/bus/stm32/Makefile
+++ b/drivers/bus/stm32/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_FIREWALL_CONTROLLERS) += firewall.o
+obj-$(CONFIG_STM32_ETZPC) += stm32-etzpc.o
diff --git a/drivers/bus/stm32/stm32-etzpc.c b/drivers/bus/stm32/stm32-etzpc.c
new file mode 100644
index 000000000000..ad0e16eea66b
--- /dev/null
+++ b/drivers/bus/stm32/stm32-etzpc.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/bus/stm32/stm32-etzpc.h>
+
+#include "firewall.h"
+
+#define ETZPC_DECPROT 0x010
+#define ETZPC_NUM_LOCKS 94
+
+struct stm32_etzpc {
+ struct regmap_field *fields[ETZPC_NUM_LOCKS];
+};
+
+static int stm32_etzpc_set_config(struct device *dev,
+ struct of_phandle_args *out_args)
+{
+ struct stm32_etzpc *etzpc = dev_get_drvdata(dev);
+ int index = out_args->args[0];
+ unsigned int value = out_args->args[1];
+ u32 status;
+
+ if (out_args->args_count != 2)
+ return -EINVAL;
+
+ if (index >= ETZPC_NUM_LOCKS)
+ return -EINVAL;
+
+ if (value > STM32_ETZPC_NON_SECURE)
+ return -EINVAL;
+
+ regmap_field_force_write(etzpc->fields[index], value);
+
+ /* Hardware could denied the new value, read it back to check it */
+ regmap_field_read(etzpc->fields[index], &status);
+
+ if (value != status) {
+ pr_info("failed to set configuration: index %d, value %d\n",
+ index, value);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct firewall_ops stm32_etzpc_ops = {
+ .set_config = stm32_etzpc_set_config,
+};
+
+static const struct regmap_config stm32_etzpc_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x3FF,
+};
+
+static void stm32_etzpc_populate(struct device *parent)
+{
+ struct device_node *child;
+
+ if (!parent)
+ return;
+
+ for_each_available_child_of_node(dev_of_node(parent), child) {
+ if (firewall_set_default_config(child)) {
+ /*
+ * Failed to set firewall configuration mark the node
+ * as populated so platform bus won't probe it
+ */
+ of_node_set_flag(child, OF_POPULATED);
+ dev_info(parent, "%s: Bad firewall configuration\n",
+ child->name);
+ }
+ }
+}
+
+static int stm32_etzpc_probe(struct platform_device *pdev)
+{
+ struct stm32_etzpc *etzpc;
+ struct device *firewall;
+ struct regmap *regmap;
+ struct resource *res;
+ void __iomem *mmio;
+ int i;
+
+ etzpc = devm_kzalloc(&pdev->dev, sizeof(*etzpc), GFP_KERNEL);
+ if (!etzpc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mmio = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mmio))
+ return PTR_ERR(mmio);
+
+ regmap = devm_regmap_init_mmio(&pdev->dev, mmio,
+ &stm32_etzpc_regmap_cfg);
+
+ for (i = 0; i < ETZPC_NUM_LOCKS; i++) {
+ struct reg_field field;
+
+ /*
+ * Each hardware block status is defined by
+ * a 2 bits field and all of them are packed into
+ * 32 bits registers. Do some computation to get
+ * register offset and the shift.
+ */
+ field.reg = ETZPC_DECPROT + (i >> 4) * sizeof(u32);
+ field.lsb = (i % 0x10) << 1;
+ field.msb = field.lsb + 1;
+
+ etzpc->fields[i] = devm_regmap_field_alloc(&pdev->dev,
+ regmap, field);
+ }
+
+ platform_set_drvdata(pdev, etzpc);
+
+ firewall = firewall_register(dev_of_node(&pdev->dev),
+ &stm32_etzpc_ops);
+ if (!firewall)
+ return -EINVAL;
+
+ dev_set_drvdata(firewall, etzpc);
+
+ stm32_etzpc_populate(&pdev->dev);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_etzpc_of_match[] = {
+ { .compatible = "st,stm32-etzpc-bus" },
+ { /* end node */ }
+};
+MODULE_DEVICE_TABLE(of, stm32_etzpc_of_match);
+
+static struct platform_driver stm32_etzpc_driver = {
+ .probe = stm32_etzpc_probe,
+ .driver = {
+ .name = "stm32-etzpc",
+ .of_match_table = stm32_etzpc_of_match,
+ },
+};
+
+static int __init stm32_etzpc_init(void)
+{
+ return platform_driver_register(&stm32_etzpc_driver);
+}
+arch_initcall(stm32_etzpc_init);
+
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Bus Firewall Controller");
diff --git a/include/dt-bindings/bus/stm32/stm32-etzpc.h b/include/dt-bindings/bus/stm32/stm32-etzpc.h
new file mode 100644
index 000000000000..9c4783b9783c
--- /dev/null
+++ b/include/dt-bindings/bus/stm32/stm32-etzpc.h
@@ -0,0 +1,90 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ */
+
+#ifndef _STM32_ETZPC_H_
+#define _STM32_ETZPC_H_
+
+/* ETZPC configurations: trust-zone, non-secure or coprocessor*/
+#define STM32_ETZPC_TRUST 1
+#define STM32_ETPCZ_COPRO 2
+#define STM32_ETZPC_NON_SECURE 3
+
+/* ETZPC hard blocks index */
+#define STM32_ETZPC_USART1 3
+#define STM32_ETZPC_SPI6 4
+#define STM32_ETZPC_I2C4 5
+#define STM32_ETZPC_RNG1 7
+#define STM32_ETZPC_HASH1 8
+#define STM32_ETZPC_CRYP1 9
+#define STM32_ETZPC_I2C6 12
+#define STM32_ETZPC_TIM2 16
+#define STM32_ETZPC_TIM3 17
+#define STM32_ETZPC_TIM4 18
+#define STM32_ETZPC_TIM5 19
+#define STM32_ETZPC_TIM6 20
+#define STM32_ETZPC_TIM7 21
+#define STM32_ETZPC_TIM12 22
+#define STM32_ETZPC_TIM13 23
+#define STM32_ETZPC_TIM14 24
+#define STM32_ETZPC_LPTIM1 25
+#define STM32_ETZPC_SPI2 27
+#define STM32_ETZPC_SPI3 28
+#define STM32_ETZPC_USART2 30
+#define STM32_ETZPC_USART3 31
+#define STM32_ETZPC_USART4 32
+#define STM32_ETZPC_USART5 33
+#define STM32_ETZPC_I2C1 34
+#define STM32_ETZPC_I2C2 35
+#define STM32_ETZPC_I2C3 36
+#define STM32_ETZPC_I2C5 37
+#define STM32_ETZPC_CEC 38
+#define STM32_ETZPC_DAC 39
+#define STM32_ETZPC_UART7 40
+#define STM32_ETZPC_UART8 41
+#define STM32_ETZPC_MDIOS 44
+#define STM32_ETZPC_TIM1 48
+#define STM32_ETZPC_TIM8 49
+#define STM32_ETZPC_USART6 51
+#define STM32_ETZPC_SPI1 52
+#define STM32_ETZPC_SPI4 53
+#define STM32_ETZPC_TIM15 54
+#define STM32_ETZPC_TIM16 55
+#define STM32_ETZPC_TIM17 56
+#define STM32_ETZPC_SPI5 57
+#define STM32_ETZPC_SAI1 58
+#define STM32_ETZPC_SAI2 59
+#define STM32_ETZPC_SAI3 60
+#define STM32_ETZPC_DFSDM 61
+#define STM32_ETZPC_TT_FDCAN 62
+#define STM32_ETZPC_LPTIM2 64
+#define STM32_ETZPC_LPTIM3 65
+#define STM32_ETZPC_LPTIM4 66
+#define STM32_ETZPC_LPTIM5 67
+#define STM32_ETZPC_SAI4 68
+#define STM32_ETZPC_VREFBUF 69
+#define STM32_ETZPC_DCMI 70
+#define STM32_ETZPC_CRC2 71
+#define STM32_ETZPC_ADC 72
+#define STM32_ETZPC_HASH2 73
+#define STM32_ETZPC_RNG2 74
+#define STM32_ETZPC_CRYP2 75
+#define STM32_ETZPC_SRAM1 80
+#define STM32_ETZPC_SRAM2 81
+#define STM32_ETZPC_SRAM3 82
+#define STM32_ETZPC_SRAM4 83
+#define STM32_ETZPC_RETRAM 84
+#define STM32_ETZPC_OTG 85
+#define STM32_ETZPC_SDMMC3 86
+#define STM32_ETZPC_DLYBSD3 87
+#define STM32_ETZPC_DMA1 88
+#define STM32_ETZPC_DMA2 89
+#define STM32_ETZPC_DMAMUX 90
+#define STM32_ETZPC_FMC 91
+#define STM32_ETZPC_QSPI 92
+#define STM32_ETZPC_DLYBQ 93
+#define STM32_ETZPC_ETH1 94
+
+#endif /* _STM32_ETZPC_H_ */
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox