* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Update the SP805 binding document to add optional 'timeout-sec'
devicetree property
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
index edc4f0e..f898a86 100644
--- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
@@ -19,6 +19,8 @@ Required properties:
Optional properties:
- interrupts : Should specify WDT interrupt number.
+- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
+ default timeout is 30 seconds
Examples:
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] watchdog: sp805: add 'timeout-sec' DT property support
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Add support for optional devicetree property 'timeout-sec'.
'timeout-sec' is used in the driver if specified in devicetree.
Otherwise, fall back to driver default, i.e., 60 seconds
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/watchdog/sp805_wdt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 03805bc..1484609 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -230,7 +230,14 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
spin_lock_init(&wdt->lock);
watchdog_set_nowayout(&wdt->wdd, nowayout);
watchdog_set_drvdata(&wdt->wdd, wdt);
- wdt_setload(&wdt->wdd, DEFAULT_TIMEOUT);
+
+ /*
+ * If 'timeout-sec' devicetree property is specified, use that.
+ * Otherwise, use DEFAULT_TIMEOUT
+ */
+ wdt->wdd.timeout = DEFAULT_TIMEOUT;
+ watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
+ wdt_setload(&wdt->wdd, wdt->wdd.timeout);
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should reset the watchdog and
tell the watchdog framework. As a result, ping can be generated from
the watchdog framework, until the userspace watchdog daemon takes over
control
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 1484609..408ffbe 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -42,6 +42,7 @@
/* control register masks */
#define INT_ENABLE (1 << 0)
#define RESET_ENABLE (1 << 1)
+ #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
#define WDTINTCLR 0x00C
#define WDTRIS 0x010
#define WDTMIS 0x014
@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout,
"Set to 1 to keep watchdog running after device release");
+/* returns true if wdt is running; otherwise returns false */
+static bool wdt_is_running(struct watchdog_device *wdd)
+{
+ struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
+ ENABLE_MASK)
+ return true;
+ else
+ return false;
+}
+
/* This routine finds load value that will reset system in required timout */
static int wdt_setload(struct watchdog_device *wdd, unsigned int timeout)
{
@@ -239,6 +252,15 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
watchdog_init_timeout(&wdt->wdd, 0, &adev->dev);
wdt_setload(&wdt->wdd, wdt->wdd.timeout);
+ /*
+ * If HW is already running, enable/reset the wdt and set the running
+ * bit to tell the wdt subsystem
+ */
+ if (wdt_is_running(&wdt->wdd)) {
+ wdt_enable(&wdt->wdd);
+ set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
+ }
+
ret = watchdog_register_device(&wdt->wdd);
if (ret) {
dev_err(&adev->dev, "watchdog_register_device() failed: %d\n",
--
2.1.4
^ permalink raw reply related
* [PATCH 4/5] arm64: dt: set initial SR watchdog timeout to 60 seconds
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Set initial Stingray watchdog timeout to 60 seconds
By the time when the userspace watchdog daemon is ready and taking
control over, the watchdog timeout will then be reset to what's
configured in the daemon
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..1e1cf49 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -420,6 +420,7 @@
interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&hsls_25m_div2_clk>, <&hsls_div4_clk>;
clock-names = "wdogclk", "apb_pclk";
+ timeout-sec = <60>;
};
gpio_hsls: gpio at d0000 {
--
2.1.4
^ permalink raw reply related
* [PATCH 5/5] arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
From: Ray Jui @ 2018-05-22 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527014840-21236-1-git-send-email-ray.jui@broadcom.com>
Enable the SP805 watchdog timer
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..3fe5eb5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -351,6 +351,7 @@ CONFIG_ROCKCHIP_THERMAL=m
CONFIG_TEGRA_BPMP_THERMAL=m
CONFIG_UNIPHIER_THERMAL=y
CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MESON_GXBB_WATCHDOG=m
CONFIG_MESON_WATCHDOG=m
--
2.1.4
^ permalink raw reply related
* [PATCH] arm64: dts: stingray: move common board components to stingray-board-base
From: Scott Branden @ 2018-05-22 18:55 UTC (permalink / raw)
To: linux-arm-kernel
Move common board components from base bcm958742 dtsi file to new
stingray-board-base dtsi file so they can be shared between many stingray
boards following common design.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
.../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 35 +--------------
.../dts/broadcom/stingray/stingray-board-base.dtsi | 51 ++++++++++++++++++++++
2 files changed, 52 insertions(+), 34 deletions(-)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..d74f6df 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -30,20 +30,9 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include "stingray.dtsi"
+#include "stingray-board-base.dtsi"
/ {
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- aliases {
- serial0 = &uart1;
- serial1 = &uart0;
- serial2 = &uart2;
- serial3 = &uart3;
- };
-
sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
compatible = "regulator-gpio";
regulator-name = "sdio0_vddo_ctrl_reg";
@@ -67,23 +56,6 @@
};
};
-&memory { /* Default DRAM banks */
- reg = <0x00000000 0x80000000 0x0 0x80000000>, /* 2G @ 2G */
- <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
-};
-
-&mdio_mux_iproc {
- mdio at 10 {
- gphy0: eth-phy at 10 {
- reg = <0x10>;
- };
- };
-};
-
-&uart1 {
- status = "okay";
-};
-
&pwm {
status = "okay";
};
@@ -111,8 +83,6 @@
};
&enet {
- phy-mode = "rgmii-id";
- phy-handle = <&gphy0>;
status = "okay";
};
@@ -133,13 +103,10 @@
&sdio0 {
vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
- non-removable;
- full-pwr-cycle;
status = "okay";
};
&sdio1 {
vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
- full-pwr-cycle;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
new file mode 100644
index 0000000..82a2471
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ * Copyright(c) 2016-2018 Broadcom
+ */
+
+#include "stingray.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart0;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&memory { /* Default DRAM banks */
+ reg = <0x00000000 0x80000000 0x0 0x80000000>, /* 2G @ 2G */
+ <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
+};
+
+&enet {
+ phy-mode = "rgmii-id";
+ phy-handle = <&gphy0>;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&sdio0 {
+ non-removable;
+ full-pwr-cycle;
+};
+
+&sdio1 {
+ full-pwr-cycle;
+};
+
+&mdio_mux_iproc {
+ mdio at 10 {
+ gphy0: eth-phy at 10 {
+ reg = <0x10>;
+ };
+ };
+};
--
2.5.0
^ permalink raw reply related
* [PATCHv2 06/12] arm64: add basic pointer authentication support
From: Adam Wallis @ 2018-05-22 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171127163806.31435-7-mark.rutland@arm.com>
On 11/27/2017 11:38 AM, Mark Rutland wrote:
> This patch adds basic support for pointer authentication, allowing
> userspace to make use of APIAKey. The kernel maintains an APIAKey value
> for each process (shared by all threads within), which is initialised to
> a random value at exec() time.
>
> To describe that address authentication instructions are available, the
> ID_AA64ISAR0.{APA,API} fields are exposed to userspace. A new hwcap,
> APIA, is added to describe that the kernel manages APIAKey.
>
> Instructions using other keys (APIBKey, APDAKey, APDBKey) are disabled,
> and will behave as NOPs. These may be made use of in future patches.
>
> No support is added for the generic key (APGAKey), though this cannot be
> trapped or made to behave as a NOP. Its presence is not advertised with
> a hwcap.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/mmu.h | 5 ++
> arch/arm64/include/asm/mmu_context.h | 25 +++++++++-
> arch/arm64/include/asm/pointer_auth.h | 89 +++++++++++++++++++++++++++++++++++
> arch/arm64/include/uapi/asm/hwcap.h | 1 +
> arch/arm64/kernel/cpufeature.c | 17 ++++++-
> arch/arm64/kernel/cpuinfo.c | 1 +
> 6 files changed, 134 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/include/asm/pointer_auth.h
Mark, I was able to verify that a buffer overflow exploit results in a segfault
with these PAC patches. When I compile the same binary without
"-msign-return-address=none", I am able to successfully overflow the stack and
execute malicious code.
Thanks
Adam
Tested-by: Adam Wallis <awallis@codeaurora.org>
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCHv4 06/10] arm64: add basic pointer authentication support
From: Adam Wallis @ 2018-05-22 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503132031.25705-7-mark.rutland@arm.com>
On 5/3/2018 9:20 AM, Mark Rutland wrote:
> This patch adds basic support for pointer authentication, allowing
> userspace to make use of APIAKey. The kernel maintains an APIAKey value
> for each process (shared by all threads within), which is initialised to
> a random value at exec() time.
>
> To describe that address authentication instructions are available, the
> ID_AA64ISAR0.{APA,API} fields are exposed to userspace. A new hwcap,
> APIA, is added to describe that the kernel manages APIAKey.
>
> Instructions using other keys (APIBKey, APDAKey, APDBKey) are disabled,
> and will behave as NOPs. These may be made use of in future patches.
>
> No support is added for the generic key (APGAKey), though this cannot be
> trapped or made to behave as a NOP. Its presence is not advertised with
> a hwcap.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
Mark, I was able to verify that a buffer overflow exploit results in a segfault
with these PAC patches. When I compile the same binary without
"-msign-return-address=none", I am able to successfully overflow the stack and
execute malicious code.
Thanks
Adam
Tested-by: Adam Wallis <awallis@codeaurora.org>
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/2] ARM: pxa: dts: add gpio-ranges to gpio controller
From: Robert Jarzmik @ 2018-05-22 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521220044.821-1-daniel@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> The PXA GPIO driver calls out to the pinctrl driver for claiming pins
> unless the config has CONFIG_PINCTRL unset. IOW, if a pinctrl driver is
> active, it must be visible to the GPIO driver.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Applied to pxa/dt, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [v4 05/11] ARM: dts: aspeed: peci: Add PECI node
From: kbuild test robot @ 2018-05-22 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521195846.27894-1-jae.hyun.yoo@linux.intel.com>
Hi Jae,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jae-Hyun-Yoo/dt-bindings-Add-a-document-of-PECI-subsystem/20180522-204411
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/aspeed-g5.dtsi:382.21-22 syntax error
FATAL ERROR: Unable to parse input tree
--
>> Error: arch/arm/boot/dts/aspeed-g4.dtsi:332.21-22 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 64516 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180523/8f62f1c8/attachment-0001.gz>
^ permalink raw reply
* [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
From: Stefan Wahren @ 2018-05-22 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bea3d6c7-a713-c4aa-8ae8-7fec80c5da5d@roeck-us.net>
> Guenter Roeck <linux@roeck-us.net> hat am 22. Mai 2018 um 16:10 geschrieben:
>
>
> On 05/22/2018 06:51 AM, Stefan Wahren wrote:
> > Hi Guenter,
> >
> >> Guenter Roeck <linux@roeck-us.net> hat am 22. Mai 2018 um 15:41 geschrieben:
> >>
> >>
> >> On 05/22/2018 04:21 AM, Stefan Wahren wrote:
> >>> Currently there is no easy way to detect undervoltage conditions on a
> >>> remote Raspberry Pi. This hwmon driver retrieves the state of the
> >>> undervoltage sensor via mailbox interface. The handling based on
> >>> Noralf's modifications to the downstream firmware driver. In case of
> >>> an undervoltage condition only an entry is written to the kernel log.
> >>>
> >>> CC: "Noralf Tr?nnes" <noralf@tronnes.org>
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> Documentation/hwmon/raspberrypi-hwmon | 22 +++++
> >>> drivers/hwmon/Kconfig | 10 ++
> >>> drivers/hwmon/Makefile | 1 +
> >>> drivers/hwmon/raspberrypi-hwmon.c | 168 ++++++++++++++++++++++++++++++++++
> >>> 4 files changed, 201 insertions(+)
> >>> create mode 100644 Documentation/hwmon/raspberrypi-hwmon
> >>> create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> >>>
> >>> diff --git a/Documentation/hwmon/raspberrypi-hwmon b/Documentation/hwmon/raspberrypi-hwmon
> >>> new file mode 100644
> >>> index 0000000..3c92e2c
> >>> --- /dev/null
> >>> +++ b/Documentation/hwmon/raspberrypi-hwmon
> >>> @@ -0,0 +1,22 @@
> >>> +Kernel driver raspberrypi-hwmon
> >>> +===============================
> >>> +
> >>> +Supported boards:
> >>> + * Raspberry Pi A+ (via GPIO on SoC)
> >>> + * Raspberry Pi B+ (via GPIO on SoC)
> >>> + * Raspberry Pi 2 B (via GPIO on SoC)
> >>> + * Raspberry Pi 3 B (via GPIO on port expander)
> >>> + * Raspberry Pi 3 B+ (via PMIC)
> >>> +
> >>> +Author: Stefan Wahren <stefan.wahren@i2se.com>
> >>> +
> >>> +Description
> >>> +-----------
> >>> +
> >>> +This driver periodically polls a mailbox property of the VC4 firmware to detect
> >>> +undervoltage conditions.
> >>> +
> >>> +Sysfs entries
> >>> +-------------
> >>> +
> >>> +in0_lcrit_alarm Undervoltage alarm
> >>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> >>> index 768aed5..9a5bdb0 100644
> >>> --- a/drivers/hwmon/Kconfig
> >>> +++ b/drivers/hwmon/Kconfig
> >>> @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> >>> This driver can also be built as a module. If so, the module
> >>> will be called pwm-fan.
> >>>
> >>> +config SENSORS_RASPBERRYPI_HWMON
> >>> + tristate "Raspberry Pi voltage monitor"
> >>> + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> >>> + help
> >>> + If you say yes here you get support for voltage sensor on the
> >>> + Raspberry Pi.
> >>> +
> >>> + This driver can also be built as a module. If so, the module
> >>> + will be called raspberrypi-hwmon.
> >>> +
> >>> config SENSORS_SHT15
> >>> tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
> >>> depends on GPIOLIB || COMPILE_TEST
> >>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> >>> index e7d52a3..a929770 100644
> >>> --- a/drivers/hwmon/Makefile
> >>> +++ b/drivers/hwmon/Makefile
> >>> @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> >>> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> >>> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> >>> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> >>> +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o
> >>> obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> >>> obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> >>> obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
> >>> diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
> >>> new file mode 100644
> >>> index 0000000..6233e84
> >>> --- /dev/null
> >>> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> >>> @@ -0,0 +1,168 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Raspberry Pi voltage sensor driver
> >>> + *
> >>> + * Based on firmware/raspberrypi.c by Noralf Tr?nnes
> >>> + *
> >>> + * Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
> >>> + */
> >>> +#include <linux/device.h>
> >>> +#include <linux/err.h>
> >>> +#include <linux/hwmon.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/platform_device.h>
> >>> +#include <linux/slab.h>
> >>> +#include <linux/workqueue.h>
> >>> +#include <soc/bcm2835/raspberrypi-firmware.h>
> >>> +
> >>> +#define UNDERVOLTAGE_STICKY_BIT BIT(16)
> >>> +
> >>> +struct rpi_hwmon_data {
> >>> + struct device *hwmon_dev;
> >>> + struct rpi_firmware *fw;
> >>> + u32 last_throttled;
> >>> + struct delayed_work get_values_poll_work;
> >>> +};
> >>> +
> >>> +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> >>> +{
> >>> + u32 new_uv, old_uv, value;
> >>> + int ret;
> >>> +
> >>> + /* Request firmware to clear sticky bits */
> >>> + value = 0xffff;
> >>> +
> >>> + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> >>> + &value, sizeof(value));
> >>> + if (ret) {
> >>> + dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
> >>> + ret);
> >>> + return;
> >>> + }
> >>> +
> >>> + new_uv = value & UNDERVOLTAGE_STICKY_BIT;
> >>> + old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
> >>> + data->last_throttled = value;
> >>> +
> >>> + if (new_uv == old_uv)
> >>> + return;
> >>> +
> >>> + if (new_uv)
> >>> + dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
> >>> + else
> >>> + dev_info(data->hwmon_dev, "Voltage normalised\n");
> >>> +
> >>> + sysfs_notify(&data->hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
> >>> +}
> >>> +
> >>> +static void get_values_poll(struct work_struct *work)
> >>> +{
> >>> + struct rpi_hwmon_data *data;
> >>> +
> >>> + data = container_of(work, struct rpi_hwmon_data,
> >>> + get_values_poll_work.work);
> >>> +
> >>> + rpi_firmware_get_throttled(data);
> >>> +
> >>> + /*
> >>> + * We can't run faster than the sticky shift (100ms) since we get
> >>> + * flipping in the sticky bits that are cleared.
> >>> + */
> >>> + schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
> >>> +}
> >>> +
> >>> +static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
> >>> + u32 attr, int channel, long *val)
> >>> +{
> >>> + struct rpi_hwmon_data *data = dev_get_drvdata(dev);
> >>> +
> >>> + *val = !!(data->last_throttled & UNDERVOLTAGE_STICKY_BIT);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static umode_t rpi_is_visible(const void *_data, enum hwmon_sensor_types type,
> >>> + u32 attr, int channel)
> >>> +{
> >>> + return 0444;
> >>> +}
> >>> +
> >>> +static const u32 rpi_in_config[] = {
> >>> + HWMON_I_LCRIT_ALARM,
> >>> + 0
> >>> +};
> >>> +
> >>> +static const struct hwmon_channel_info rpi_in = {
> >>> + .type = hwmon_in,
> >>> + .config = rpi_in_config,
> >>> +};
> >>> +
> >>> +static const struct hwmon_channel_info *rpi_info[] = {
> >>> + &rpi_in,
> >>> + NULL
> >>> +};
> >>> +
> >>> +static const struct hwmon_ops rpi_hwmon_ops = {
> >>> + .is_visible = rpi_is_visible,
> >>> + .read = rpi_read,
> >>> +};
> >>> +
> >>> +static const struct hwmon_chip_info rpi_chip_info = {
> >>> + .ops = &rpi_hwmon_ops,
> >>> + .info = rpi_info,
> >>> +};
> >>> +
> >>> +static int rpi_hwmon_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct device *dev = &pdev->dev;
> >>> + struct rpi_hwmon_data *data;
> >>> + int ret;
> >>> +
> >>> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >>> + if (!data)
> >>> + return -ENOMEM;
> >>> +
> >>> + data->fw = platform_get_drvdata(to_platform_device(dev->parent));
> >>> + if (!data->fw)
> >>> + return -EPROBE_DEFER;
> >>> +
> >>
> >> I am a bit at loss here (and sorry I didn't bring this up before).
> >> How would this ever be possible, given that the driver is registered
> >> from the firmware driver ?
> >
> > Do you refer to the (wrong) return code, the assumption that the parent must be a platform driver or a possible race?
> >
>
> The return code is one thing. My question was how the driver would ever be instantiated
> with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but dev->parent != NULL),
> so I referred to the race. But, sure, a second question would be how that would indicate
> that the parent is not instantiated yet (which by itself seems like an odd question).
This shouldn't happen and worth a log error. In patch #3 the registration is called after the complete private data of the firmware driver is initialized. Did i missed something?
But i must confess that i didn't test all builtin/module combinations.
>
> Yet another question, as you point out, is why to use platform_get_drvdata(to_platform_device(dev->parent))
> instead of dev_get_drvdata(dev->parent).
Sure this is much simpler
Thanks
Stefan
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC
From: Rob Herring @ 2018-05-22 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-2-manivannan.sadhasivam@linaro.org>
On Sun, May 20, 2018 at 10:47:32AM +0530, Manivannan Sadhasivam wrote:
> Add gpio bindings for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../devicetree/bindings/pinctrl/actions,s900-pinctrl.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/2] ARM: pxa: dts: add pin definitions for extended GPIOs
From: Robert Jarzmik @ 2018-05-22 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521220044.821-2-daniel@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> The PXA3xx series features some extended GPIO banks which are named GPIO0_2,
> GPIO1_2 etc. The PXA300, PXA310 and PXA320 have different numbers of such
> pins, and they also have variant-specific register offsets.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
> arch/arm/boot/dts/pxa3xx.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
> index a13ac52e4fd2..446e612688c0 100644
> --- a/arch/arm/boot/dts/pxa3xx.dtsi
> +++ b/arch/arm/boot/dts/pxa3xx.dtsi
> @@ -8,6 +8,13 @@
> (gpio <= 98) ? (0x0400 + 4 * (gpio - 27)) : \
> (gpio <= 127) ? (0x0600 + 4 * (gpio - 99)) : \
> 0)
> +#define MFP_PIN_PXA300_0_2 0x674
> +#define MFP_PIN_PXA300_1_2 0x678
> +#define MFP_PIN_PXA300_2_2 0x2dc
> +#define MFP_PIN_PXA300_3_2 0x2e0
> +#define MFP_PIN_PXA300_4_2 0x2e4
> +#define MFP_PIN_PXA300_5_2 0x2e8
> +#define MFP_PIN_PXA300_6_2 0x2ec
To be consistent with the previous items, could it be something like :
#define MFP_PIN_PXA300_2(gpio) \
... etc ...
And so on for the others.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: Andy Shevchenko @ 2018-05-22 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f1970a64be17267e0f044242dc0764d6@codeaurora.org>
On Tue, May 22, 2018 at 9:33 PM, <rishabhb@codeaurora.org> wrote:
> On 2018-05-18 14:01, Andy Shevchenko wrote:
>> On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar
>> <rishabhb@codeaurora.org> wrote:
>>> +#define ACTIVATE 0x1
>>> +#define DEACTIVATE 0x2
>>> +#define ACT_CTRL_OPCODE_ACTIVATE 0x1
>>> +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2
>>> +#define ACT_CTRL_ACT_TRIG 0x1
>>
>>
>> Are these bits? Perhaps BIT() ?
>>
> isn't it just better to use fixed size as u suggest in the next comment?
If the are bits, use BIT() macro.
>>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>>> +{
>>> + const struct llcc_slice_config *cfg;
>>> + struct llcc_slice_desc *desc;
>>> + u32 sz, count = 0;
>>> +
>>> + cfg = drv_data->cfg;
>>> + sz = drv_data->cfg_size;
>>> +
>>
>>
>>> + while (cfg && count < sz) {
>>> + if (cfg->usecase_id == uid)
>>> + break;
>>> + cfg++;
>>> + count++;
>>> + }
>>> + if (cfg == NULL || count == sz)
>>> + return ERR_PTR(-ENODEV);
>>
>>
>> if (!cfg)
>> return ERR_PTR(-ENODEV);
>>
>> while (cfg->... != uid) {
>> cfg++;
>> count++;
>> }
>>
>> if (count == sz)
>> return ...
>>
>> Though I would rather put it to for () loop.
>>
> In each while loop iteration the cfg pointer needs to be checked for
> NULL. What if the usecase id never matches the uid passed by client
> and we keep iterating. At some point it will crash.
do {
if (!cfg || count == sz)
return ...(-ENODEV);
...
} while (...);
Though, as I said for-loop will look slightly better I think.
>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>> + DEACTIVATE);
>>
>>
>> Perhaps one line (~83 characters here is OK) ?
>
> The checkpatch script complains about such lines.
So what if it just 3 characters out?
>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>> + ACTIVATE);
>> Ditto.
>>> + attr1_cfg = bcast_off +
>>> +
>>> LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
>>> + attr0_cfg = bcast_off +
>>> +
>>> LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
>> Ditto.
>>> + attr1_val |= llcc_table[i].probe_target_ways <<
>>> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
>>> + attr1_val |= llcc_table[i].fixed_size <<
>>> + ATTR1_FIXED_SIZE_SHIFT;
>>> + attr1_val |= llcc_table[i].priority <<
>>> ATTR1_PRIORITY_SHIFT;
>> foo |=
>> bar << SHIFT;
>>
>> would look slightly better.
Did you consider this option ?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Aaro Koskinen @ 2018-05-22 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522080250.4fzyvqrgw5oigexn@pali>
Hi,
On Tue, May 22, 2018 at 10:02:50AM +0200, Pali Roh?r wrote:
> Hi! I remember that in time of migration from platform board code to
> device tree structures there appeared some bug which caused that
> sometimes display were not initialized. And somebody figured out that
> display initialization is failing when some other SPI devices are
> initialized before or after display... This behavior was observed only
> on real N900 hardware, not in qemu.
Touchscreen needs to be initialized before display. This is documented
in the DTS, see arch/arm/boot/dts/omap3-n900.dts:
* For some reason, touchscreen is necessary for screen to work at
* all on real hw. It works well without it on emulator.
*
* Also... order in the device tree actually matters here.
> Real reason was never explained. In old platform board code there was
> hardcoded order of SPI devices in which initialization happened. And in
> device tree it is probably in (pseudo)-random order. Enabling/disabling
> various config option can affect some timings and order in which kernel
> starts probing and initializing devices...
The issue was also somewhat present with platform/board code, see e.g.
commit e65f131a14726e5f1b880a528271a52428e5b3a5.
My device worked with v4.17-rc1 (haven't found time to test newer kernels),
but if you say the probe order is random then we must find some proper way
to express the dependency.
A.
^ permalink raw reply
* [PATCH 2/2] ARM: pxa: dts: add pin definitions for extended GPIOs
From: Daniel Mack @ 2018-05-22 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvqzxz5z.fsf@belgarion.home>
On Tuesday, May 22, 2018 09:34 PM, Robert Jarzmik wrote:
> Daniel Mack <daniel@zonque.org> writes:
>
>> The PXA3xx series features some extended GPIO banks which are named GPIO0_2,
>> GPIO1_2 etc. The PXA300, PXA310 and PXA320 have different numbers of such
>> pins, and they also have variant-specific register offsets.
>>
>> Signed-off-by: Daniel Mack <daniel@zonque.org>
>> ---
>> arch/arm/boot/dts/pxa3xx.dtsi | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
>> index a13ac52e4fd2..446e612688c0 100644
>> --- a/arch/arm/boot/dts/pxa3xx.dtsi
>> +++ b/arch/arm/boot/dts/pxa3xx.dtsi
>> @@ -8,6 +8,13 @@
>> (gpio <= 98) ? (0x0400 + 4 * (gpio - 27)) : \
>> (gpio <= 127) ? (0x0600 + 4 * (gpio - 99)) : \
>> 0)
>> +#define MFP_PIN_PXA300_0_2 0x674
>> +#define MFP_PIN_PXA300_1_2 0x678
>> +#define MFP_PIN_PXA300_2_2 0x2dc
>> +#define MFP_PIN_PXA300_3_2 0x2e0
>> +#define MFP_PIN_PXA300_4_2 0x2e4
>> +#define MFP_PIN_PXA300_5_2 0x2e8
>> +#define MFP_PIN_PXA300_6_2 0x2ec
>
> To be consistent with the previous items, could it be something like :
> #define MFP_PIN_PXA300_2(gpio) \
> ... etc ...
>
Ah, yes. Much nicer. Will resend!
Thanks,
Daniel
^ permalink raw reply
* [v4 06/11] drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx
From: kbuild test robot @ 2018-05-22 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521195856.27938-1-jae.hyun.yoo@linux.intel.com>
Hi Jae,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc6 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jae-Hyun-Yoo/dt-bindings-Add-a-document-of-PECI-subsystem/20180522-204411
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/peci/peci-aspeed.c:146:42: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned int [unsigned] val @@ got d int [unsigned] val @@
drivers/peci/peci-aspeed.c:146:42: expected unsigned int [unsigned] val
drivers/peci/peci-aspeed.c:146:42: got restricted __le32
vim +146 drivers/peci/peci-aspeed.c
116
117 static int aspeed_peci_xfer_native(struct aspeed_peci *priv,
118 struct peci_xfer_msg *msg)
119 {
120 long err, timeout = msecs_to_jiffies(priv->cmd_timeout_ms);
121 u32 peci_head, peci_state, rx_data, cmd_sts;
122 unsigned long flags;
123 int i, rc;
124 uint reg;
125
126 /* Check command sts and bus idle state */
127 rc = regmap_read_poll_timeout(priv->regmap, ASPEED_PECI_CMD, cmd_sts,
128 !(cmd_sts & (PECI_CMD_STS_MASK | PECI_CMD_PIN_MON)),
129 PECI_IDLE_CHECK_INTERVAL_USEC, PECI_IDLE_CHECK_TIMEOUT_USEC);
130 if (rc)
131 return rc; /* -ETIMEDOUT */
132
133 spin_lock_irqsave(&priv->lock, flags);
134 reinit_completion(&priv->xfer_complete);
135
136 peci_head = FIELD_PREP(PECI_TAGET_ADDR_MASK, msg->addr) |
137 FIELD_PREP(PECI_WRITE_LEN_MASK, msg->tx_len) |
138 FIELD_PREP(PECI_READ_LEN_MASK, msg->rx_len);
139
140 regmap_write(priv->regmap, ASPEED_PECI_CMD_CTRL, peci_head);
141
142 for (i = 0; i < msg->tx_len; i += 4) {
143 reg = i < 16 ? ASPEED_PECI_W_DATA0 + i % 16 :
144 ASPEED_PECI_W_DATA4 + i % 16;
145 regmap_write(priv->regmap, reg,
> 146 cpu_to_le32p((u32 *)&msg->tx_buf[i]));
147 }
148
149 dev_dbg(priv->dev, "HEAD : 0x%08x\n", peci_head);
150 print_hex_dump_debug("TX : ", DUMP_PREFIX_NONE, 16, 1,
151 msg->tx_buf, msg->tx_len, true);
152
153 priv->status = 0;
154 regmap_write(priv->regmap, ASPEED_PECI_CMD, PECI_CMD_FIRE);
155 spin_unlock_irqrestore(&priv->lock, flags);
156
157 err = wait_for_completion_interruptible_timeout(&priv->xfer_complete,
158 timeout);
159
160 spin_lock_irqsave(&priv->lock, flags);
161 dev_dbg(priv->dev, "INT_STS : 0x%08x\n", priv->status);
162 regmap_read(priv->regmap, ASPEED_PECI_CMD, &peci_state);
163 dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
164 FIELD_GET(PECI_CMD_STS_MASK, peci_state));
165
166 regmap_write(priv->regmap, ASPEED_PECI_CMD, 0);
167
168 if (err <= 0 || priv->status != PECI_INT_CMD_DONE) {
169 if (err < 0) { /* -ERESTARTSYS */
170 rc = (int)err;
171 goto err_irqrestore;
172 } else if (err == 0) {
173 dev_dbg(priv->dev, "Timeout waiting for a response!\n");
174 rc = -ETIMEDOUT;
175 goto err_irqrestore;
176 }
177
178 dev_dbg(priv->dev, "No valid response!\n");
179 rc = -EIO;
180 goto err_irqrestore;
181 }
182
183 /**
184 * Note that rx_len and rx_buf size can be an odd number.
185 * Byte handling is more efficient.
186 */
187 for (i = 0; i < msg->rx_len; i++) {
188 u8 byte_offset = i % 4;
189
190 if (byte_offset == 0) {
191 reg = i < 16 ? ASPEED_PECI_R_DATA0 + i % 16 :
192 ASPEED_PECI_R_DATA4 + i % 16;
193 regmap_read(priv->regmap, reg, &rx_data);
194 }
195
196 msg->rx_buf[i] = (u8)(rx_data >> (byte_offset << 3));
197 }
198
199 print_hex_dump_debug("RX : ", DUMP_PREFIX_NONE, 16, 1,
200 msg->rx_buf, msg->rx_len, true);
201
202 regmap_read(priv->regmap, ASPEED_PECI_CMD, &peci_state);
203 dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
204 FIELD_GET(PECI_CMD_STS_MASK, peci_state));
205 dev_dbg(priv->dev, "------------------------\n");
206
207 err_irqrestore:
208 spin_unlock_irqrestore(&priv->lock, flags);
209 return rc;
210 }
211
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] PCI/portdrv: do not disable device on remove()
From: Ryan Finnie @ 2018-05-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527011883-21320-1-git-send-email-okaya@codeaurora.org>
On 05/22/2018 10:58 AM, Sinan Kaya wrote:
> 'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
> shutdown")' has been added to kernel to shutdown pending PCIe port
> service interrupts during reboot so that a newly started kexec kernel
> wouldn't observe pending interrupts.
>
> pcie_port_device_remove() is disabling the root port and switches by
> calling pci_disable_device() after all PCIe service drivers are shutdown.
>
> pci_disable_device() has a much wider impact then port service itself and
> it prevents all inbound transactions to reach to the system and impacts
> the entire PCI traffic behind the bridge.
>
> Issue is that pcie_port_device_remove() doesn't maintain any coordination
> with the rest of the PCI device drivers in the system before clearing the
> bus master bit.
>
> This has been found to cause crashes on HP DL360 Gen9 machines during
> reboot. Besides, kexec is already clearing the bus master bit in
> pci_device_shutdown() after all PCI drivers are removed.
FAOD, this problem has been observed on both DL360 Gen9 and DL380 Gen9,
in both EFI and legacy modes. I suspect all Gen9 models with the P89
firmware base.
> Just remove the extra clear here.
Thank you! Fix tested on:
- DL360 Gen9
- DL380 Gen9
- DL380 Gen10 (confirmed no regression)
- DL380 G7 (confirmed no regression)
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: stable at vger.kernel.org
> Reported-by: Ryan Finnie <ryan@finnie.org>
Tested-by: Ryan Finnie <ryan@finnie.org>
^ permalink raw reply
* [PATCH] arm64: dts: fix regulator property name for wlan pcie endpoint
From: Niklas Cassel @ 2018-05-22 19:57 UTC (permalink / raw)
To: linux-arm-kernel
The property name vddpe-supply is not included in
Documentation/devicetree/bindings/pci/qcom,pcie.txt
nor in the pcie-qcom PCIe Root Complex driver.
This property name was used in an initial patchset for pcie-qcom,
but was renamed in a later revision.
Therefore, the regulator is currently never enabled, leaving us with
unoperational wlan.
Fix this by using the correct regulator property name, so that wlan
comes up correctly.
Fixes: 1c8ca74a2ea1 ("arm64: dts: apq8096-db820c: Enable wlan and bt en pins")
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
Bluetooth needs a similar patch, but since bluetooth needs some more
work, submit this right now, so we at least have working wlan.
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index 818bf0efd501..804268f54f37 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -203,7 +203,7 @@
pcie at 600000 {
status = "okay";
perst-gpio = <&msmgpio 35 GPIO_ACTIVE_LOW>;
- vddpe-supply = <&wlan_en>;
+ vddpe-3v3-supply = <&wlan_en>;
vddpe1-supply = <&bt_en>;
};
--
2.17.0
^ permalink raw reply related
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Rob Herring @ 2018-05-22 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43ff3894-a287-1558-687c-40f50712735c@ti.com>
On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> On 17/04/18 17:49, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
> > > In typical setup, you can boot a large number of different configs via:
> > >
> > > bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
> > >
> > > ... assuming the configs were named like that, and assuming they would be
> > > compatible with each other. The am57xx-evm example provided is better, as
> > > you can chain the different cameras to the available evm configs.
> >
> > Why not just do it in the bootloader to put together the dtb?
> >
> > Then for external devices, you could just pass info on the
> > kernel cmdline with lcd=foo camera=bar if they cannot be
> > detected over I2C.
>
> (Added Linux ARM list to CC, this was not part of the original delivery.)
>
> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> things like this should be handled? Should we add the DT overlay files to
> kernel tree or not?
IMO, yes.
> Should we add any kind of build infra to kernel tree, and at what level
> would this be? Just DT overlay file building support, and drop the FIT build
> support as was proposed in this RFC series or...?
I think I mentioned this already, but I expect that this is going to
cause a number of conversions of dtsi + dtsi -> dtb into base dts and
overlay(s) dts files. In doing so, we still need to be able to build the
original, full dtb.
> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
> but this is somewhat clumsy approach and is relatively error prone to get it
> right.
Why? How is the kernel better?
> Building the FIT image post kernel build would also be possible, but who
> would be doing this, is there any need to get this done in generic manner or
> shall we just add SoC vendor specific tools for this?
I'll tell you up front, I'm not a fan of FIT image (nor uImage,
Android boot image, $bootloader image). If you want a collection of
files and some configuration data, use a filesystem and a text file.
Rob
^ permalink raw reply
* [PATCH v1 1/7] dt-bindings: pinctrl: add external interrupt support to MT7622 pinctrl
From: Rob Herring @ 2018-05-22 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3898620ef606004aaddc332591ca467f56773029.1526835466.git.sean.wang@mediatek.com>
On Mon, May 21, 2018 at 01:01:47AM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Extend the capability of MT7622 pinctrl with adding EINT so that each
> GPIO can be used to notify CPU when a signal state is changing on the
> line as an external interrupt.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 4/5] arm64: allwinner: h6: add USB3 device nodes
From: Rob Herring @ 2018-05-22 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a25a561-b643-a77b-3287-8082780fce60@cogentembedded.com>
On Tue, May 08, 2018 at 11:31:27AM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 5/7/2018 6:18 PM, Icenowy Zheng wrote:
>
> > Allwinner H6 SoC features USB3 functionality, with a DWC3 controller and
> > a custom PHY.
> >
> > Add device tree nodes for them.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 ++++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index c72da8cd9ef5..9564c938717c 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -174,6 +174,44 @@
> > status = "disabled";
> > };
> > + usb3: usb at 5200000 {
>
> I don't think <unit-address> is allowed for a node having no "reg" prop...
Right. One way to fix is fill out ranges property because the unit
address can come from either.
However, there's work to deprecate doing DWC3 binding with a child node
like this. See the series "usb: dwc3: support clocks and resets for DWC3
core". Please follow that.
Rob
^ permalink raw reply
* [PATCH 1/5] phy: allwinner: add phy driver for USB3 PHY on Allwinner H6 SoC
From: Rob Herring @ 2018-05-22 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507151817.55663-2-icenowy@aosc.io>
On Mon, May 07, 2018 at 11:18:13PM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC contains a USB3 PHY (with USB2 DP/DM lines also
> controlled).
>
> Add a driver for it.
>
> The register operations in this driver is mainly extracted from the BSP
> USB3 driver.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../bindings/phy/sun50i-usb3-phy.txt | 24 +++
Please split bindings to separate patch.
> drivers/phy/allwinner/Kconfig | 13 ++
> drivers/phy/allwinner/Makefile | 1 +
> drivers/phy/allwinner/phy-sun50i-usb3.c | 195 ++++++++++++++++++
> 4 files changed, 233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/sun50i-usb3-phy.txt
> create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/sun50i-usb3-phy.txt b/Documentation/devicetree/bindings/phy/sun50i-usb3-phy.txt
> new file mode 100644
> index 000000000000..912d55f9f69d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/sun50i-usb3-phy.txt
> @@ -0,0 +1,24 @@
> +Allwinner sun50i USB3 PHY
> +-----------------------
> +
> +Required properties:
> +- compatible : should be one of
> + * allwinner,sun60i-h6-usb3-phy
> +- reg : a list of offset + length pairs
> +- #phy-cells : from the generic phy bindings, must be 0
> +- clocks : phandle + clock specifier for the phy clock
> +- resets : phandle + reset specifier for the phy reset
> +
> +Optional Properties:
> +- phy-supply : from the generic phy bindings, a phandle to a regulator that
> + provides power to VBUS.
> +
> +Example:
> + usb3phy: phy at 5210000 {
usb-phy at ...
> + compatible = "allwinner,sun50i-h6-usb3-phy";
> + reg = <0x5210000 0x10000>;
> + clocks = <&ccu CLK_USB_PHY1>;
> + resets = <&ccu RST_USB_PHY1>;
> + #phy-cells = <0>;
> + status = "disabled";
Don't show status in examples.
> + };
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add compatible string for FRWY-LS1012A
From: Rob Herring @ 2018-05-22 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-2-git-send-email-Bhaskar.Upadhaya@nxp.com>
On Tue, May 08, 2018 at 11:59:59AM +0530, Bhaskar Upadhaya wrote:
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/8] dt-bindings: serial: Add bindings for nvidia,tegra194-tcu
From: Rob Herring @ 2018-05-22 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ddaafbd-d8cb-3cca-be4e-8c5c53fd9734@nvidia.com>
On Tue, May 22, 2018 at 04:15:09PM +0100, Jon Hunter wrote:
>
> On 08/05/18 12:43, Mikko Perttunen wrote:
> > Add bindings for the Tegra Combined UART device used to talk to the
> > UART console on Tegra194 systems.
> >
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > .../bindings/serial/nvidia,tegra194-tcu.txt | 35 ++++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
> > new file mode 100644
> > index 000000000000..86763bc5d74f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt
> > @@ -0,0 +1,35 @@
> > +NVIDIA Tegra Combined UART (TCU)
> > +
> > +The TCU is a system for sharing a hardware UART instance among multiple
> > +systems withing the Tegra SoC. It is implemented through a mailbox-
> > +based protocol where each "virtual UART" has a pair of mailboxes, one
> > +for transmitting and one for receiving, that is used to communicate
> > +with the hardware implementing the TCU.
> > +
> > +Required properties:
> > +- name : Should be tcu
> > +- compatible
> > + Array of strings
> > + One of:
> > + - "nvidia,tegra194-tcu"
>
> Nit. We should say what device the above compatibility is applicable for ...
>
> - "nvidia,tegra194-tcu": for Tegra194
Yeah, everyone seems to do that, but I find it to be redundant.
Rob
^ permalink raw reply
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