* [PATCH v2 0/2] ARM64: dts: meson-axg: enable wifi driver
From: Kevin Hilman @ 2018-05-09 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504094533.15588-1-yixun.lan@amlogic.com>
Hi Yixun,
Yixun Lan <yixun.lan@amlogic.com> writes:
> These patches try to enable the WIFI module AP6255 in Meson-AXG S400
> baord. First patch revert an error which was introduced in early commit.
>
> Hi Kevin
> Please squash patch 1 into the commit[1] of your v4.18/dt64 branch,
> which was the error introduced there.
Thanks for the explanation, I've squashed patch 1, and applied patch 2
to v4.18/dt64.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 2/2] pinctrl: nand: meson-gxl: fix missing data pins
From: Yixun Lan @ 2018-05-09 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509220827.22286-1-yixun.lan@amlogic.com>
The data pin 0-7 of the NAND controller are actually missing from
the nand pinctrl group, so we fix it here.
Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions")
Reported-by: Liang Yang <liang.yang@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
index b3786cde963d..7dae1d7bf6b0 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -617,8 +617,8 @@ static const char * const sdio_groups[] = {
};
static const char * const nand_groups[] = {
- "nand_ce0", "nand_ce1", "nand_rb0", "nand_ale", "nand_cle",
- "nand_wen_clk", "nand_ren_wr", "nand_dqs",
+ "emmc_nand_d07", "nand_ce0", "nand_ce1", "nand_rb0", "nand_ale",
+ "nand_cle", "nand_wen_clk", "nand_ren_wr", "nand_dqs",
};
static const char * const uart_a_groups[] = {
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] pinctrl: nand: meson-gxbb: fix missing data pins
From: Yixun Lan @ 2018-05-09 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509220827.22286-1-yixun.lan@amlogic.com>
The data pin 0-7 of the NAND controller are actually missing from
the nand pinctrl group, so we fix it here.
Fixes: cd1e3b01c7d3 ("pinctrl: amlogic: gxbb: add nand pins")
Reported-by: Liang Yang <liang.yang@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index 9079020259c5..2c97a2e07a5f 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -627,8 +627,8 @@ static const char * const sdio_groups[] = {
};
static const char * const nand_groups[] = {
- "nand_ce0", "nand_ce1", "nand_rb0", "nand_ale", "nand_cle",
- "nand_wen_clk", "nand_ren_wr", "nand_dqs",
+ "emmc_nand_d07", "nand_ce0", "nand_ce1", "nand_rb0", "nand_ale",
+ "nand_cle", "nand_wen_clk", "nand_ren_wr", "nand_dqs",
};
static const char * const uart_a_groups[] = {
--
2.17.0
^ permalink raw reply related
* [PATCH 0/2] pinctrl: nand: meson: fix missing data pins
From: Yixun Lan @ 2018-05-09 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus
We found the data pins of NAND controller are actually mising from
the nand pinctrl group in the GXBB, GXL SoC driver, these two patches
will fix these issue.
I have prepared the two patches separated with different Fix tag,
but I can squash them into one patch if you prefer, since the meson nand
driver has never been pushed into mainline (so probably the Fix tag is
useless).
Btw, the patches are formated on top your 'for-next' branch,
and I'm fine with this merged as for-next.
Thanks
Yixun Lan (2):
pinctrl: nand: meson-gxbb: fix missing data pins
pinctrl: nand: meson-gxl: fix missing data pins
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 4 ++--
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process
From: Suzuki K Poulose @ 2018-05-09 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c935a9e6-94a0-03cb-eb64-7e2eef8f8d86@arm.com>
On 05/04/2018 11:06 AM, Julien Thierry wrote:
> Hi,
>
> In order to prepare the v3 of this patchset, I'd like people's opinion
> on what this patch does. More below.
>
> On 17/01/18 11:54, Julien Thierry wrote:
>> From: Daniel Thompson <daniel.thompson@linaro.org>
>>
>> Currently alternatives are applied very late in the boot process (and
>> a long time after we enable scheduling). Some alternative sequences,
>> such as those that alter the way CPU context is stored, must be applied
>> much earlier in the boot sequence.
>> +/*
>> + * early-apply features are detected using only the boot CPU and
>> checked on
>> + * secondary CPUs startup, even then,
>> + * These early-apply features should only include features where we must
>> + * patch the kernel very early in the boot process.
>> + *
>> + * Note that the cpufeature logic *must* be made aware of early-apply
>> + * features to ensure they are reported as enabled without waiting
>> + * for other CPUs to boot.
>> + */
>> +#define EARLY_APPLY_FEATURE_MASK BIT(ARM64_HAS_SYSREG_GIC_CPUIF)
>> +
>
> Following the change in the cpufeature infrastructure,
> ARM64_HAS_SYSREG_GIC_CPUIF will have the scope
> ARM64_CPUCAP_SCOPE_BOOT_CPU in order to be checked early in the boot
> process.
Thats correct.
>
> Now, regarding the early application of alternative, I am wondering
> whether we can apply all the alternatives associated with SCOPE_BOOT
> features that *do not* have a cpu_enable callback.
>
I don't understand why would you skip the ones that have a "cpu_enable"
callback. Could you explain this a bit ? Ideally you should be able to
apply the alternatives for features with the SCOPE_BOOT, provided the
cpu_enable() callback is written properly.
> Otherwise we can keep the macro to list individually each feature that
> is patchable at boot time as the current patch does (or put this info in
> a flag within the arm64_cpu_capabilities structure)
You may be able to build up the mask of *available* capabilities with
SCOPE_BOOT at boot time by playing some trick in the
setup_boot_cpu_capabilities(), rather than embedding it in the
capabilities (and then parsing the entire table(s)) or manually keeping
track of the capabilities by having a separate mask.
Suzuki
>
> Any thoughts or preferences on this?
>
> Thanks,
>
>> ? #define __ALT_PTR(a,f)??????? ((void *)&(a)->f + (a)->f)
>> ? #define ALT_ORIG_PTR(a)??????? __ALT_PTR(a, orig_offset)
>> ? #define ALT_REPL_PTR(a)??????? __ALT_PTR(a, alt_offset)
>> @@ -105,7 +117,8 @@ static u32 get_alt_insn(struct alt_instr *alt,
>> __le32 *insnptr, __le32 *altinsnp
>> ????? return insn;
>> ? }
>>
>> -static void __apply_alternatives(void *alt_region, bool
>> use_linear_alias)
>> +static void __apply_alternatives(void *alt_region,? bool
>> use_linear_alias,
>> +???????????????? unsigned long feature_mask)
>> ? {
>> ????? struct alt_instr *alt;
>> ????? struct alt_region *region = alt_region;
>> @@ -115,6 +128,9 @@ static void __apply_alternatives(void *alt_region,
>> bool use_linear_alias)
>> ????????? u32 insn;
>> ????????? int i, nr_inst;
>>
>> +??????? if ((BIT(alt->cpufeature) & feature_mask) == 0)
>> +??????????? continue;
>> +
>> ????????? if (!cpus_have_cap(alt->cpufeature))
>> ????????????? continue;
>>
>> @@ -138,6 +154,21 @@ static void __apply_alternatives(void
>> *alt_region, bool use_linear_alias)
>> ? }
>>
>> ? /*
>> + * This is called very early in the boot process (directly after we run
>> + * a feature detect on the boot CPU). No need to worry about other CPUs
>> + * here.
>> + */
>> +void apply_alternatives_early(void)
>> +{
>> +??? struct alt_region region = {
>> +??????? .begin??? = (struct alt_instr *)__alt_instructions,
>> +??????? .end??? = (struct alt_instr *)__alt_instructions_end,
>> +??? };
>> +
>> +??? __apply_alternatives(®ion, true, EARLY_APPLY_FEATURE_MASK);
>> +}
>> +
>> +/*
>> ?? * We might be patching the stop_machine state machine, so implement a
>> ?? * really simple polling protocol here.
>> ?? */
>> @@ -156,7 +187,9 @@ static int __apply_alternatives_multi_stop(void
>> *unused)
>> ????????? isb();
>> ????? } else {
>> ????????? BUG_ON(patched);
>> -??????? __apply_alternatives(®ion, true);
>> +
>> +??????? __apply_alternatives(®ion, true, ~EARLY_APPLY_FEATURE_MASK);
>> +
>> ????????? /* Barriers provided by the cache flushing */
>> ????????? WRITE_ONCE(patched, 1);
>> ????? }
>> @@ -177,5 +210,5 @@ void apply_alternatives(void *start, size_t length)
>> ????????? .end??? = start + length,
>> ????? };
>>
>> -??? __apply_alternatives(®ion, false);
>> +??? __apply_alternatives(®ion, false, -1);
>> ? }
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 551eb07..37361b5 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -453,6 +453,12 @@ void __init smp_prepare_boot_cpu(void)
>> ?????? * cpuinfo_store_boot_cpu() above.
>> ?????? */
>> ????? update_cpu_errata_workarounds();
>> +??? /*
>> +???? * We now know enough about the boot CPU to apply the
>> +???? * alternatives that cannot wait until interrupt handling
>> +???? * and/or scheduling is enabled.
>> +???? */
>> +??? apply_alternatives_early();
>> ? }
>>
>> ? static u64 __init of_get_cpu_mpidr(struct device_node *dn)
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* [PATCH] arm64: dts: sdm845: Add command DB node
From: Bjorn Andersson @ 2018-05-09 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509213439.165623-1-dianders@chromium.org>
On Wed 09 May 14:34 PDT 2018, Douglas Anderson wrote:
> Add command DB node based on the bindings example.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 486ace9a9e8b..7b5f2b3982a3 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -21,6 +21,18 @@
> reg = <0 0x80000000 0 0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + reserved-memory at 85fe0000 {
> + compatible = "qcom,cmd-db";
> + reg = <0x0 0x85fe0000 0x0 0x20000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <2>;
> #size-cells = <0>;
> --
> 2.17.0.441.gb46fe60e1d-goog
>
^ permalink raw reply
* [PATCH] arm64: dts: sdm845: Add command DB node
From: Douglas Anderson @ 2018-05-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Add command DB node based on the bindings example.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 486ace9a9e8b..7b5f2b3982a3 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -21,6 +21,18 @@
reg = <0 0x80000000 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ reserved-memory at 85fe0000 {
+ compatible = "qcom,cmd-db";
+ reg = <0x0 0x85fe0000 0x0 0x20000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: juno: replace '_' with '-' in node names
From: Rob Herring @ 2018-05-09 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-2-git-send-email-sudeep.holla@arm.com>
On Wed, May 9, 2018 at 11:44 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> The latest DTC throws warnings for character '_' in the node names.
>
> Warning (node_name_chars_strict): /thermal-zones/big_cluster: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /thermal-zones/little_cluster: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /smb at 8000000/motherboard/gpio_keys: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /pmu_a57: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /pmu_a53: Character '_' not recommended in node name
>
> The general recommendation is to use character '-' for all the node names.
> This patch fixes the warnings following the recommendation.
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ++--
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 2 +-
> arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++--
> arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++--
> arch/arm64/boot/dts/arm/juno.dts | 4 ++--
> 5 files changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Replace '_' with '-' in node names
From: Rob Herring @ 2018-05-09 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884482-19855-1-git-send-email-sudeep.holla@arm.com>
On Wed, May 9, 2018 at 11:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> The latest DTC throws warnings for character '_' in the node names.
>
> Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
>
> The general recommendation is to use character '-' for all the node names.
> This patch fixes the warnings following the recommendation.
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 7b8ff5b3b912..58e73131ecef 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -77,19 +77,19 @@
> compatible = "arm,vexpress-sysreg";
> reg = <0x010000 0x1000>;
>
> - v2m_led_gpios: sys_led {
> + v2m_led_gpios: sys-led {
Except this is a gpio-controller so it should have 'gpio' for its node
name. (I have a dtc check written for that, but there are too many
false positives.)
But then you have 3 of them and no addressing, so you need to add reg
property (with the register's offset and size) and unit-address.
I'm surprised Linus W accepted these a GPIO when they are not really
general purpose, but then lots of things slip in.
Rob
^ permalink raw reply
* [PATCH] arm64: dts: sdm845: Fix xo_board clock name and speed
From: Douglas Anderson @ 2018-05-09 20:05 UTC (permalink / raw)
To: linux-arm-kernel
The RPMh clock driver assumes that the xo_board clock is named
"xo_board", not "xo-board". Add a "clock-output-names" property to
the device tree to get the right name.
Also add the proper speed for the xo-clock as 38400000. This is
internally divided in RPMh clock driver to get "bi_tcxo" at 19200000.
After this change the clock tree in /sys/kernel/debug/clk/clk_summary
looks much better.
NOTES:
- Technically you could argue that this clock could belong in board
.dts files, not in the SoC one. However at the moment it's believed
that 100% of sdm845 boards will have an external clock at 38.4. It
can always be moved later if necessary.
- We could rename the "xo-board" device tree node to "xo_board" to
achieve the same effect as this patch. Presumably device-tree folks
would rather keep node names using dashes though.
- We could change the RPMh clock driver to use a dash to achieve the
same effect as this patch, but all other clocks in the clock tree
use underscores. It seems silly to change just this one.
Fixes: 7bafa643647f ("arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 486ace9a9e8b..4945f8cccd6c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -137,7 +137,8 @@
xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <19200000>;
+ clock-frequency = <38400000>;
+ clock-output-names = "xo_board";
};
sleep_clk: sleep-clk {
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()
From: Jacek Anaszewski @ 2018-05-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508201725.3alpkcpaxebupzqv@pengutronix.de>
Hi Uwe,
On 05/08/2018 10:17 PM, Uwe Kleine-K?nig wrote:
> Hello Jacek,
>
> On Tue, May 08, 2018 at 09:33:14PM +0200, Jacek Anaszewski wrote:
>> Thank you for the patch. It looks fine, but please split
>> the drivers/net/can/led.c related changes into a separate one.
>
> I renamed led_trigger_rename_static() to led_trigger_rename() (and
> changed the parameters). The can change just adapts the only user of
> led_trigger_rename_static() to use the new one.
>
> It's not impossible to separate this patches, but I wonder if it's worth
> the effort.
>
> The first patch would be like the patch under discussion, just without
> the can bits and introducing something like:
>
> /*
> * compat stuff to be removed once the only caller is converted
> */
> static inline led_trigger_rename_static(const char *name, struct led_trigger *trig)
> {
> (void)led_trigger_rename(trig, "%s", name);
> }
>
> Then the second patch would just be the 6-line can hunk. And a third
> patch would remove the compat function. (Maybe I'd choose to squash the
> two can patches together then, but this doesn't reduce the overhead
> considerably.) The only upside I can see here is that it increases my
> patch count, but it's otherwise not worth the effort for such an easy
> change. Further more as there is a strict dependency on these three
> patches this either delays the cleanup or (IMHO more likely) the can
> change would go in via the led tree anyhow. (Mark already acked patch 2
> of this series and in private confirmed that the agrees to let this
> change go in via the led tree, too.)
OK, makes sense. I'll wait also for ack on 3/3 since it should
go through the LED tree as well - uses a new led_trigger_register_format().
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH 2/2] i2c: exynos5: remove pointless initializers
From: Peter Rosin @ 2018-05-09 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509194532.28929-1-peda@axentia.se>
The variables are always assigned before use anyway.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/busses/i2c-exynos5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index a2cbc779c33a..185fba37e830 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -707,7 +707,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
{
struct exynos5_i2c *i2c = adap->algo_data;
- int i = 0, ret = 0, stop = 0;
+ int i, ret, stop;
if (i2c->suspended) {
dev_err(i2c->dev, "HS-I2C is not initialized.\n");
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] i2c: exynos5: remove some dead code
From: Peter Rosin @ 2018-05-09 19:45 UTC (permalink / raw)
To: linux-arm-kernel
The else branch cannot be taken as i will always equal num.
Get rid of the whole construct.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/busses/i2c-exynos5.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 12ec8484e653..a2cbc779c33a 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -727,17 +727,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
goto out;
}
- if (i == num) {
- ret = num;
- } else {
- /* Only one message, cannot access the device */
- if (i == 1)
- ret = -EREMOTEIO;
- else
- ret = i;
-
- dev_warn(i2c->dev, "xfer message failed\n");
- }
+ ret = num;
out:
clk_disable(i2c->clk);
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: BCM5301X: Relicense Asus RT-AC87U file to the GPL 2.0+ / MIT
From: Florian Fainelli @ 2018-05-09 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504100324.31847-1-zajec5@gmail.com>
On Fri, 4 May 2018 12:03:24 +0200, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> This matches licensing used by other BCM5301X files and is preferred as:
> 1) GPL 2.0+ makes is clearly compatible with Linux kernel
> 2) MIT is also permissive but preferred over ISC
>
> This file were created and ever touched by a group of three people only:
> ?lvaro, Hauke and me.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node
From: Simon Horman @ 2018-05-09 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2889c7ff-1748-e435-c03c-cb36cf930b1d@cogentembedded.com>
On Wed, May 09, 2018 at 10:18:47PM +0300, Sergei Shtylyov wrote:
> On 5/9/2018 10:14 PM, Simon Horman wrote:
>
> > > > Add resets property to CAN-FD node to describe it in the reset topology of
> > > > on-SoC devices. This allows to reset the CAN-FD device using the Reset
> > > > Controller API.
> > > >
> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > >
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks, applied.
>
> You're too quick (and I'm on holiday today). Need "to| before "CAN-FD" in
> the subject. ;-)
Thanks, fixed.
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Relicense Asus RT-AC87U file to the GPL 2.0+ / MIT
From: Álvaro Fernández Rojas @ 2018-05-09 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f80f8566-aada-65ae-9952-83780f041eb7@gmail.com>
Sorry for the delay.
Acked-by: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
El 09/05/2018 a las 21:19, Florian Fainelli escribi?:
> On 05/04/2018 03:03 AM, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> This matches licensing used by other BCM5301X files and is preferred as:
>> 1) GPL 2.0+ makes is clearly compatible with Linux kernel
>> 2) MIT is also permissive but preferred over ISC
>>
>> This file were created and ever touched by a group of three people only:
>> ?lvaro, Hauke and me.
> Alvaro, please Ack/Nack the license change. Thank you
>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>> ?lvaro, Hauke: I need approve for this change from each of you. If you
>> are OK with it, can you reply with an Acked-by, please?
>> ---
>> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 13 +------------
>> 1 file changed, 1 insertion(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
>> index df473cc41572..22271818f901 100644
>> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
>> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
>> @@ -1,20 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> /*
>> * Broadcom BCM470X / BCM5301X ARM platform code.
>> * DTS for Asus RT-AC87U
>> *
>> * Copyright (C) 2015 Rafa? Mi?ecki <zajec5@gmail.com>
>> - *
>> - * Permission to use, copy, modify, and/or distribute this software for any
>> - * purpose with or without fee is hereby granted, provided that the above
>> - * copyright notice and this permission notice appear in all copies.
>> - *
>> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH
>> - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
>> - * AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
>> - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
>> - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
>> - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
>> - * PERFORMANCE OF THIS SOFTWARE.
>> */
>>
>> /dts-v1/;
>>
>
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Relicense Asus RT-AC87U file to the GPL 2.0+ / MIT
From: Florian Fainelli @ 2018-05-09 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504100324.31847-1-zajec5@gmail.com>
On 05/04/2018 03:03 AM, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> This matches licensing used by other BCM5301X files and is preferred as:
> 1) GPL 2.0+ makes is clearly compatible with Linux kernel
> 2) MIT is also permissive but preferred over ISC
>
> This file were created and ever touched by a group of three people only:
> ?lvaro, Hauke and me.
Alvaro, please Ack/Nack the license change. Thank you
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
> ?lvaro, Hauke: I need approve for this change from each of you. If you
> are OK with it, can you reply with an Acked-by, please?
> ---
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index df473cc41572..22271818f901 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -1,20 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> /*
> * Broadcom BCM470X / BCM5301X ARM platform code.
> * DTS for Asus RT-AC87U
> *
> * Copyright (C) 2015 Rafa? Mi?ecki <zajec5@gmail.com>
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH
> - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
> - * AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
> - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
> - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
> - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> - * PERFORMANCE OF THIS SOFTWARE.
> */
>
> /dts-v1/;
>
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node
From: Sergei Shtylyov @ 2018-05-09 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509191435.vm2zfuuixbyd3drm@verge.net.au>
On 5/9/2018 10:14 PM, Simon Horman wrote:
>>> Add resets property to CAN-FD node to describe it in the reset topology of
>>> on-SoC devices. This allows to reset the CAN-FD device using the Reset
>>> Controller API.
>>>
>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks, applied.
You're too quick (and I'm on holiday today). Need "to| before "CAN-FD" in
the subject. ;-)
MBR, Sergei
^ permalink raw reply
* [PATCH 2/2] ARM: dts: BCM5301X: Add DT for Luxul XAP-1610
From: Florian Fainelli @ 2018-05-09 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525450124-21665-2-git-send-email-dan.haab@luxul.com>
On Fri, 4 May 2018 10:08:44 -0600, Dan Haab <riproute@gmail.com> wrote:
> It's an access point based on BCM47094 SoC with two BCM4366E wireless
> chipsets.
>
> Signed-off-by: Dan Haab <dan.haab@luxul.com>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH 1/2] ARM: dts: BCM5301X: Add DT for Luxul XWR-3150 V1
From: Florian Fainelli @ 2018-05-09 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525450124-21665-1-git-send-email-dan.haab@luxul.com>
On Fri, 4 May 2018 10:08:43 -0600, Dan Haab <riproute@gmail.com> wrote:
> Luxul XWR-3150 is a wireless router similar to the XWR-3100 except:
> 1) It has more RAM
> 2) Its NAND controller in running in BCH8 mode
> 3) LAN ports LEDs are hardware controlled
>
> Signed-off-by: Dan Haab <dan.haab@luxul.com>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add resets property CAN-FD node
From: Simon Horman @ 2018-05-09 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXWHXtO1-0FucCsPTE22U_k+vdqCrDHgBFrM4+yEgXYcQ@mail.gmail.com>
On Wed, May 09, 2018 at 08:29:19PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 9, 2018 at 7:54 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> > Add resets property to CAN-FD node to describe it in the reset topology of
> > on-SoC devices. This allows to reset the CAN-FD device using the Reset
> > Controller API.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes
From: Simon Horman @ 2018-05-09 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
On Mon, May 07, 2018 at 03:56:59PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series enables support for the ARM Performance Monitor Units
> in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
> R-Car Gen2, and RZ/G1 SoCs. This allows for better performance analysis
> using the "perf" tool.
>
> Sample output of "perf stat echo" on r8a7791/koelsch:
>
> - Before:
>
> Performance counter stats for 'echo':
>
> 2,636300 task-clock (msec) # 0,265 CPUs utilized
> 8 context-switches # 0,003 M/sec
> 0 cpu-migrations # 0,000 K/sec
> 43 page-faults # 0,016 M/sec
> <not supported> cycles
> <not supported> stalled-cycles-frontend
> <not supported> stalled-cycles-backend
> <not supported> instructions
> <not supported> branches
> <not supported> branch-misses
>
> 0,009960300 seconds time elapsed
>
> - After:
>
> Performance counter stats for 'echo':
>
> 2,455400 task-clock (msec) # 0,273 CPUs utilized
> 3 context-switches # 0,001 M/sec
> 0 cpu-migrations # 0,000 K/sec
> 45 page-faults # 0,018 M/sec
> 3.556.784 cycles # 1,449 GHz
> <not supported> stalled-cycles-frontend
> <not supported> stalled-cycles-backend
> 1.350.480 instructions # 0,38 insns per cycle
> 335.542 branches # 136,655 M/sec
> 18.075 branch-misses # 5,39% of all branches
>
> 0,008987900 seconds time elapsed
>
> Still missing:
> - R-Mobile APE6 (no PMU interrupt documented),
> - R-Car M1A and H1 (the PMU interrupt seems to be routed to the legacy
> SH INTC only?),
> - RZ/G1C (SMP support not yet upstream).
>
> This has been tested on r8a7791/koelsch, and boot-tested on
> r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.
Thanks, applied.
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: renesas: r8a77970: Add SMP Support
From: Simon Horman @ 2018-05-09 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525879403-12207-1-git-send-email-geert+renesas@glider.be>
On Wed, May 09, 2018 at 05:23:21PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series enables SMP support on the R-Car V3M SoC, by adding
> the second Cortex-A53 CPU core. It also adds the performance monitor
> unit, and links it to both CPU cores.
>
> Changes compared to v1:
> - Adjust GIC_CPU_MASK_SIMPLE(),
> - Use symbolic core clock and power domain indices,
> - Move the pmu node from the soc subnode to the root node, as it
> doesn't have registers.
>
> Note that the PSCI implementation on Eagle may be a preliminary version
> with some familiar quirks:
> - SMP bringup works, and both CPUs can be used,
> - Offlining CPU0 crashes the system,
> - CPU1 can be offlined, but trying to bring it online again crashes
> the system, too.
>
> I'm confident these will be fixed in future firmware versions, just like
> on H3/Salvator-X. Note that
> git at github.com:renesas-rcar/arm-trusted-firmware.git does not have
> support for R-Car V3M, V3H, and D3.
>
> Thanks!
>
> Geert Uytterhoeven (2):
> arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
> arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
Thanks, applied.
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: add SMP support
From: Simon Horman @ 2018-05-09 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db136ee6-4ce6-756e-743d-3342b2e65f2b@cogentembedded.com>
On Tue, May 08, 2018 at 09:47:10PM +0300, Sergei Shtylyov wrote:
> On 05/08/2018 09:40 PM, Geert Uytterhoeven wrote:
>
> >> Add the device node for the second Cortex-A53 CPU core.
> >>
> >> Based on the original (and large) patch by Daisuke Matsushita
> >> <daisuke.matsushita.ns@hitachi.com>.
> >>
> >> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > Dupe of https://patchwork.kernel.org/patch/10032875/
>
> Sorry!
> Not an exact dupe, though -- mine has clock/power #define's used,
> yours -- only bare #s. :-)
>
> > From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
> > (https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)
>
> Hmm... what's the fate of this series?
There is now a v2 of Geert's series which incorporates your enhancements.
I will apply that.
^ permalink raw reply
* [PATCH v3 08/10] PCI: Remove of_pci_get_host_bridge_resources()
From: Jan Kiszka @ 2018-05-09 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508132930.GL161390@bhelgaas-glaptop.roam.corp.google.com>
There are no in-tree users remaining, all are converted to the managed
variant. And it is unlikely that any out-of-tree user got the resource
management right as well. So remove the interface.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
This replaces "PCI: Deprecate of_pci_get_host_bridge_resources()" from
the round v2.
drivers/pci/of.c | 88 +++++++++++++-------------------------------------
include/linux/of_pci.h | 10 ------
2 files changed, 22 insertions(+), 76 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 5a88d46a41b7..38469ffd1d7e 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,11 +243,29 @@ void of_pci_check_probe_only(void)
EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
-static int __of_pci_get_host_bridge_resources(struct device *dev,
- struct device_node *dev_node,
+/**
+ * devm_of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI
+ * host bridge resources from DT
+ * @dev: host bridge device
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
+ struct device_node *dev_node = dev->of_node;
struct resource_entry *window;
struct resource *res;
struct resource *bus_range;
@@ -259,10 +277,7 @@ static int __of_pci_get_host_bridge_resources(struct device *dev,
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
- if (dev)
- bus_range = devm_kzalloc(dev,sizeof(*bus_range), GFP_KERNEL);
- else
- bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+ bus_range = devm_kzalloc(dev,sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
@@ -306,11 +321,7 @@ static int __of_pci_get_host_bridge_resources(struct device *dev,
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
- if (dev)
- res = devm_kzalloc(dev, sizeof(struct resource),
- GFP_KERNEL);
- else
- res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto parse_failed;
@@ -350,62 +361,7 @@ static int __of_pci_get_host_bridge_resources(struct device *dev,
pci_free_resource_list(resources);
return err;
}
-
-/**
- * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
- * @dev_node: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
- unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base)
-{
- return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
- bus_max, resources, io_base);
-}
-EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
-
-/**
- * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
- * bridge resources from DT
- * @dev: host bridge device
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int devm_of_pci_get_host_bridge_resources(struct device *dev,
- unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base)
-{
- return __of_pci_get_host_bridge_resources(dev, dev->of_node, busno,
- bus_max, resources, io_base);
-}
EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
-
#endif /* CONFIG_OF_ADDRESS */
/**
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 08b8f02426a5..fa4463a52900 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,20 +71,10 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
- unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base);
int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
#else
-static inline int of_pci_get_host_bridge_resources(struct device_node *dev_node,
- unsigned char busno, unsigned char bus_max,
- struct list_head *resources, resource_size_t *io_base)
-{
- return -EINVAL;
-}
-
static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
--
2.13.6
^ 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