* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Rafael J. Wysocki @ 2018-06-05 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec94a230-2798-8001-d3c5-902ea6f1855b@arm.com>
On Tue, Jun 5, 2018 at 6:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:12, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 5:33 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>>
>>> On 05/06/18 16:00, Rafael J. Wysocki wrote:
>>>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
>>>>> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>>>>>
>>>>> This patch adds the missing dummy/boiler plate implementation to fix
>>>>> the build.
>>>>>
>>>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> include/linux/acpi.h | 15 +++++++++++++++
>>>>> include/linux/cacheinfo.h | 2 +-
>>>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>>>
>>>>> Hi Rafael,
>>>>>
>>>>> If you are fine with this, can you provide Ack, so that we route this
>>>>> through ARM64 tree where most of the ACPI PPTT support is present.
>>>>>
>>>>> Regards,
>>>>> Sudeep
>>>>>
>>>>> v1->v2:
>>>>> - removed duplicate definition for acpi_find_last_cache_level
>>>>>
>>>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>>>> index 8f2cdb0eca71..4b35a66383f9 100644
>>>>> --- a/include/linux/acpi.h
>>>>> +++ b/include/linux/acpi.h
>>>>> @@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
>>>>> }
>>>>> #endif
>>>>>
>>>>> +#ifdef CONFIG_ACPI_PPTT
>>>>> int find_acpi_cpu_topology(unsigned int cpu, int level);
>>>>> int find_acpi_cpu_topology_package(unsigned int cpu);
>>>>> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
>>>>> +#else
>>>>> +static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
>>>>> +{
>>>>> + return -EINVAL;
>>>>
>>>> Why -EINVAL?
>>>>
>>>
>>> I am not sure either. I used to return -ENOTSUPP, but IIRC someone
>>> suggested to use it only for syscalls. Also I just based it on other
>>> existing functions in acpi.h
>>>
>>> I am open for any alternatives if you think that is better here.
>>
>> It would be good to make it consistent with the error codes returned
>> by the functions when they are present.
>>
>> Anyway, it's fine by me if that's consistent with the other acpi.h stubs.
>>
>
> Thanks, indeed I copied it from existing stubs.
>
> Can I take this as official Ack ?
Yes, please.
^ permalink raw reply
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Andy Shevchenko @ 2018-06-05 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526907189-10031-1-git-send-email-sudeep.holla@arm.com>
On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> of_property_read_u32 searches for a property in a device node and read
> a 32-bit value from it. Instead of using of_get_property to get the
> property and then read 32-bit value using of_read_number, we can
> simplify it by using of_property_read_u32.
>
LGTM.
Thanks!
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/cacheinfo.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> Hi Andy,
>
> Ignore my comment on compile errors error with Werror=incompatible-pointer-types
> I was so hung up on _u64 version and didn't realise that we were using 32-bit
> with of_read_number originally.
>
> Regards,
> Sudeep
>
> v1->v2:
> - Replaced use of of_property_read_u64 with of_property_read_u32
> - Also removed the local variables as Andy initially suggested
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 2880e2ab01f5..5d5b5988e88b 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *cache_size;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->size))
> + this_leaf->size = 0;
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> static void cache_get_line_size(struct cacheinfo *this_leaf,
> struct device_node *np)
> {
> - const __be32 *line_size;
> int i, lim, ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
>
> for (i = 0; i < lim; i++) {
> + int ret;
> + u32 line_size;
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + ret = of_property_read_u32(np, propname, &line_size);
> + if (!ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> }
> -
> - if (line_size)
> - this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *nr_sets;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(np, propname, NULL);
> - if (nr_sets)
> - this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
> + this_leaf->number_of_sets = 0;
> }
>
> static void cache_associativity(struct cacheinfo *this_leaf)
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Sudeep Holla @ 2018-06-05 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd_rQFX1s6jCbj-uLC3K70sSD=s0rt3sWme_f2m90NE5A@mail.gmail.com>
On 05/06/18 17:21, Andy Shevchenko wrote:
> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> of_property_read_u32 searches for a property in a device node and read
>> a 32-bit value from it. Instead of using of_get_property to get the
>> property and then read 32-bit value using of_read_number, we can
>> simplify it by using of_property_read_u32.
>>
>
> LGTM.
> Thanks!
>
Thanks, can I take is Ack ?
Anyways it's too late for v4.18, will repost after the merge window for
v4.19 with your Ack if you agree.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources()
From: Andy Shevchenko @ 2018-06-05 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f35b2972-aa40-5397-facb-765cafe7c315@siemens.com>
On Wed, May 16, 2018 at 3:31 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Instead of first allocating and then freeing memory for struct resource
> in case we cannot parse a PCI resource from the device tree, work
> against a local struct and kmemdup it when we decide to go with it.
>
Bjorn, any comments on this?
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> drivers/pci/of.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index b06585a1da75..fc0f906c5c25 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -266,7 +266,7 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> struct list_head *resources, resource_size_t *io_base)
> {
> struct device_node *dev_node = dev->of_node;
> - struct resource *res;
> + struct resource *res, tmp_res;
> struct resource *bus_range;
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> @@ -320,18 +320,16 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> continue;
>
> - res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
> + err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
> + if (err)
> + continue;
> +
> + res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
> if (!res) {
> err = -ENOMEM;
> goto failed;
> }
>
> - err = of_pci_range_to_resource(&range, dev_node, res);
> - if (err) {
> - devm_kfree(dev, res);
> - continue;
> - }
> -
> if (resource_type(res) == IORESOURCE_IO) {
> if (!io_base) {
> dev_err(dev,
> --
> 2.13.6
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 0/2] Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
Add devicetree support for Mediatek X20 Development Board by Archermind.
This board is based on the Deca-Core MT6797 SoC from Mediatek and is
one of the 96Boards Consumer Edition platform.
With this devicetree change, board can boot into initramfs.
More information about this board can be found in 96Boards product page:
https://www.96boards.org/product/mediatek-x20/
Thanks,
Mani
Changes in v2:
* Added documentation for board compatible
* Dropped vendor documetation patch since it got applied
Manivannan Sadhasivam (2):
dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
arm64: dts: Add Mediatek X20 Development Board support
.../devicetree/bindings/arm/mediatek.txt | 3 ++
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
3 files changed, 37 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Document Mediatek X20 Development Board which is a 96Boards Consumer
Edition platform based on MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
index 7d21ab37c19c..356df1ee11b9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -47,6 +47,9 @@ Supported boards:
- Evaluation board for MT6797(Helio X20):
Required root node properties:
- compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
+- Mediatek X20 Development Board:
+ Required root node properties:
+ - compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
- Reference board variant 1 for MT7622:
Required root node properties:
- compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60f998c..5b7fd6ad96e4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
new file mode 100644
index 000000000000..2c09ca95d9e2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for MediaTek X20 Development Board
+ *
+ * Copyright (C) 2018, Linaro Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "mt6797.dtsi"
+
+/ {
+ model = "Mediatek X20 Development Board";
+ compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x1e605000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Andy Shevchenko @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54785881-da7c-db68-c6a4-70cfd489c1fe@arm.com>
On Tue, Jun 5, 2018 at 7:26 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:21, Andy Shevchenko wrote:
>> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> of_property_read_u32 searches for a property in a device node and read
>>> a 32-bit value from it. Instead of using of_get_property to get the
>>> property and then read 32-bit value using of_read_number, we can
>>> simplify it by using of_property_read_u32.
>>>
>>
>> LGTM.
>> Thanks!
>>
>
> Thanks, can I take is Ack ?
>
> Anyways it's too late for v4.18, will repost after the merge window for
> v4.19 with your Ack if you agree.
You can consider like this, though it makes a little change here since
I'm not a maintainer of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Jeremy Linton @ 2018-06-05 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a93212e3-7965-9ae2-34b0-407f04590567@arm.com>
Hi,
On 06/05/2018 10:27 AM, Sudeep Holla wrote:
>
>
> On 05/06/18 16:02, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> Currently, ARM64 doesn't support updating the CPU topology masks on
>>> CPU hotplug operations. ACPI PPTT support rely on that missing feature
>>> which is technically not incorrect. Instead of reverting all the PPTT
>>> support, let's keep it simple and disable ACPI PPTT support on ARM64
>>> for time-being until the topology updates are added for CPU hotplug
>>> operations.
>>
>> When is that going to happen?
>>> Nobody else uses PPTT now.
>>
>
> No we need it on ARM64. I have even the fixes for the original issue
> but it's bit invasive and too late as we are already in the merge
> window. It needs to be tested on NUMA platforms, I have asked for that
> explicitly.
>
So, there is a lot simpler fix for this, and its to remove the numa mask
dependency from the scheduler domain building. That is just a couple
line fix, and it reverts !ACPI to its original behavior, while the ACPI
LLC building will work around the NUMA in package issue that caused
patch 12/12 as the machine in question doesn't have a LLC crossing numa
domains.
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Will Deacon @ 2018-06-05 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528140881044.41145@nvidia.com>
Hi Alex,
On Mon, Jun 04, 2018 at 07:34:10PM +0000, Alexander Van Brunt wrote:
> __flush_icache_all all cache is slow in large systems. It flushes the
> instruction caches cache in the inner-shareable domain. That includes
> other NUMA nodes in multi-socket systems. The CPU issuing the invalidate
> has to wait for all of the other CPUs to complete the invalidate
> instruction. The remote CPU's responding to the request all need to slow
> down.
>
> In contrast, flushes by range can be checked in a snoop filter to see if
> the addresses are relevant to the CPU. So, it scales to systems with more
> than two clusters much better.
>
> The flush ignores the VMID. So, one guest OS can slow down others. That
> creates a big covert channel between guests unless the hypervisor traps
> and emulates it by invalidating an entire VMID. By flushing by VA range,
> the hardware only flushes lines associated with the VMID, ASID, and VA
> associated with the line.
>
> Selfishly, NVIDIA's Denver CPU's are even more sensitive because the
> optimized code stored in DRAM is effectively a very large (on the order of
> 64 MB) instruction cache. "ic ialluis" can result in the entire
> optimization cache for all guests to be invalidated.
>
> I am aware that the arguments I made apply to TLB invalidates and the
> other places that Linux calls __flush_icache_all. But, that doesn't mean I
> don't like those either. For now, I just don't want more calls to
> __flush_icache_all.
Sure, but there are only two cases to consider here:
1. Boot. This happens once, and we end up putting *all* secondary cores into
a tight loop anyway, so I don't see that the performance of
__flush_icache_all is relevant
2. On module load. This happens right before we start remapping the module
areas and sending out TLB invalidation so, again, not sure I see why this
is such a big deal. In fact, it looks like the core module loading code
does invalidation by range, so if we remove it from __apply_alternatives
then we can avoid doing it twice.
In other words, something like the diff below.
Will
--->8
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index a91933b1e2e6..934f99215bd4 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -28,7 +28,12 @@ typedef void (*alternative_cb_t)(struct alt_instr *alt,
__le32 *origptr, __le32 *updptr, int nr_inst);
void __init apply_alternatives_all(void);
-void apply_alternatives(void *start, size_t length);
+
+#ifdef CONFIG_MODULES
+void apply_alternatives_module(void *start, size_t length);
+#else
+void apply_alternatives_module(void *start, size_t length) { }
+#endif
#define ALTINSTR_ENTRY(feature,cb) \
" .word 661b - .\n" /* label */ \
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 9bbffc7a301f..627d62ff2ddd 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -21,6 +21,7 @@
#define CTR_L1IP_SHIFT 14
#define CTR_L1IP_MASK 3
#define CTR_DMINLINE_SHIFT 16
+#define CTR_IMINLINE_SHIFT 0
#define CTR_ERG_SHIFT 20
#define CTR_CWG_SHIFT 24
#define CTR_CWG_MASK 15
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 5c4bce4ac381..6c813f58824b 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -122,7 +122,29 @@ static void patch_alternative(struct alt_instr *alt,
}
}
-static void __apply_alternatives(void *alt_region, bool use_linear_alias)
+static void clean_dcache_range_nopatch(u64 start, u64 end)
+{
+ u64 cur, d_size, i_size, ctr_el0;
+
+ /* use sanitised value of ctr_el0 rather than raw value from CPU */
+ ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0);
+ /* size in bytes */
+ d_size = 4 << cpuid_feature_extract_unsigned_field(ctr_el0,
+ CTR_DMINLINE_SHIFT);
+ i_size = 4 << cpuid_feature_extract_unsigned_field(ctr_el0,
+ CTR_IMINLINE_SHIFT);
+
+ cur = start & ~(d_size - 1);
+ do {
+ /*
+ * We must clean+invalidate in order to avoid Cortex-A53
+ * errata 826319, 827319, 824069 and 819472.
+ */
+ asm volatile("dc civac, %0" : : "r" (cur) : "memory");
+ } while (cur += d_size, cur < end);
+}
+
+static void __apply_alternatives(void *alt_region, bool is_module)
{
struct alt_instr *alt;
struct alt_region *region = alt_region;
@@ -145,7 +167,7 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
pr_info_once("patching kernel code\n");
origptr = ALT_ORIG_PTR(alt);
- updptr = use_linear_alias ? lm_alias(origptr) : origptr;
+ updptr = is_module ? origptr : lm_alias(origptr);
nr_inst = alt->orig_len / AARCH64_INSN_SIZE;
if (alt->cpufeature < ARM64_CB_PATCH)
@@ -155,9 +177,23 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
alt_cb(alt, origptr, updptr, nr_inst);
- flush_icache_range((uintptr_t)origptr,
- (uintptr_t)(origptr + nr_inst));
+ if (is_module)
+ continue;
+
+ clean_dcache_range_nopatch((u64)origptr,
+ (u64)(origptr + nr_inst));
}
+
+ /*
+ * The core module code takes care of cache maintenance in
+ * flush_module_icache().
+ */
+ if (is_module)
+ return;
+
+ dsb(ish);
+ __flush_icache_all();
+ isb();
}
/*
@@ -178,7 +214,7 @@ static int __apply_alternatives_multi_stop(void *unused)
isb();
} else {
BUG_ON(alternatives_applied);
- __apply_alternatives(®ion, true);
+ __apply_alternatives(®ion, false);
/* Barriers provided by the cache flushing */
WRITE_ONCE(alternatives_applied, 1);
}
@@ -192,12 +228,14 @@ void __init apply_alternatives_all(void)
stop_machine(__apply_alternatives_multi_stop, NULL, cpu_online_mask);
}
-void apply_alternatives(void *start, size_t length)
+#ifdef CONFIG_MODULES
+void apply_alternatives_module(void *start, size_t length)
{
struct alt_region region = {
.begin = start,
.end = start + length,
};
- __apply_alternatives(®ion, false);
+ __apply_alternatives(®ion, true);
}
+#endif
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 155fd91e78f4..f0f27aeefb73 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -448,9 +448,8 @@ int module_finalize(const Elf_Ehdr *hdr,
const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++) {
- if (strcmp(".altinstructions", secstrs + s->sh_name) == 0) {
- apply_alternatives((void *)s->sh_addr, s->sh_size);
- }
+ if (strcmp(".altinstructions", secstrs + s->sh_name) == 0)
+ apply_alternatives_module((void *)s->sh_addr, s->sh_size);
#ifdef CONFIG_ARM64_MODULE_PLTS
if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
!strcmp(".text.ftrace_trampoline", secstrs + s->sh_name))
^ permalink raw reply related
* [PATCH v2] dmaengine: ti: omap-dma: Fix OMAP1510 incorrect residue_granularity
From: Janusz Krzysztofik @ 2018-06-05 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
instead of omap-pcm") resulted in broken audio playback on OMAP1510
(discovered on Amstrad Delta).
When running on OMAP1510, omap-pcm used to obtain DMA offset from
snd_dmaengine_pcm_pointer_no_residue() based on DMA interrupt triggered
software calculations instead of snd_dmaengine_pcm_pointer() which
depended on residue value calculated from omap_dma_get_src_pos().
Similar code path is still available in now used
sound/soc/soc-generic-dmaengine-pcm.c but it is not triggered.
It was verified already before that omap_get_dma_src_pos() from
arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
callback") for details. Apparently the same applies to its successor,
omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
On the other hand, snd_dmaengine_pcm_pointer_no_residue() is described
as depreciated and discouraged for use in new drivers because of its
unreliable accuracy. However, it seems the only working option for
OPAM1510 now, as long as a software calculated residue is not
implemented as OMAP1510 fallback in omap-dma.
Using snd_dmaengine_pcm_pointer_no_residue() code path instead of
snd_dmaengine_pcm_pointer() in sound/soc/soc-generic-dmaengine-pcm.c
can be triggered in two ways:
- by passing pcm->flags |= SND_DMAENGINE_PCM_FLAG_NO_RESIDUE from
sound/soc/omap/sdma-pcm.c,
- by passing dma_caps.residue_granularity =
DMA_RESIDUE_GRANULARITY_DESCRIPTOR from DMA engine.
Let's do the latter.
Created and tested against next-20180531 tag from linux-next tree.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Changelog:
v2: fix subject as requested by Peter.
drivers/dma/ti/omap-dma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
index b73fb51fbc81..96b5096c26dd 100644
--- a/drivers/dma/ti/omap-dma.c
+++ b/drivers/dma/ti/omap-dma.c
@@ -1485,7 +1485,11 @@ static int omap_dma_probe(struct platform_device *pdev)
od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
- od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ if (__dma_omap15xx(od->plat->dma_attr))
+ od->ddev.residue_granularity =
+ DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+ else
+ od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
od->ddev.max_burst = SZ_16M - 1; /* CCEN: 24bit unsigned */
od->ddev.dev = &pdev->dev;
INIT_LIST_HEAD(&od->ddev.channels);
--
2.16.1
^ permalink raw reply related
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Alexander Van Brunt @ 2018-06-05 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605165511.GB2193@arm.com>
> 1. Boot. This happens once, and we end up putting *all* secondary cores into
> a tight loop anyway, so I don't see that the performance of
> __flush_icache_all is relevant
Native boot happens once. But, each VM that boots will slow down all of the other VM's on the system. A VM boot can happen thousands of times.
I really don't want to cause the whole system to hiccup for a millisecond or more when there are only a few cache lines that need to be invalidated.
^ permalink raw reply
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Catalin Marinas @ 2018-06-05 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-2-git-send-email-sudeep.holla@arm.com>
On Tue, Jun 05, 2018 at 03:35:03PM +0100, Sudeep Holla wrote:
> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>
> This patch adds the missing dummy/boiler plate implementation to fix
> the build.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> include/linux/acpi.h | 15 +++++++++++++++
> include/linux/cacheinfo.h | 2 +-
> 2 files changed, 16 insertions(+), 1 deletion(-)
I queued this patch for now, it's a good clean-up regardless of whether
we disable PPTT temporarily or not.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
From: Geert Uytterhoeven @ 2018-06-05 17:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Add a device node for the Watchdog Timer (WDT) controller on the
R8A77990 SoC, and enable the watchdog on the Ebisu board.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Squashed 2 commits]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 5 +++++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 7a09d0524f9b0663..28945a8b980080f2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -60,6 +60,11 @@
};
};
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 6d597a1c7636784f..735881d4e57ac1ad 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -69,6 +69,16 @@
#size-cells = <2>;
ranges;
+ rwdt: watchdog at e6020000 {
+ compatible = "renesas,r8a77990-wdt",
+ "renesas,rcar-gen3-wdt";
+ reg = <0 0xe6020000 0 0x0c>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc 32>;
+ resets = <&cpg 402>;
+ status = "disabled";
+ };
+
gpio0: gpio at e6050000 {
compatible = "renesas,gpio-r8a77990",
"renesas,rcar-gen3-gpio";
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-05 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528198148-23308-3-git-send-email-michel.pollet@bp.renesas.com>
On 06/05/18 04:28, Michel Pollet wrote:
> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
> requires a special enable method to get it started.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> ---
> arch/arm/mach-shmobile/Makefile | 1 +
> arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>
> diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
> index 1939f52..d7fc98f 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
> smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
> +smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
> smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
>
> # PM objects
> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
> new file mode 100644
> index 0000000..cd40e6e
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R9A06G032 Second CA7 enabler.
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from action,s500-smp
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +
> +/*
> + * The second CPU is parked in ROM at boot time. It requires waking it after
> + * writing an address into the BOOTADDR register of sysctrl.
> + *
> + * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
> + *
> + * *However* the BOOTADDR register is not available when the kernel
> + * starts in NONSEC mode.
> + *
> + * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
> + * which is not restricted.
The binding document for cpu-release-addr does not have a definition for 32 bit
arm. The existing definition is only 64 bit arm. Please add the definition
for 32 bit arm to patch 1.
-Frank
> + */
> +
> +static void __iomem *cpu_bootaddr;
> +
> +static DEFINE_SPINLOCK(cpu_lock);
> +
> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> + if (!cpu_bootaddr)
> + return -ENODEV;
> +
> + spin_lock(&cpu_lock);
> +
> + writel(__pa_symbol(secondary_startup), cpu_bootaddr);
> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> +
> + spin_unlock(&cpu_lock);
> +
> + return 0;
> +}
> +
> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
> +{
> + struct device_node *dn;
> + int ret;
> + u32 bootaddr;
> +
> + dn = of_get_cpu_node(1, NULL);
> + if (!dn) {
> + pr_err("CPU#1: missing device tree node\n");
> + return;
> + }
> + /*
> + * Determine the address from which the CPU is polling.
> + * The bootloader *does* change this property
> + */
> + ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
> + of_node_put(dn);
> + if (ret) {
> + pr_err("CPU#1: invalid cpu-release-addr property\n");
> + return;
> + }
> + pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
> +
> + cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
> +}
> +
> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
> + .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
> + .smp_boot_secondary = r9a06g032_smp_boot_secondary,
> +};
> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
>
^ permalink raw reply
* How to print stack uses of IRQ in ARM64
From: James Morse @ 2018-06-05 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VcTvMKy8h_2gztav2FOUvE1QG01FByTNmc=x0bdyRx5Dg@mail.gmail.com>
Hi Vishun,
(CC: +linux-arm-kernel list)
On 05/06/18 14:12, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 1:01 PM, Vishnu Motghare
> <vishnumotghare@gmail.com> wrote:
>> My understanding is each CPU getting its own IRQ stack. So is it
>> possible to print the stack uses of each IRQ handler?
The stacks are per-cpu not per-handler, so you would get a jumble of different
interrupt-handlers, mixed up with softirq that runs on the same stack.
>> like, How much stack is used & how much left free ?
What would you do with the information?
>> like in process context we have API like stack_not_used(struct
>> task_struct *p) to get the unused stack of processes.
Isn't this only printed when the process exits?
When would you print it for an irqstack?
To get this information you would need to mask interrupts, then search backwards
on the irq-stack to find the 'last' value. I think it would always be more
useful to take interrupts in that time...
>> So, is it possible to get the similar result for IRQ?
Probably, but I don't think its useful.
If you're debugging a stack-overflow, its much better to use vmap stacks, which
will give you the function and stack trace that triggered the overflow.
Thanks,
James
^ permalink raw reply
* panic kexec broken on ARM64?
From: James Morse @ 2018-06-05 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605100151.7fd54381@ezekiel.suse.cz>
Hi Petr,
(CC: +Akashi, Marc)
On 05/06/18 09:01, Petr Tesarik wrote:
> I have observed hangs after crash on a Raspberry Pi 3 Model B+ board
> when a panic kernel is loaded.
kdump is a best-effort thing, it looks like this is a case where the
crashed-kernel can't tear itself down.
Do you have the rest of the stack trace? Was it handling an irq when it decided
to panic?:
https://lkml.org/lkml/2018/3/13/1134
> I attached a hardware debugger and found
> out that all CPU cores were stopped except one which was stuck in the
> idle thread. It seems that irq_set_irqchip_state() may sleep, which is
> definitely not safe after a kernel panic.
I don't know much about irqchip stuff, but __irq_get_desc_lock() takes a
raw_spin_lock(), and calls gic_irq_get_irqchip_state() which is just poking
around in mmio registers, this should all be safe unless you re-entered the same
code.
> If I'm right, then this is broken in general, but I have only ever seen
> it on RPi 3 Model B+ (even RPi3 Model B works fine), so the issue may
> be more subtle.
Is there a hardware difference around the interrupt controller on these?
> FWIW the code for 32-bit ARM seems to work just fine
> without this code in machine_kexec_mask_interrupts():
>
> /*
> * First try to remove the active state. If this
> * fails, try to EOI the interrupt.
> */
> ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
>
> I wonder what breaks if this call to irq_set_irqchip_state() is removed.
My understanding is this is to reset all interrupts so the new kernel doesn't
spend its first waking minutes declaring all these pending interrupts as
spurious as the device drivers haven't (re-)claimed them yet.
I don't know if/how this is done on 32bit.
> For reference, here is a stack trace of the process which originally
> triggered the panic:
>
> #0 __switch_to (prev=0xffff000008e62a00 <init_task>, next=0xffff80002b796080) at ../arch/arm64/kernel/process.c:355
> #1 0xffff0000088f584c in context_switch (rf=<optimized out>, next=<optimized out>, prev=<optimized out>, rq=<optimized out>) at ../kernel/sched/core.c:2896
> #2 __schedule (preempt=false) at ../kernel/sched/core.c:3457
> #3 0xffff0000088f5eac in schedule () at ../kernel/sched/core.c:3516
> #4 0xffff0000088f9448 in schedule_timeout (timeout=<optimized out>) at ../kernel/time/timer.c:1743
> #5 0xffff0000088f6afc in do_wait_for_common (state=<optimized out>, timeout=500, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:77
> #6 __wait_for_common (state=<optimized out>, timeout=<optimized out>, action=<optimized out>, x=<optimized out>) at ../kernel/sched/completion.c:96
> #7 wait_for_common (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500, state=<optimized out>) at ../kernel/sched/completion.c:104
> #8 0xffff0000088f6c1c in wait_for_completion_timeout (x=0xffff000008e53848 <init_thread_union+14408>, timeout=500) at ../kernel/sched/completion.c:144
> #9 0xffff000000a19f1c in usb_start_wait_urb (urb=0xffff80002c1cd700, timeout=5000, actual_length=0xffff000008e538dc <init_thread_union+14556>)
> at ../drivers/usb/core/message.c:61
(USB?!)
> #10 0xffff000000a1a05c in usb_internal_control_msg (timeout=<optimized out>, len=<optimized out>, data=<optimized out>, cmd=<optimized out>, pipe=<optimized out>,
> usb_dev=<optimized out>) at ../drivers/usb/core/message.c:100
> #11 usb_control_msg (dev=0xffff80002c348000, pipe=2147484800, request=161 '\241', requesttype=192 '\300', value=0, index=152, data=0xffff80002b6fa080, size=4,
> timeout=5000) at ../drivers/usb/core/message.c:151
> #12 0xffff000001001cd0 in lan78xx_read_reg (index=152, data=0xffff000008e5396c <init_thread_union+14700>, dev=<optimized out>, dev=<optimized out>)
> at ../drivers/net/usb/lan78xx.c:425
> #13 0xffff00000100365c in lan78xx_irq_bus_sync_unlock (irqd=<optimized out>) at ../drivers/net/usb/lan78xx.c:1909
I'm not sure what these 'struct irq_chip' outside drivers/irqchip are,
presumably irq-controllers can be nested, and devices believe they are interrupt
controllers too.
This looks like yours is actually a network chip on the other end of a usb bus.
Any configuration attempt involves taking mutexs, allocating memory and sitting
on a wait queue until the response comes, (all relying on a different kind of
interrupt).
So for this network-irqcontroller-chip its not safe to call
irq_set_irqchip_state() from irq context. (you also survived taking a mutex and
allocating a few buffers before hitting the wait queue).
I'm not sure how this should be fixed, but as suggested on that irqchip thread
above, having a irqchip-specific separate 'reset' API could do something more
drastic than trying to modify the configuration, which requires these
locks/memory-allocation.
> #14 0xffff00000813e590 in chip_bus_sync_unlock (desc=<optimized out>) at ../kernel/irq/internals.h:129
> #15 __irq_put_desc_unlock (desc=0xffff80002c361c00, flags=128, bus=true) at ../kernel/irq/irqdesc.c:804
> #16 0xffff00000813f604 in irq_put_desc_busunlock (flags=<optimized out>, desc=<optimized out>) at ../kernel/irq/internals.h:155
> #17 irq_set_irqchip_state (irq=<optimized out>, which=<optimized out>, val=false) at ../kernel/irq/manage.c:2136
> #18 0xffff00000809b7d4 in machine_kexec_mask_interrupts () at ../arch/arm64/kernel/machine_kexec.c:233
> #19 machine_crash_shutdown (regs=<optimized out>) at ../arch/arm64/kernel/machine_kexec.c:259
> #20 0xffff000008180fd4 in __crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:943
> #21 0xffff0000081810e4 in crash_kexec (regs=0xffff000008e53d70 <init_thread_union+15728>) at ../kernel/kexec_core.c:965
> #22 0xffff00000808ab58 in die (str=<optimized out>, regs=0xffff000008e53d70 <init_thread_union+15728>, err=-2046820348) at ../arch/arm64/kernel/traps.c:266
> #23 0xffff0000080a1c14 in __do_kernel_fault (mm=0x0, addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:226
> #24 0xffff0000088fc8dc in do_page_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:476
> #25 0xffff0000088fccdc in do_translation_fault (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:502
> #26 0xffff000008081478 in do_mem_abort (addr=0, esr=2248146948, regs=0xffff000008e53d70 <init_thread_union+15728>) at ../arch/arm64/mm/fault.c:657
> #27 0xffff000008082dd0 in el1_sync () at ../arch/arm64/kernel/entry.S:548
What was going on just before this NULL deference? This looks like CPU0's idle
thread stack, which rules out another irq.
Thanks,
James
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-05 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605145038.qptdlcphdbnw6jyg@flea>
On 05/06/18 15:50, Maxime Ripard wrote:
> On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
>> On 04/06/18 09:13, Maxime Ripard wrote:
>>> On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>>
>>>> + * This file is dual-licensed: you can use it either under the terms
>>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>>> + * licensing only applies to this file, and not this project as a
>>>> + * whole.
>>
>>>> + * The above copyright notice and this permission notice shall be
>>>> + * included in all copies or substantial portions of the Software.
>>
>>> And this is redundant with the SPDX header.
>>
>> The X11 license notice states explicitly that the notice has to be
>> included in the file. Wouldn't removing it be a violation of the license?
>
> The SPDX header is explicitly here to remove the license text and
> create a tag that is in a indirect reference to the license text in
> LICENSES. It's not going away.
Well, the top bit that I quoted above says that the licenses refer to
only that one file in particular and not the project as a whole. Then
the X11 license states that the notice can't be removed from 'this
software and associated documentation files (the "Software")' which
would seem to refer to the single file. Therefore, removing the notice
from the single file and replacing it with an SPDX header would seem to
violate the license.
It's a fine point but it makes me nervous. I originally based my .dts
on sun4i-a10-inet1.dts. I've CC'd the original copyright holder, Hans
de Goede. Hans, are you willing to give permission for the license
notice to be replaced with just an SPDX header indicating the dual
licensing?
While we're at it, there are a number of other files with the same
license text. Hans, are you prepared to give permission for your other
license notices to be replaced with SPDX headers?
Thanks,
Bob
--
Bob Ham <rah@settrans.net>
for (;;) { ++pancakes; }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2913 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/c91f541e/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Takashi Iwai @ 2018-06-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2ae6c5b6-872a-9aaa-6ca4-e29adb7c8bc0@st.com>
On Tue, 05 Jun 2018 17:50:57 +0200,
Arnaud Pouliquen wrote:
>
> Hi Takashi,
>
> On 04/17/2018 01:17 PM, Mark Brown wrote:
> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
> >
> >> I guess the blocking patch in this patchset is the patch "add IEC958
> >> channel status control helper". This patch has been reviewed several
> >> times, but did not get a ack so far.
> >> If you think these helpers will not be merged, I will reintegrate the
> >> corresponding code in stm driver.
> >> Please let me know, if I need to prepare a v2 without helpers, or if we
> >> can go further in the review of iec helpers patch ?
> >
> > I don't mind either way but you're right here, I'm waiting for Takashi
> > to review the first patch.? I'd probably be OK with it just integrated
> > into the driver if we have to go that way though.
>
> Gentlemen reminder for this patch set. We would appreciate to have your
> feedback on iec helper.
> From our point of view it could be useful to have a generic management
> of the iec controls based on helpers instead of redefining them in DAIs.
> Having the same behavior for these controls could be useful to ensure
> coherence of the control management used by application (for instance
> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
Oh sorry for the late reply, I've totally overlooked the thread.
And, another sorry: the patchset doesn't look convincing enough to
me.
First off, the provided API definition appears somewhat
unconventional, the mixture of the ops, the static data and the
dynamic data.
Moreover, this is only for your driver, ATM. If it were an API that
does clean up the already existing usages, I'd happily apply it. There
are lots of drivers creating and controlling the IEC958 ctls even
now.
Also, the patchset requires more fine-tuning, in anyways. The changes
in create_iec958_consumre() are basically irrelevant, should be split
off as an individual fix. Also, the new function doesn't create the
"XXX Mask" controls. And the byte comparison should be replaced with
memcmp(), etc, etc.
So, please proceed rather with the open codes for now. If you can
provide a patch that cleans up the *multiple* driver codes, again,
I'll happily take it. But it can be done anytime later, too.
thanks,
Takashi
^ permalink raw reply
* [PATCH V3] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 18:48 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 "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++++++++++++++++++++++
2 files changed, 314 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..59048740ae06
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// 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 = "kobol,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";
+ };
+
+ 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 {
+ 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] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Jeremy Linton @ 2018-06-05 19:08 UTC (permalink / raw)
To: linux-arm-kernel
The numa mask subset check has problems if !CONFIG_NUMA, over hotplug
operations or during early boot. Lets disable the NUMA siblings checks
for the time being, as NUMA in socket machines have LLC's that will
assure that the scheduler topology isn't "borken".
Futher, as a defensive mechanism during hotplug, lets assure that the
LLC siblings are also masked.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/topology.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..f845a8617812 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,13 +215,8 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].core_sibling;
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
if (cpu_topology[cpu].llc_id != -1) {
if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
core_mask = &cpu_topology[cpu].llc_siblings;
@@ -239,8 +234,10 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ if (cpuid_topo->llc_id == cpu_topo->llc_id) {
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+ cpumask_set_cpu(cpuid, &cpu_topo->llc_siblings);
+ }
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
--
2.14.3
^ permalink raw reply related
* [PATCH] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0
From: Martin Blumenstingl @ 2018-06-05 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528188743-12798-1-git-send-email-narmstrong@baylibre.com>
On Tue, Jun 5, 2018 at 10:52 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
> devices on the P212 Reference Design based boards.
>
> Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
out of curiosity: I guess you tested this using u-boot?
if anyone else is interested: the only other way to test this is by
ensuring that the hdmi_5v regulator is turned off by Linux (by
removing it from the HDMI nodes) and then plugging in a USB device ->
if it doesn't get VBUS then the hdmi_5v regulator is the cause (and
needs to be kept/turned on by the USB code, just like Neil's patch
does)
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> index 0cfd701..a1b3101 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
> @@ -189,3 +189,10 @@
> &usb0 {
> status = "okay";
> };
> +
> +&usb2_phy0 {
> + /*
> + * HDMI_5V is also used as supply for the USB VBUS.
> + */
> + phy-supply = <&hdmi_5v>;
> +};
> --
> 2.7.4
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Rob Herring @ 2018-06-05 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-2-git-send-email-ray.jui@broadcom.com>
On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
> Consolidate two SP805 binding documents "arm,sp805.txt" and
> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
> desired compatible string to be used
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
> 2 files changed, 20 insertions(+), 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
Would be good to get a ACK from FSL/NXP person on this. It looks to me
like the driver fetches the wrong clock as it gets the first one and the
driver really wants 'wdog_clk'. In any case, their dts files should be
updated.
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18
From: Dinh Nguyen @ 2018-06-05 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524494393-8052-1-git-send-email-dinguyen@kernel.org>
Hi Olof, Kevin, and Arnd:
Perhaps this pull request got buried in your inbox somewhere?
There are a few patches that touches the socfpga_stratix10.dtsi that are
in the EDAC branch that is dependent on these patches, so Boris is
taking these patches through his edac changes for v4.18.
Dinh
On 04/23/2018 09:39 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please full in these SoCFPGA Stratix10 DTS updates for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v4.18_part1
>
> for you to fetch changes up to ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA DTS updates for v4.18
> - Stratix10 platform updates
> - Populate clock properties for platform
> - Enable DMA and I2C
>
> ----------------------------------------------------------------
> Alan Tull (1):
> arm64: dts: stratix10: enable i2c, add i2c periperals
>
> Dinh Nguyen (1):
> arm64: dts: stratix10: use clock bindings for the Stratix10 platform
>
> Graham Moore (1):
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts
>
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 71 +++++++++++++++++++++-
> .../boot/dts/altera/socfpga_stratix10_socdk.dts | 42 +++++++++++++
> 2 files changed, 111 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18, part 2
From: Dinh Nguyen @ 2018-06-05 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514135144.26872-1-dinguyen@kernel.org>
Hi Arnd, Kevin and Olof:
Perhaps this pull request got buried in your inbox somewhere? Can you
still pull these in for v4.18?
Thanks,
Dinh
On 05/14/2018 08:51 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in more updates for SoCFPGA Stratix10 DTS for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git socfpga_for_next_v4.18_dts_v2
>
> for you to fetch changes up to 91fdd8274f32987760bbdb2981b4a896e338c09e:
>
> arm64: dts: stratix10: add sdram ecc (2018-05-08 08:11:29 -0500)
>
> ----------------------------------------------------------------
> Bartosz Golaszewski (1):
> ARM: dts: consistently use 'atmel' as at24 manufacturer in cyclone5
>
> Ooi, Joyce (1):
> arm64: dts: stratix10: Change pad skew values for EMAC0 PHY driver
>
> Thor Thayer (1):
> arm64: dts: stratix10: add sdram ecc
>
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++---
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
^ 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