* [PATCH] arm64: dts: stingray: Add otp device node
From: Florian Fainelli @ 2018-06-04 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527106630-4760-1-git-send-email-scott.branden@broadcom.com>
On 05/23/2018 01:17 PM, Scott Branden wrote:
> Add otp device node for Stingray SOC.
>
> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
line since that is not a bug fix AFAICT.
Thank you
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Scott Branden @ 2018-06-04 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9219029-6e45-1889-6326-470d2bc9e46c@gmail.com>
Hi Florian,
On 18-06-04 02:24 PM, Florian Fainelli wrote:
> On 05/23/2018 01:17 PM, Scott Branden wrote:
>> Add otp device node for Stingray SOC.
>>
>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
> line since that is not a bug fix AFAICT.
It fixes the issue that OTP is not active as it is missing the device node?
>
> Thank you
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Florian Fainelli @ 2018-06-04 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f6f3e76e-eac9-797d-fea5-eac64327ec7f@broadcom.com>
On 06/04/2018 02:30 PM, Scott Branden wrote:
> Hi Florian,
>
>
> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>> Add otp device node for Stingray SOC.
>>>
>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>> line since that is not a bug fix AFAICT.
> It fixes the issue that OTP is not active as it is missing the device node?
By that token, any peripheral that is being added at some point in the
lifetime of this DTS would qualify as a bugfix when it is in fact
feature/peripheral enabling.
I could not see the relationship between the commit being provided in
the "Fixes:" tag and OTP, am I missing something?
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: add ethernet0 alias
From: Florian Fainelli @ 2018-06-04 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503095618.2312-1-peron.clem@gmail.com>
On 05/03/2018 02:56 AM, Cl?ment P?ron wrote:
> In order to avoid Linux generating a random mac address on every boot,
> add an ethernet0 alias that will allow u-boot to patch the dtb with
> the MAC address.
>
> Signed-off-by: Cl?ment P?ron <peron.clem@gmail.com>
Applied to devicetree/next, thanks. Next time, please do include the
proper mailing-lists, that way it does not escape my workflow involving
patchwork behind bcm-kernel-feedback-list at broadcom.com. Thank you
--
Florian
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: correct voltage selector Firefly-RK3399
From: Heinrich Schuchardt @ 2018-06-04 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604171523.28454-1-xypron.glpk@gmx.de>
On 06/04/2018 07:15 PM, Heinrich Schuchardt wrote:
> Without this patch the Firefly-RK3399 board boot process hangs after these
> lines:
>
> fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> fan53555-reg: supplied by vcc_sys
> vcc1v8_s3: supplied by vcc_1v8
>
> Blacklisting driver fan53555 allows booting.
>
> The device tree uses a value of fcs,suspend-voltage-selector different to
> any other board.
>
> Changing this setting to the usual value is sufficient to enable booting.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> index 4f28628aa091..50940ef844a7 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> @@ -458,7 +458,7 @@
> vdd_cpu_b: regulator at 40 {
> compatible = "silergy,syr827";
> reg = <0x40>;
> - fcs,suspend-voltage-selector = <0>;
> + fcs,suspend-voltage-selector = <1>;
The same value <1> is used in the legacy kernel:
https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm64/boot/dts/rockchip/rk3399-firefly-linux.dts
vdd_cpu_b: syr827 at 40 {
compatible = "silergy,syr827";
reg = <0x40>;
vin-supply = <&vcc5v0_sys>;
regulator-compatible = "fan53555-reg";
regulator-name = "vdd_cpu_b";
regulator-min-microvolt = <712500>;
regulator-max-microvolt = <1500000>;
regulator-ramp-delay = <1000>;
vsel-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
fcs,suspend-voltage-selector = <1>;
regulator-always-on;
regulator-boot-on;
regulator-initial-state = <3>;
regulator-state-mem {
regulator-off-in-suspend;
};
};
Best regards
Heinrich
> regulator-name = "vdd_cpu_b";
> regulator-min-microvolt = <712500>;
> regulator-max-microvolt = <1500000>;
>
^ permalink raw reply
* [PATCH] arm64: dts: stingray: move common board components to stingray-board-base
From: Scott Branden @ 2018-06-04 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05b33af8-c938-f124-f918-a9d7f8679d90@gmail.com>
Hi Florian,
On 18-06-04 02:09 PM, Florian Fainelli wrote:
> On 05/22/2018 11:55 AM, Scott Branden wrote:
>> 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>
>
> Applied to devicetree-arm64/next, though this did not apply cleanly,
> please check the results at:
>
> https://github.com/Broadcom/stblinux/commit/0b2cf5a855cd235fa95fbdfedfc524a97a71a7fe
It's looks fine.
>
>> ---
>> .../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>;
>> + };
>> + };
>> +};
>>
>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-axg: fix register ranges for SD/eMMC
From: Kevin Hilman @ 2018-06-04 22:27 UTC (permalink / raw)
To: linux-arm-kernel
Based on updated information from Amlogic, correct the register
range for the SD/eMMC blocks to the right size.
Reported-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
Yixun, please test and confirm this still works on AXG boards.
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index fee87737a201..67d7115e4eff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -132,7 +132,7 @@
sd_emmc_b: sd at 5000 {
compatible = "amlogic,meson-axg-mmc";
- reg = <0x0 0x5000 0x0 0x2000>;
+ reg = <0x0 0x5000 0x0 0x800>;
interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
clocks = <&clkc CLKID_SD_EMMC_B>,
@@ -144,7 +144,7 @@
sd_emmc_c: mmc at 7000 {
compatible = "amlogic,meson-axg-mmc";
- reg = <0x0 0x7000 0x0 0x2000>;
+ reg = <0x0 0x7000 0x0 0x800>;
interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
clocks = <&clkc CLKID_SD_EMMC_C>,
--
2.11.0
^ permalink raw reply related
* [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
From: Bjorn Helgaas @ 2018-06-04 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c2897d82-fe33-52cd-5aa6-3bddb478cb9f@gmail.com>
[+cc ARM64 folks, linux-kernel]
The original patch under discussion is:
https://lkml.kernel.org/r/20180521220514.30256-1-marek.vasut+renesas at gmail.com
On Tue, May 22, 2018 at 11:52:21AM +0200, Marek Vasut wrote:
> On 05/22/2018 10:10 AM, Arnd Bergmann wrote:
> > On Tue, May 22, 2018 at 12:05 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> From: Phil Edworthy <phil.edworthy@renesas.com>
> >>
> >> The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus,
> >> so limit the DMA range to 32bit.
> >>
> >> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >> Cc: Arnd Bergmann <arnd@arndb.de>
> >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> >> Cc: Simon Horman <horms+renesas@verge.net.au>
> >> Cc: Wolfram Sang <wsa@the-dreams.de>
> >> Cc: linux-renesas-soc at vger.kernel.org
> >> To: linux-pci at vger.kernel.org
> >> ---
> >> NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the
> >> discussion seems to have gone way off, so I'm sending this as a
> >> RFC. Any feedback on how to do this limiting properly would be nice.
> >
> > Doing it in the driver is clearly not appropriate, we must do this in
> > common code. If I remember correctly, it's specifically ARM64 that is
> > broken here, it incorrectly allows setting a DMA mask to 64 bit
> > when that is not available.
>
> Yep, that's correct. ARM64 with devices mapping tremendous amounts of
> memory. So did anything change since that discussion references in the NOTE?
>
> --
> Best regards,
> Marek Vasut
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Scott Branden @ 2018-06-04 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <efaf0373-2959-b238-e5f3-ae7e16534384@gmail.com>
On 18-06-04 02:33 PM, Florian Fainelli wrote:
> On 06/04/2018 02:30 PM, Scott Branden wrote:
>> Hi Florian,
>>
>>
>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>> Add otp device node for Stingray SOC.
>>>>
>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>> line since that is not a bug fix AFAICT.
>> It fixes the issue that OTP is not active as it is missing the device node?
> By that token, any peripheral that is being added at some point in the
> lifetime of this DTS would qualify as a bugfix when it is in fact
> feature/peripheral enabling.
>
> I could not see the relationship between the commit being provided in
> the "Fixes:" tag and OTP, am I missing something?
The relationship is the fixes tag points was selected to the last tag
when the commit applies directly against (and is far enough back that it
covers any possible LTS kernels that would have needed it). In this case
I don't care too much about whether this is fixed in LTS or not.? If
needed I'll send a request for the commit be ported to stable.
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Florian Fainelli @ 2018-06-04 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e641f180-0b7e-678c-07c4-834ff0676b34@broadcom.com>
On 06/04/2018 03:33 PM, Scott Branden wrote:
>
>
> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>> Hi Florian,
>>>
>>>
>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>> Add otp device node for Stingray SOC.
>>>>>
>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>> line since that is not a bug fix AFAICT.
>>> It fixes the issue that OTP is not active as it is missing the device
>>> node?
>> By that token, any peripheral that is being added at some point in the
>> lifetime of this DTS would qualify as a bugfix when it is in fact
>> feature/peripheral enabling.
>>
>> I could not see the relationship between the commit being provided in
>> the "Fixes:" tag and OTP, am I missing something?
> The relationship is the fixes tag points was selected to the last tag
> when the commit applies directly against (and is far enough back that it
> covers any possible LTS kernels that would have needed it).
I understand how ones gets to select an appropriate Fixes: tag, what I
don't understand is the relationship between the two changes, like why
would a GPIO Device Tree node influence the OTP peripheral here when
there is no pinmux or GPIO phandle of some sort linking the two. Also,
since you guys were very trigger happy with Fixes: tag lately (referring
to the internal review of Srinath's changes) this one looked a lot like
that.
The only thing I am questioning here is treating that particular
changeset as a bugfix proper. Yes it is technically a fix in that,
without this changeset the OTP node is not there and that is
functionality you want, but it is not preventing the platform from not
booting for instance, or having an incorrect behavior for an established
behavior before, right?
> In this case
> I don't care too much about whether this is fixed in LTS or not.? If
> needed I'll send a request for the commit be ported to stable.
If this is a true fix, I don't mind taking it as-is and keeping the
Fixes: tag, keep in mind the following:
I always treat bug fixes with a higher priority than features, and I
will do my best to queue up fixes (separate branches, all ending in
/fixes) and submit those at any time in the release cycle so they can
land in Linus' tree and in the -stable trees as fast as possible.
Don't bypass the maintainer if you can convince me this is a proper fix,
then I will just move that patch into the appropriate branch, and you
will get those stable backports automatically.
Thanks for reading me.
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Scott Branden @ 2018-06-04 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d6cc541-7987-5b4c-a847-6fcbb27e12d2@gmail.com>
On 18-06-04 03:41 PM, Florian Fainelli wrote:
> On 06/04/2018 03:33 PM, Scott Branden wrote:
>>
>> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>>> Hi Florian,
>>>>
>>>>
>>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>>> Add otp device node for Stingray SOC.
>>>>>>
>>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>>> line since that is not a bug fix AFAICT.
>>>> It fixes the issue that OTP is not active as it is missing the device
>>>> node?
>>> By that token, any peripheral that is being added at some point in the
>>> lifetime of this DTS would qualify as a bugfix when it is in fact
>>> feature/peripheral enabling.
>>>
>>> I could not see the relationship between the commit being provided in
>>> the "Fixes:" tag and OTP, am I missing something?
>> The relationship is the fixes tag points was selected to the last tag
>> when the commit applies directly against (and is far enough back that it
>> covers any possible LTS kernels that would have needed it).
> I understand how ones gets to select an appropriate Fixes: tag, what I
> don't understand is the relationship between the two changes, like why
> would a GPIO Device Tree node influence the OTP peripheral here when
> there is no pinmux or GPIO phandle of some sort linking the two. Also,
> since you guys were very trigger happy with Fixes: tag lately (referring
> to the internal review of Srinath's changes) this one looked a lot like
> that.
>
> The only thing I am questioning here is treating that particular
> changeset as a bugfix proper. Yes it is technically a fix in that,
> without this changeset the OTP node is not there and that is
> functionality you want, but it is not preventing the platform from not
> booting for instance, or having an incorrect behavior for an established
> behavior before, right?
>
>> In this case
>> I don't care too much about whether this is fixed in LTS or not.? If
>> needed I'll send a request for the commit be ported to stable.
> If this is a true fix, I don't mind taking it as-is and keeping the
> Fixes: tag, keep in mind the following:
>
> I always treat bug fixes with a higher priority than features, and I
> will do my best to queue up fixes (separate branches, all ending in
> /fixes) and submit those at any time in the release cycle so they can
> land in Linus' tree and in the -stable trees as fast as possible.
>
> Don't bypass the maintainer if you can convince me this is a proper fix,
> then I will just move that patch into the appropriate branch, and you
> will get those stable backports automatically.
For now, nobody needs it in the LTS.? The OTP driver hasn't actively
been used by applications.
So not critical for backport right now.? It's in now so OTP won't be a
problem going forward.
> Thanks for reading me.
^ permalink raw reply
* [PATCH 7/7] regulator: core: Enable voltage balancing
From: kbuild test robot @ 2018-06-04 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[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/Maciej-Purski/regulator-core-Add-debug-messages/20180605-052333
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: x86_64-randconfig-x011-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//regulator/core.c: In function 'regulator_set_voltage_unlocked':
>> drivers//regulator/core.c:3046:1: error: version control conflict marker in file
<<<<<<< HEAD
^~~~~~~
drivers//regulator/core.c:3048:1: error: version control conflict marker in file
=======
^~~~~~~
vim +3046 drivers//regulator/core.c
3035
3036 static int regulator_set_voltage_unlocked(struct regulator *regulator,
3037 int min_uV, int max_uV,
3038 suspend_state_t state)
3039 {
3040 struct regulator_dev *rdev = regulator->rdev;
3041 struct regulator_voltage *voltage = ®ulator->voltage[state];
3042 int ret = 0;
3043 int old_min_uV, old_max_uV;
3044 int current_uV;
3045
> 3046 <<<<<<< HEAD
3047 pr_err("%s: %d\n", __func__, __LINE__);
3048 =======
3049 if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
3050 rdev_err(rdev, "not all coupled regulators registered\n");
3051 ret = -EPERM;
3052 goto out;
3053 }
3054
---
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: 34005 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/c5e61c9a/attachment-0001.gz>
^ permalink raw reply
* [PATCH 7/7] regulator: core: Enable voltage balancing
From: kbuild test robot @ 2018-06-04 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[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/Maciej-Purski/regulator-core-Add-debug-messages/20180605-052333
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: i386-randconfig-a1-06041847 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/regulator/core.c: In function 'regulator_set_voltage_unlocked':
>> drivers/regulator/core.c:3046:1: error: expected expression before '<<' token
<<<<<<< HEAD
^
drivers/regulator/core.c:3048:1: error: expected expression before '==' token
=======
^
vim +3046 drivers/regulator/core.c
3035
3036 static int regulator_set_voltage_unlocked(struct regulator *regulator,
3037 int min_uV, int max_uV,
3038 suspend_state_t state)
3039 {
3040 struct regulator_dev *rdev = regulator->rdev;
3041 struct regulator_voltage *voltage = ®ulator->voltage[state];
3042 int ret = 0;
3043 int old_min_uV, old_max_uV;
3044 int current_uV;
3045
> 3046 <<<<<<< HEAD
3047 pr_err("%s: %d\n", __func__, __LINE__);
3048 =======
3049 if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
3050 rdev_err(rdev, "not all coupled regulators registered\n");
3051 ret = -EPERM;
3052 goto out;
3053 }
3054
---
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: 26101 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/699454b6/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Zhang, Lei @ 2018-06-04 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F30297@G01JPEXMBKW03>
Hi Marc
Please let me know is there any plan to push your patch to v4.18.
Thanks
Best Regards,
Lei Zhang zhang.lei at fujitsu.com
FUJITSU LIMITED
> -----Original Message-----
> From: linux-arm-kernel
> [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of
> Zhang, Lei
> Sent: Friday, June 01, 2018 10:47 PM
> To: 'Marc Zyngier'; 'linux-arm-kernel at lists.infradead.org'
> Subject: RE: [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
>
> Hi Marc
>
> Thanks. Now I understood the policy of MSI allocation.
> So this patch is great for our bus, and looks no problem for PCI.
>
> Best Regards,
> Lei Zhang zhang.lei at jp.fujitsu.com
> FUJITSU LIMITED
>
> > -----Original Message-----
> > From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> > Sent: Friday, June 01, 2018 9:57 PM
> > To: Zhang, Lei/? ?; 'linux-arm-kernel at lists.infradead.org'
> > Subject: Re: [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
> >
> > Hi Lei,
> >
> > On 01/06/18 13:44, Zhang, Lei wrote:
> > > Hi Marc
> > >
> > > I have reviewed your patch.
> > > I think the approach is same between your patch and mine.
> > > Your patch is simpler and more beautiful, and match our bus's
> > requirement.
> > >
> > > I have only one question.
> > > According your patch, if there are no enough lpis, amount of lpis
> > required
> > > will be divide by 2. it means someone want 16 lpis, maybe they can
> only
> > get 8?
> > > I don?t' understand why we need it.
> >
> > That's the way the MSI allocation works in the kernel.
> >
> > A driver asks a number of MSIs (let's imagine, for example, one MSI
> per
> > CPU in the system), but the underlying HW can only provide a smaller
> > number.
> >
> > Instead of failing and just returning an error, we reduce the allocation
> > in order to provide the driver with something. If that's not enough,
> > well, the driver itself will have the opportunity to give up.
> >
> > See pci_alloc_irq_vectors_affinity(), which takes a min and a max
> number
> > of vectors, for example.
> >
> > Thanks,
> >
> > M.
> > --
> > Jazz is not dead. It just smells funny...
> >
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Let the codec control MCLK pinctrl
From: Fabio Estevam @ 2018-06-05 0:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
sgtl5000 codec needs MCLK clock to be present so that it can
successfully read/write via I2C.
In the case of imx53-qsb, MCLK is provided via
MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK pad.
Move the MCLK pinctrl from hog group to the codec group, so that the
codec clock can be present prior to reading the codec ID.
This avoids the following sgtl5000 probe error:
sgtl5000 1-000a: Error reading chip id -6
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index ef7658a..7423d46 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -153,7 +153,6 @@
imx53-qsb {
pinctrl_hog: hoggrp {
fsl,pins = <
- MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x80000000
MX53_PAD_GPIO_8__GPIO1_8 0x80000000
MX53_PAD_PATA_DATA14__GPIO2_14 0x80000000
MX53_PAD_PATA_DATA15__GPIO2_15 0x80000000
@@ -180,6 +179,12 @@
>;
};
+ pinctrl_codec: codecgrp {
+ fsl,pins = <
+ MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x1c4
+ >;
+ };
+
pinctrl_esdhc1: esdhc1grp {
fsl,pins = <
MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
@@ -310,6 +315,8 @@
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_codec>;
#sound-dai-cells = <0>;
VDDA-supply = <®_3p2v>;
VDDIO-supply = <®_3p2v>;
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 1:13 UTC (permalink / raw)
To: linux-arm-kernel
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "solidrun,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..a6d6996e1378
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "solidrun,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ //vbus-regulator = <®_5p0v_usb>;
+ };
+
+ soc {
+ internal-regs {
+ i2c at 11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander at 20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp at 4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c at 11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ sata at e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ spi at 10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb at 58000 {
+ //vcc-supply = <®_5p0v_usb>;
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+
+ pinctrl at 18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/6] PCI: iproc: Update iProc PCI binding for INTx support
From: Ray Jui @ 2018-06-05 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+ac6dmHKS6m0h5N3bv=VseKVL8XLU5K7j1Rn=mgFNLsA@mail.gmail.com>
Hi Rob/Arnd,
On 6/4/2018 7:17 AM, Rob Herring wrote:
> +Arnd
>
> On Tue, May 29, 2018 at 4:58 PM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Update the iProc PCIe binding document for better modeling of the legacy
>> interrupt (INTx) support
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++++++++++++++-----
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> index b8e48b4..7ea24dc 100644
>> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> @@ -13,9 +13,6 @@ controller, used in Stingray
>> PAXB-based root complex is used for external endpoint devices. PAXC-based
>> root complex is connected to emulated endpoint devices internal to the ASIC
>> - reg: base address and length of the PCIe controller I/O register space
>> -- #interrupt-cells: set to <1>
>> -- interrupt-map-mask and interrupt-map, standard PCI properties to define the
>> - mapping of the PCIe interface to interrupt numbers
>> - linux,pci-domain: PCI domain ID. Should be unique for each host controller
>> - bus-range: PCI bus numbers covered
>> - #address-cells: set to <3>
>> @@ -41,6 +38,16 @@ Required:
>> - brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
>> address used by the iProc PCIe core (not the PCIe address)
>>
>> +Legacy interrupt (INTx) support (optional):
>> +
>> +Note INTx is for PAXB only.
>> +
>> +- interrupt-controller: claims itself as an interrupt controller for INTx
>> +- #interrupt-cells: set to <1>
>> +- interrupt-map-mask and interrupt-map, standard PCI properties to define
>> +the mapping of the PCIe interface to interrupt numbers
>> +- interrupts: interrupt line wired to the generic GIC for INTx support
>> +
>> MSI support (optional):
>>
>> For older platforms without MSI integrated in the GIC, iProc PCIe core provides
>> @@ -77,9 +84,14 @@ Example:
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18012000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie0 1>,
>
> Are you sure this works? The irq parsing code will ignore
> interrupt-map if interrupt-controller is found. In other words, you
> should have one or the other, but not both.
Yes, it does work. I tested this by using an Intel E1000E PCIe NIC card
installed in our system and have it fall back to INTx.
>
> Maybe it happens to work because "pcie0" is this node and your irq
> numbers are the same.
Perhaps it works because we are claiming "pcie0" as an interrupt
controller by itself and the INTx is modeled under that.
>
> Arnd, any thoughts on this?
>
Please let me know if the above model makes sense or not.
Thanks,
Ray
>> + <0 0 0 2 &pcie0 2>,
>> + <0 0 0 3 &pcie0 3>,
>> + <0 0 0 4 &pcie0 4>;
>> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
>>
>> linux,pci-domain = <0>;
>>
>> @@ -115,9 +127,14 @@ Example:
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18013000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie1 1>,
>> + <0 0 0 2 &pcie1 2>,
>> + <0 0 0 3 &pcie1 3>,
>> + <0 0 0 4 &pcie1 4>;
>> + interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
>>
>> linux,pci-domain = <1>;
>>
>> --
>> 2.1.4
>>
^ permalink raw reply
* [PATCH v5 4/4] ARM: dts: imx: add missing compatible and clock properties for EPIT
From: kbuild test robot @ 2018-06-05 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604100035.19558-5-peron.clem@gmail.com>
Hi Colin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17 next-20180601]
[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/Cl-ment-P-ron/Reintroduce-i-MX-EPIT-Timer/20180604-211036
base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
config: arm-at91_dt_defconfig (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/imx6qdl.dtsi:832.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: 23243 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/f204908e/attachment-0001.gz>
^ permalink raw reply
* [PATCH V4] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-05 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 4 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 ---
arch/x86/pci/early.c | 44 -------------------------
drivers/pci/pci.c | 5 +++
drivers/pci/pci.h | 1 +
drivers/pci/probe.c | 19 +++++++++++
8 files changed, 26 insertions(+), 58 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e490902..e64f1d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2995,7 +2995,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..94597a3 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -15,8 +15,4 @@ extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..f5fc953 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -57,47 +57,3 @@ int early_pci_allowed(void)
PCI_PROBE_CONF1;
}
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97acba7..04052dc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, the PCI config space of each device is printed during boot. */
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..c33265e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,6 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 56771f3..3678f0a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1545,6 +1545,23 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ if (!pci_early_dump)
+ return;
+
+ pci_info(pdev, "config space:\n");
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1594,6 +1611,8 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-helios4
From: Baruch Siach @ 2018-06-05 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605011343.14999-1-dennis@ausil.us>
Hi Dennis,
On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
> https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
> I added a SPDX license line to match the clearfog it says it was based
> on and a compatible line for "solidrun,helios4"
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
> 2 files changed, 316 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e2424957809..490bfd586198 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
> armada-388-clearfog-pro.dtb \
> armada-388-db.dtb \
> armada-388-gp.dtb \
> + armada-388-helios4.dtb \
> armada-388-rd.dtb
> dtb-$(CONFIG_MACH_ARMADA_39X) += \
> armada-398-db.dtb
> diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
> new file mode 100644
> index 000000000000..a6d6996e1378
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-388-helios4.dts
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Helios4
> + * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
> + *
> + * Copyright (C) 2017
> + *
> + */
> +
> +/dts-v1/;
> +#include "armada-388.dtsi"
> +#include "armada-38x-solidrun-microsom.dtsi"
> +
> +/ {
> + model = "Helios4";
> + compatible = "solidrun,helios4", "marvell,armada388",
SolidRun is not the producer of the Helios4 carrier board. So I think
"kobol,helios4" makes more sense. This is just like the "auvidea,h100"
compatible string for Auvidea H100 which is also using a SolidRun SOM.
baruch
> + "marvell,armada385", "marvell,armada380";
> +
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Y.b. Lu @ 2018-06-05 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604134920.ezhe6jz5ntpnqyzj@localhost>
Hi Richard,
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Monday, June 4, 2018 9:49 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev at vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
>
> On Mon, Jun 04, 2018 at 03:08:36PM +0800, Yangbo Lu wrote:
>
> > +if FSL_DPAA_ETH
> > +config FSL_DPAA_ETH_TS
> > + bool "DPAA hardware timestamping support"
> > + select PTP_1588_CLOCK_QORIQ
> > + default n
> > + help
> > + Enable DPAA hardware timestamping support.
> > + This option is useful for applications to get
> > + hardware time stamps on the Ethernet packets
> > + using the SO_TIMESTAMPING API.
> > +endif
>
> You should drop this #ifdef. In general, if a MAC supports time stamping and
> PHC, then the driver support should simply be compiled in.
>
> [ When time stamping incurs a large run time performance penalty to
> non-PTP users, then it might make sense to have a Kconfig option to
> disable it, but that doesn't appear to be the case here. ]
[Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
That's why we used ifdef for it.
>
> > @@ -1615,6 +1635,24 @@ static int dpaa_eth_refill_bpools(struct
> dpaa_priv *priv)
> > skbh = (struct sk_buff **)phys_to_virt(addr);
> > skb = *skbh;
> >
> > +#ifdef CONFIG_FSL_DPAA_ETH_TS
> > + if (priv->tx_tstamp &&
> > + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
>
> This condition fits on one line easily.
[Y.b. Lu] Right. I will use one line in next version.
>
> > + struct skb_shared_hwtstamps shhwtstamps;
> > + u64 ns;
>
> Local variables belong at the top of the function.
[Y.b. Lu] Ok, will move them to the top in next verison.
>
> > + memset(&shhwtstamps, 0, sizeof(shhwtstamps));
> > +
> > + if (!dpaa_get_tstamp_ns(priv->net_dev, &ns,
> > + priv->mac_dev->port[TX],
> > + (void *)skbh)) {
> > + shhwtstamps.hwtstamp = ns_to_ktime(ns);
> > + skb_tstamp_tx(skb, &shhwtstamps);
> > + } else {
> > + dev_warn(dev, "dpaa_get_tstamp_ns failed!\n");
> > + }
> > + }
> > +#endif
> > if (unlikely(qm_fd_get_format(fd) == qm_fd_sg)) {
> > nr_frags = skb_shinfo(skb)->nr_frags;
> > dma_unmap_single(dev, addr, qm_fd_get_offset(fd) + @@ -2086,6
> > +2124,14 @@ static int dpaa_start_xmit(struct sk_buff *skb, struct
> net_device *net_dev)
> > if (unlikely(err < 0))
> > goto skb_to_fd_failed;
> >
> > +#ifdef CONFIG_FSL_DPAA_ETH_TS
> > + if (priv->tx_tstamp &&
> > + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
>
> One line please.
[Y.b. Lu] No problem.
>
> > + fd.cmd |= FM_FD_CMD_UPD;
> > + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> > + }
> > +#endif
> > +
> > if (likely(dpaa_xmit(priv, percpu_stats, queue_mapping, &fd) == 0))
> > return NETDEV_TX_OK;
> >
>
> Thanks,
> Richard
^ permalink raw reply
* Common config for N900 and D4
From: Tony Lindgren @ 2018-06-05 4:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180603210115.GA7438@amd>
* Pavel Machek <pavel@ucw.cz> [180603 21:03]:
> Hi!
>
> > > Aaro, I know I have asked before, but if you have common config for
> > > N900 and Droid4, please send me a copy. Yes, it should be somewhere in
> > > my inbox already, but I can't find it and version for v4.17 would be
> > > more useful.
> > >
> > > While trying to came up with common config, I hit:
> > >
> > > [ 0.000000] L2C-310 erratum 727915 enabled
> > > [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
> > > [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
> >
> > I tried disabling outer cache to get rid of this. That got me further
> > in boot, but not to working system:
>
> I now have config that works.
>
> My kernels were probably grossly misconfigured (OMAP4 not enabled on
> droid4)... still I'd expect some kind of panic explaining board is not
> compatible with kernel, not a random oops...
Like "clk-provider not found" error? :) I agree it's not very
descriptive and I think we could easily print something from
after the SoC detection for missing pdata.
Eventually we should just get rid of all ARMv7 Kconfig variants
once most of the hwmod SoC pdata is gone.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-06-05 4:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602081418.jcl2vjc6saoj3z3d@localhost>
On 02-06-18, 01:14, Olof Johansson wrote:
> And what I am saying is that it sounds like a broken binding if you don't allow
> that, especially since it'll be a super common case that all CPUs will specify
> the same cooling-device specifier.
I am fine with allowing the #cooling-cells property in the cpus node if the DT
maintainers are fine with it.
@Rob: comments ?
@Olof: What about other properties which are still going to be duplicated for
the most common cases today, like: clocks, supply information, cache
information, cpu-idle-states and others. When we can duplicate these properties,
why not keep following the same for #cpu-cooling property ?
Note that the OPP table doesn't really need to get duplicated (for new
platforms) as the platforms use the v2 bindings now which just duplicates a
phandle assignment for all CPUs. Its a mess with older platforms which use the
earlier version of OPP table.
> > This property is required to declare a device as a cooling-device and
> > the device here is CPU. We use it as a cooling device by limiting its
> > higher range of frequencies, so that it doesn't generate too much
> > heat.
> >
> > It is already there for CPU0 and CPU4, but it should really be there
> > for all the CPUs, like we have clock, supply, caches, etc.
>
> You have #cooling-cells in the cpu node, but the actual data is in the
> thermal-zones nodes. Why isn't #cooling-cells under thermal-zones, next to
> cooling-maps?
Actually I thought about that when I worked on these patches initially and this
is why I felt convinced that the CPU nodes are the right place for this.
We add #interrupt-cells to an Interrupt controller's DT node, #gpio-cells to a
GPIO controller's DT node, #clock-cells to a clock controller's DT node and
that's exactly why we should (and we do) add #cooling-cells property to a
cooling device's DT node. This information is used in two ways, first it enables
the OS to know that the device is capable of being a cooling device and second
it tells us how many arguments will be required with a phandle of this device.
And so the cooling-maps always contain two arguments with the cooling device's
phandle (which is mostly a CPU or a gpio fan) as the #cooling-cells currently
is fixed to 2.
And so I am not really sure if thermal-zones is the right place to define this
thing. Is my understanding correct ?
--
viresh
^ permalink raw reply
* Regression in Linux next again
From: Tony Lindgren @ 2018-06-05 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-1-git-send-email-m.purski@samsung.com>
Hi,
* Maciej Purski <m.purski@samsung.com> [180604 14:02]:
> Tony, please apply this patchset and test it on your Beaglebone. It'd be
> great if you could try to find out, which patch causes failure. They should
> be appliable on the current next.
It seems beagle-x15 boots for me except with the last patch in the
series with compile issue fixed. With that applied after modules
get loaded it just hangs with:
[ 25.925607] regulator_resolve_supply: 1608
[ 25.930620] regulator_resolve_supply: 1608
[ 26.098449] lib80211: common routines for IEEE802.11 drivers
[ 26.446713] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 26.514834] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 26.525311] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 26.534250] cfg80211: failed to load regulatory.db
[ 26.998736] regulator_set_voltage: 3381
[ 27.007662] _regulator_do_set_voltage: 2913
[ 27.012593] regulator_set_voltage: 3381
[ 27.016969] _regulator_do_set_voltage: 2913
[ 27.022847] regulator_set_voltage: 3381
Not sure what module gets loaded at that point, I'll test again
with initcall_debug once you post a compiling version of your last
patch.
Regards,
Tony
^ permalink raw reply
* [PATCH V2 1/2] arm: dts: sun8i-h3: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-06-05 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601151701.sshwfdbflic6mybv@flea>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, clock-names) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2: Separated patch for h3.
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ 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