* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Kim Phillips @ 2018-05-10 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509161120.ilnukvismwfb452g@lakrids.cambridge.arm.com>
On Wed, 9 May 2018 17:12:42 +0100
Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, May 09, 2018 at 05:06:43PM +0100, Pawel Moll wrote:
> > On Wed, 2018-05-09 at 00:40 +0100, Kim Phillips wrote:
> > > On Fri, 4 May 2018 11:41:17 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > [adding Pawel, arm-ccn driver author]
> >
> > We had this discussion way too many times for my liking. As I said
> > before - *I* will be fine with the debug messages in the CCN driver.
>
> > > > The ARM CCN PMU driver uses dev_warn() to complain about parameters
> > > in
> > > > the user-provided perf_event_attr. This means that under normal
> > > > operation (e.g. a single invocation of the perf tool), dmesg may be
> > > > spammed with multiple messages.
> >
> > Surely Mark, in his role as maintainer of drivers/perf/ (and a few
> > other locations), meant to use much more technical and emotion-free
> > subject, along the lines of "reduce a number of dmesg warnings at event
> > init".
>
> True. I'll reword the above to:
>
> The ARM CCN PMU driver uses dev_warn() to complain about parameters in
> the user-provided perf_event_attr. This means that under normal
> operation (e.g. a single invocation of the perf tool), a number of
> messages warnings may be logged to dmesg.
So from:
"...dmesg may be spammed with multiple messages."
to:
"...a number of messages warnings may be logged to dmesg."
Not sure what's *that* different between the two, but is the assumption
that "normal operation" - i.e., a single *valid* perf invocation -
still emits messages? In which case, could the misunderstanding here
possibly be the following?:
Assuming I know what node is valid, I can still get messages:
$ dmesg -w &
$ sudo ./perf stat -e ccn/hnf_cache_miss,node=8/ find /usr > /dev/null
[626610.173759] arm-ccn e8000000.ccn: Can't exclude execution levels!
[626610.173790] arm-ccn e8000000.ccn: Can't exclude execution levels!
Performance counter stats for 'system wide':
1,096,602 ccn/hnf_cache_miss,node=8/
3.708314082 seconds time elapsed
But the driver is still technically correct in that it WARNs (not
invisibly DEBUGs) it's users about the EL problem. In order to not
exclude the default execution levels, we postpend 'hku' to the event,
so now the EL messages are gone:
$ sudo ./perf stat -e ccn/hnf_cache_miss,node=8/hku find /usr > /dev/null
Performance counter stats for 'system wide':
1,086,521 ccn/hnf_cache_miss,node=8/hku
3.699726648 seconds time elapsed
What's important to keep the user warned about with arm-ccn is these
types of messages:
$ sudo ./perf stat -e ccn/hnf_cache_miss,node=1/hku find /usr > /dev/null
[626675.574828] arm-ccn e8000000.ccn: Invalid type 0x4 for node 1!
[626675.574841] arm-ccn e8000000.ccn: Invalid type 0x4 for node 1!
Performance counter stats for 'system wide':
<not supported> ccn/hnf_cache_miss,node=1/
3.686169559 seconds time elapsed
See? Now the user is pointed directly at the problem.
I've even enhanced the tool to help identify to the user the event with
an unsupported sampling error (commit 114bc191c370 "perf evsel: Say
which PMU Hardware event doesn't support sampling/overflow-interrupts").
BTW, the dmesg output above was only two lines per effective message:
That should be totally acceptable - it's only one line more than one
line per message. Are you seeing much more than that? If so, can we
see an example of an invocation that's completely unacceptable,
dmesg-volume-wise?
Thanks,
Kim
^ permalink raw reply
* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Kim Phillips @ 2018-05-09 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882003.4199.55.camel@arm.com>
On Wed, 9 May 2018 17:06:43 +0100
Pawel Moll <pawel.moll@arm.com> wrote:
> On Wed, 2018-05-09 at 00:40 +0100, Kim Phillips wrote:
> > On Fri, 4 May 2018 11:41:17 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > [adding Pawel, arm-ccn driver author]
>
> We had this discussion way too many times for my liking. As I said
> before - *I* will be fine with the debug messages in the CCN driver.
> Now, if there ever turns out to be other user of this thing and gets
Sure, this isn't just about Pawel using the driver he wrote - we know
you know how to use it because you wrote it. No, it's about all the
other potential users out there, esp. first time users, as I once was.
> into problems with event configuration, I'd hope that he/she can count
> on support from the knowledgable people here... (just checked and both
I abhor having to suggest our users email this list in order to find out
how to use the PMU drivers. First time users are going to tend to
steer completely away if they don't have the patience to debug a silent
PMU, rather than email this mailing list - sorry, but that's just
adding a huge usage barrier - for what - fuzzer runner's convenience?
> RHEL 7.5 and Ubuntu 16.04.3 kernels on AArch64 come with
> CONFIG_DYNAMIC_DEBUG=y, so it's a matter of explaining what has to be
> enabled where; sadly this information did not find its way into the
> commit description)
I can't think of a more difficult to find, more far-away, alien
place for end users to find help with perf, sorry.
> > > The ARM CCN PMU driver uses dev_warn() to complain about parameters
> > in
> > > the user-provided perf_event_attr. This means that under normal
> > > operation (e.g. a single invocation of the perf tool), dmesg may be
> > > spammed with multiple messages.
>
> Surely Mark, in his role as maintainer of drivers/perf/ (and a few
> other locations), meant to use much more technical and emotion-free
> subject, along the lines of "reduce a number of dmesg warnings at event
> init".
'reduce a number' is the wrong word: warnings are completely
eliminated. Debug-level messages occur at exactly the same
frequency/amount.
But I still object to the rationale overall - it seems this is about
running fuzzers? I even offered an alternative for fuzzer runners: is
modifying the loglevel prior to fuzzing somehow unacceptable?
Kim
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Stanimir Varbanov @ 2018-05-09 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509045151.GA24899@dragon>
Hi,
On 9.05.2018 07:51, Shawn Guo wrote:
> Hi Bjorn,
>
> On Tue, May 08, 2018 at 07:56:58AM -0500, Bjorn Helgaas wrote:
> ...
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + pci->pp.root_bus_nr = -1;
>>
>> Setting root_bus_nr looks like an unrelated change that should be in a
>> separate patch.
>>
>> But I'm not sure why you need to set root_bus_nr at all, since
>> dw_pcie_host_init() always sets it.
>>
>> Some other callers of dw_pcie_host_init() do set it:
>>
>> exynos_add_pcie_port()
>> imx6_add_pcie_port()
>> armada8k_add_pcie_port()
>> artpec6_add_pcie_port()
>> dw_plat_add_pcie_port()
>> histb_pcie_probe()
>> qcom_pcie_probe()
>> spear13xx_add_pcie_port()
>>
>> But I don't see *why* any of these need to set it. If they don't need to
>> set it, they shouldn't.
>
> Mostly it's a blind copy of unnecessary code. I tested histb driver
> by dropping the line, and did not see anything broken. I will cook up
> a series to remove the code from all above drivers, and copy
> corresponding driver owner to comment.
>
>> And it would be nice if histb and qcom followed the structure and naming
>> conventions of the other drivers, i.e., they should have
>> histb_add_pcie_port() and qcom_add_pcie_port().
>
> I can create a patch for histb driver, but will leave qcom one to
> Stanimir to decide.
Thanks, will see what can be done.
regards,
Stan
^ permalink raw reply
* [RFC][PATCH] arm64: update iomem_resource.end
From: Nicolin Chen @ 2018-05-09 22:58 UTC (permalink / raw)
To: linux-arm-kernel
The iomem_resource.end is -1 by default and should be updated in
arch-level code.
ARM64 so far hasn't updated it while core kernel code (mm/hmm.c)
started to use iomem_resource.end for boundary check. So it'd be
better to assign iomem_resource.end using a valid value, the end
of physical address space for example because iomem_resource.end
in theory should reflect that.
However, VA_BITS might be smaller than PA_BITS in ARM64. So using
the end of physical address space doesn't make a lot of sense in
this case, or could be even harmful since virtual address cannot
reach that memory region. Furthermore, the linear region size of
ARM64 only has the half of Virtual Memory size -- "VA_BITS - 1".
So this patch updates the iomem_resource.end by using the end of
physical address space or the end of linear mapping region when
(VA_BITS - 1) is smaller than PA_BITS.
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
arch/arm64/mm/init.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f48b194..22015af 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -377,6 +377,12 @@ void __init arm64_memblock_init(void)
BUILD_BUG_ON(linear_region_size != BIT(VA_BITS - 1));
/*
+ * Update iomem_resource.end based on size of physical address space,
+ * or linear region size when (VA_BITS - 1) is smaller than PA_BITS.
+ */
+ iomem_resource.end = BIT(min(PHYS_MASK_SHIFT, VA_BITS - 1)) - 1;
+
+ /*
* Select a suitable value for the base of physical memory.
*/
memstart_addr = round_down(memblock_start_of_DRAM(),
--
2.1.4
^ permalink raw reply related
* [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Peter Rosin @ 2018-05-09 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4be4448e-763c-4832-f194-6b79afe87d08@axentia.se>
On 2018-05-09 17:53, Peter Rosin wrote:
> On 2018-05-09 17:08, Andrzej Hajda wrote:
>> On 04.05.2018 15:51, Peter Rosin wrote:
>>> Bridge drivers can now (temporarily, in a transition phase) select if
>>> they want to provide a full owner device or keep just providing an
>>> of_node.
>>>
>>> By providing a full owner device, the bridge drivers no longer need
>>> to provide an of_node since that node is available via the owner
>>> device.
>>>
>>> When all bridge drivers provide an owner device, that will become
>>> mandatory and the .of_node member will be removed.
>>>
>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>> ---
>>> drivers/gpu/drm/drm_bridge.c | 3 ++-
>>> drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
>>
>> What is the reason to put rockchip here? Shouldn't be in separate patch?
>
> Because the rockchip driver peeks into the bridge struct and all the
> changes in this patch relate to making the new .odev member optional in
> the transition phase, when the bridge can have either a new-style odev
> or an old style of_node.
>
> I guess this rockchip change could be patch 2, but it has to come first
> after this patch and it makes no sense on its own. Hence, one patch.
>
> This rockchip_lvds interaction is also present in patch 24/26
> drm/bridge: remove the .of_node member
>
> I can split them if you want, but I personally don't see the point.
I had a second look, and maybe the series should start with a patch like
this instead, so that the rockchip_lvds.c hunks can be removed from
patch 1/26 and 24/26. That would perhaps be slightly cleaner?
On the other hand, it's orthogonal and this series can be left as is
(with the benefit of me not having to do another iteration and you all
not having another bunch of messages to sift through). The below
patch could easily be (adjusted and) applied later instead. Or not,
since the right fix is to do this with the newfangled static image
format mechanism from Jacopo Mondi, and it might be easier to just do
it right.
State your preference.
Cheers,
Peter
>From dee27b36a36acd271459d1489336b56132097425 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda@axentia.se>
Date: Wed, 9 May 2018 23:58:24 +0200
Subject: [PATCH] drm/rockchip: lvds: do not dig into the DT of remote bridges
The driver is trying to find the needed "data-mapping" for
interacting with the following bridge in the graphics chain.
But, doing so is bad since it is done w/o regard of the
compatible of the remote bridge, so the value of "data-mapping"
might not mean what this driver assumes. It is also pointless
since no bridge has any documented "data-mapping" DT property
and no dts file show any undocumented use.
Just remove the inappropriate code.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..fa3f4bf9712f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else
- remote = lvds->bridge->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
--
2.11.0
^ permalink raw reply related
* [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
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