* [PATCH v2] ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it
From: Srinivas Kandagatla @ 2018-06-04 11:13 UTC (permalink / raw)
To: linux-arm-kernel
dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
paths pointer dangling in the list.
This leads to system crash when we try to unload and reload sound card.
I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
Without this patch, on SLAB Poisoning enabled build, kernel crashes with
"BUG kmalloc-128 (Tainted: G W ): Poison overwritten"
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Changes since v1:
-remove unnecessary very long bug trace.
sound/soc/soc-dapm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 1e9a36389667..36a39ba30226 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -433,6 +433,8 @@ static int dapm_kcontrol_data_alloc(struct snd_soc_dapm_widget *widget,
static void dapm_kcontrol_free(struct snd_kcontrol *kctl)
{
struct dapm_kcontrol_data *data = snd_kcontrol_chip(kctl);
+
+ list_del(&data->paths);
kfree(data->wlist);
kfree(data);
}
--
2.16.2
^ permalink raw reply related
* [PATCH 1/7] iommu/dma: fix trival coding style mistake
From: Leizhen (ThunderTown) @ 2018-06-04 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b473059d-fee6-1627-4749-192771038741@arm.com>
On 2018/5/31 21:03, Robin Murphy wrote:
> On 31/05/18 08:42, Zhen Lei wrote:
>> The static function iova_reserve_iommu_regions is only called by function
>> iommu_dma_init_domain, and the 'if (!dev)' check in iommu_dma_init_domain
>> affect it only, so we can safely move the check into it. I think it looks
>> more natural.
>
> As before, I disagree - the logic of iommu_dma_init_domain() is "we expect to have a valid device, but stop here if we don't", and moving the check just needlessly obfuscates that. It is not a coincidence that the arguments of both functions are in effective order of importance.
OK
>
>> In addition, the local variable 'ret' is only assigned in the branch of
>> 'if (region->type == IOMMU_RESV_MSI)', so the 'if (ret)' should also only
>> take effect in the branch, add a brace to enclose it.
>
> 'ret' is clearly also assigned at its declaration, to cover the (very likely) case where we don't enter the loop at all. Thus testing it in the loop is harmless, and cluttering that up with extra tabs and braces is just noise.
OK, I will drop this patch in v2
>
> Robin.
>
>> No functional changes.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> drivers/iommu/dma-iommu.c | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index ddcbbdb..4e885f7 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -231,6 +231,9 @@ static int iova_reserve_iommu_regions(struct device *dev,
>> LIST_HEAD(resv_regions);
>> int ret = 0;
>> + if (!dev)
>> + return 0;
>> +
>> if (dev_is_pci(dev))
>> iova_reserve_pci_windows(to_pci_dev(dev), iovad);
>> @@ -246,11 +249,12 @@ static int iova_reserve_iommu_regions(struct device *dev,
>> hi = iova_pfn(iovad, region->start + region->length - 1);
>> reserve_iova(iovad, lo, hi);
>> - if (region->type == IOMMU_RESV_MSI)
>> + if (region->type == IOMMU_RESV_MSI) {
>> ret = cookie_init_hw_msi_region(cookie, region->start,
>> region->start + region->length);
>> - if (ret)
>> - break;
>> + if (ret)
>> + break;
>> + }
>> }
>> iommu_put_resv_regions(dev, &resv_regions);
>> @@ -308,8 +312,6 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> }
>> init_iova_domain(iovad, 1UL << order, base_pfn);
>> - if (!dev)
>> - return 0;
>> return iova_reserve_iommu_regions(dev, domain);
>> }
>>
>
> .
>
--
Thanks!
BestRegards
^ permalink raw reply
* [PATCH] ASoC: dapm: delete dapm_kcontrol_data paths entry before freeing
From: Mark Brown @ 2018-06-04 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e37bf559-b040-db34-6273-d4f8ea1e2284@linaro.org>
On Mon, Jun 04, 2018 at 11:55:10AM +0100, Srinivas Kandagatla wrote:
> I agree, Do you want me to resend the patch removing irrelevant sections in
> log?
I didn't actually apply yet so yes please.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180604/a71b3ace/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ASoC: dapm: delete dapm_kcontrol_data paths entry before freeing
From: Srinivas Kandagatla @ 2018-06-04 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604104541.GB7536@sirena.org.uk>
On 04/06/18 11:45, Mark Brown wrote:
> On Fri, Jun 01, 2018 at 11:53:34PM +0100, Srinivas Kandagatla wrote:
>
>> Below is the kernel BUG with SLAB Poisoning
>
>> =============================================================================
>> BUG kmalloc-128 (Tainted: G W ): Poison overwritten
>> -----------------------------------------------------------------------------
>>
>> Disabling lock debugging due to kernel taint
>> INFO: 0xffff80003cf1c310-0xffff80003cf1c31f. First byte 0x10 instead of 0x6b
>> INFO: Allocated in dapm_kcontrol_data_alloc.isra.37+0x34/0x2a8 age=6929 cpu=0 pid=50
>> __slab_alloc.isra.24+0x24/0x38
>> kmem_cache_alloc+0x190/0x1d8
>
> Please think hard before including complete backtraces in upstream
> reports, they are very large and contain almost no useful information
> relative to their size so often obscure the relevant content in your
> message. If part of the backtrace is usefully illustrative then it's
> usually better to pull out the relevant sections.
I agree, Do you want me to resend the patch removing irrelevant sections
in log?
thanks,
srini
>
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Mark Brown @ 2018-06-04 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2564792.sYBGPVz9u3@z50>
On Fri, Jun 01, 2018 at 12:49:53AM +0200, Janusz Krzysztofik wrote:
> I confirm the fix by Stephen works for me, however, the conflicting patch by
> Linus breaks things a bit.
> Lookup tables added to board files use function name "enable" while the
> regulator uses NULL. As a result, GPIO descriptor is not matched and not
> assigned to the regulator which ends up running with no control over GPIO pin.
> Either the regulator driver should use the function name "enable" or that name
> should be removed from lookup tables.
I'll revert this one as well :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180604/ab8c1fa9/attachment.sig>
^ permalink raw reply
* [PATCH] ASoC: dapm: delete dapm_kcontrol_data paths entry before freeing
From: Mark Brown @ 2018-06-04 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601225334.19064-1-srinivas.kandagatla@linaro.org>
On Fri, Jun 01, 2018 at 11:53:34PM +0100, Srinivas Kandagatla wrote:
> Below is the kernel BUG with SLAB Poisoning
> =============================================================================
> BUG kmalloc-128 (Tainted: G W ): Poison overwritten
> -----------------------------------------------------------------------------
>
> Disabling lock debugging due to kernel taint
> INFO: 0xffff80003cf1c310-0xffff80003cf1c31f. First byte 0x10 instead of 0x6b
> INFO: Allocated in dapm_kcontrol_data_alloc.isra.37+0x34/0x2a8 age=6929 cpu=0 pid=50
> __slab_alloc.isra.24+0x24/0x38
> kmem_cache_alloc+0x190/0x1d8
Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180604/2726e3d4/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] arm64: topology: rename llc_siblings to align with other struct members
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
Similar to core_sibling and thread_sibling, it's better to align and
rename llc_siblings to llc_sibling.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 2 +-
arch/arm64/kernel/topology.c | 12 ++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index fb996f454305..dda4b6dba6b4 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -11,7 +11,7 @@ struct cpu_topology {
int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_siblings;
+ cpumask_t llc_sibling;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index bf522bcf40ec..082f76f7a94d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -223,8 +223,8 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
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;
+ if (cpumask_subset(&cpu_topology[cpu].llc_sibling, core_mask))
+ core_mask = &cpu_topology[cpu].llc_sibling;
}
return core_mask;
@@ -240,7 +240,7 @@ static void update_siblings_masks(unsigned int cpuid)
cpu_topo = &cpu_topology[cpu];
if (cpuid_topo->llc_id == cpu_topo->llc_id)
- cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+ cpumask_set_cpu(cpu, &cpuid_topo->llc_sibling);
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -305,13 +305,13 @@ static void clear_cpu_topology(int cpu, bool reset)
cpu_topo->package_id = -1;
cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->llc_sibling);
cpumask_clear(&cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
if (reset) {
cpu_topo->core_id = 0;
- cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->llc_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
}
@@ -325,7 +325,7 @@ static void __init reset_cpu_topology(void)
clear_cpu_topology(cpu, true);
}
-#define cpu_llc_shared_mask(cpu) (&cpu_topology[cpu].llc_siblings)
+#define cpu_llc_shared_mask(cpu) (&cpu_topology[cpu].llc_sibling)
void remove_cpu_topology(unsigned int cpu)
{
int sibling;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] arm64: smp: remove cpu and numa topology information when hotplugging out CPU
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
We already repopulate the information on CPU hotplug-in, so we can safely
remove the CPU topology and NUMA cpumap information during CPU hotplug
out operation. This will help to provide the correct cpumask for
scheduler domains.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/smp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 49a021e30dfb..63a40ba3cd37 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -279,6 +279,9 @@ int __cpu_disable(void)
if (ret)
return ret;
+ remove_cpu_topology(cpu);
+ numa_remove_cpu(cpu);
+
/*
* Take this CPU offline. Once we clear this, we can't return,
* and we must not schedule until we're ready to give up the cpu.
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] arm64: numa: separate out updates to percpu nodeid and NUMA node cpumap
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
Currently numa_clear_node removes both cpu information from the NUMA
node cpumap as well as the NUMA node id from the cpu. Similarly
numa_store_cpu_info updates both percpu nodeid and NUMA cpumap.
However we need to retain the numa node id for the cpu and only remove
the cpu information from the numa node cpumap during CPU hotplug out.
The same can be extended for hotplugging in the CPU.
This patch separates out numa_{add,remove}_cpu from numa_clear_node and
numa_store_cpu_info.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/numa.h | 4 ++++
arch/arm64/kernel/smp.c | 2 ++
arch/arm64/mm/numa.c | 29 +++++++++++++++++++++--------
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 01bc46d5b43a..626ad01e83bf 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -35,10 +35,14 @@ void __init numa_set_distance(int from, int to, int distance);
void __init numa_free_distance(void);
void __init early_map_cpu_to_node(unsigned int cpu, int nid);
void numa_store_cpu_info(unsigned int cpu);
+void numa_add_cpu(unsigned int cpu);
+void numa_remove_cpu(unsigned int cpu);
#else /* CONFIG_NUMA */
static inline void numa_store_cpu_info(unsigned int cpu) { }
+static inline void numa_add_cpu(unsigned int cpu) { }
+static inline void numa_remove_cpu(unsigned int cpu) { }
static inline void arm64_numa_init(void) { }
static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..49a021e30dfb 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -225,6 +225,7 @@ asmlinkage void secondary_start_kernel(void)
notify_cpu_starting(cpu);
store_cpu_topology(cpu);
+ numa_add_cpu(cpu);
/*
* OK, now it's safe to let the boot CPU continue. Wait for
@@ -679,6 +680,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
this_cpu = smp_processor_id();
store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ numa_add_cpu(this_cpu);
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"), don't set
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..43cc669bc7bc 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -70,19 +70,32 @@ EXPORT_SYMBOL(cpumask_of_node);
#endif
-static void map_cpu_to_node(unsigned int cpu, int nid)
+static void numa_update_cpu(unsigned int cpu, bool remove)
{
- set_cpu_numa_node(cpu, nid);
- if (nid >= 0)
+ int nid = cpu_to_node(cpu);
+
+ if (nid < 0)
+ return;
+
+ if (remove)
+ cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
+ else
cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
}
-void numa_clear_node(unsigned int cpu)
+void numa_add_cpu(unsigned int cpu)
{
- int nid = cpu_to_node(cpu);
+ numa_update_cpu(cpu, false);
+}
- if (nid >= 0)
- cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
+void numa_remove_cpu(unsigned int cpu)
+{
+ numa_update_cpu(cpu, true);
+}
+
+void numa_clear_node(unsigned int cpu)
+{
+ numa_remove_cpu(cpu);
set_cpu_numa_node(cpu, NUMA_NO_NODE);
}
@@ -116,7 +129,7 @@ static void __init setup_node_to_cpumask_map(void)
*/
void numa_store_cpu_info(unsigned int cpu)
{
- map_cpu_to_node(cpu, cpu_to_node_map[cpu]);
+ set_cpu_numa_node(cpu, cpu_to_node_map[cpu]);
}
void __init early_map_cpu_to_node(unsigned int cpu, int nid)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] arm64: topology: add support to remove cpu topology
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
This patch adds support to remove all the CPU topology information using
clear_cpu_topology and also resetting the sibling information on other
sibling CPUs. This will be used in cpu_disable so that all the topology
information is removed on CPU hotplug out.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 1 +
arch/arm64/kernel/topology.c | 15 +++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index df48212f767b..fb996f454305 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -23,6 +23,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
void init_cpu_topology(void);
void store_cpu_topology(unsigned int cpuid);
+void remove_cpu_topology(unsigned int cpuid);
const struct cpumask *cpu_coregroup_mask(int cpu);
#ifdef CONFIG_NUMA
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index f10babcc112b..bf522bcf40ec 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -325,6 +325,21 @@ static void __init reset_cpu_topology(void)
clear_cpu_topology(cpu, true);
}
+#define cpu_llc_shared_mask(cpu) (&cpu_topology[cpu].llc_siblings)
+void remove_cpu_topology(unsigned int cpu)
+{
+ int sibling;
+
+ for_each_cpu(sibling, topology_core_cpumask(cpu))
+ cpumask_clear_cpu(cpu, topology_core_cpumask(sibling));
+ for_each_cpu(sibling, topology_sibling_cpumask(cpu))
+ cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
+ for_each_cpu(sibling, cpu_llc_shared_mask(cpu))
+ cpumask_clear_cpu(cpu, cpu_llc_shared_mask(sibling));
+
+ clear_cpu_topology(cpu, false);
+}
+
#ifdef CONFIG_ACPI
/*
* Propagate the topology information of the processor_topology_node tree to the
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] arm64: topology: refactor reset_cpu_topology to add support for removing topology
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
Currently reset_cpu_topology clears all the CPU topology information
and resets to default values. However we may need to just clear the
information when we hotplig out the CPU. In preparation to add the
support the same, let's refactor reset_cpu_topology to clear out the
information and reset them only if explicitly requested.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/topology.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..f10babcc112b 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -296,28 +296,35 @@ void store_cpu_topology(unsigned int cpuid)
update_siblings_masks(cpuid);
}
-static void __init reset_cpu_topology(void)
+static void clear_cpu_topology(int cpu, bool reset)
{
- unsigned int cpu;
+ struct cpu_topology *cpu_topo = &cpu_topology[cpu];
- for_each_possible_cpu(cpu) {
- struct cpu_topology *cpu_topo = &cpu_topology[cpu];
+ cpu_topo->core_id = -1;
+ cpu_topo->thread_id = -1;
+ cpu_topo->package_id = -1;
+ cpu_topo->llc_id = -1;
- cpu_topo->thread_id = -1;
- cpu_topo->core_id = 0;
- cpu_topo->package_id = -1;
+ cpumask_clear(&cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->core_sibling);
+ cpumask_clear(&cpu_topo->thread_sibling);
- cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
+ if (reset) {
+ cpu_topo->core_id = 0;
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
-
- cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
- cpumask_clear(&cpu_topo->thread_sibling);
cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
}
}
+static void __init reset_cpu_topology(void)
+{
+ unsigned int cpu;
+
+ for_each_possible_cpu(cpu)
+ clear_cpu_topology(cpu, true);
+}
+
#ifdef CONFIG_ACPI
/*
* Propagate the topology information of the processor_topology_node tree to the
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] arm64: numa/topology/smp: fix the cpumasks for CPU hotplug
From: Sudeep Holla @ 2018-06-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will, Catalin, Jeremy, Morten,
This is the fix I could come up for the issues we are seeing with arm64
for-next branch, in particular with commit 37c3ec2d810f ("arm64: topology:
divorce MC scheduling domain from core_siblings").
The solution is to update the CPU topology during CPU hotplug operations
similar to other architectures like x86 and PPC. This is also inline
with the expection from the scheduler.
I have cc-ed few Cavium and Huawei guys as they seem to have added or
modified the numa related code in the past.
Regards,
Sudeep
Sudeep Holla (5):
arm64: topology: refactor reset_cpu_topology to add support for removing topology
arm64: topology: add support to remove cpu topology
arm64: numa: separate out updates to percpu nodeid and NUMA node cpumap
arm64: smp: remove cpu and numa topology information when hotplugging out CPU
arm64: topology: rename llc_siblings to align with other struct members
arch/arm64/include/asm/numa.h | 4 +++
arch/arm64/include/asm/topology.h | 3 ++-
arch/arm64/kernel/smp.c | 5 ++++
arch/arm64/kernel/topology.c | 54 +++++++++++++++++++++++++++------------
arch/arm64/mm/numa.c | 29 +++++++++++++++------
5 files changed, 70 insertions(+), 25 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC PATCH 2/8] coresight: Fix remote endpoint parsing
From: Suzuki K Poulose @ 2018-06-04 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzY-1z4NBmZECczMisDixgPb2UkJL0k9_LmDNEiqUS1=g@mail.gmail.com>
On 06/01/2018 08:46 PM, Mathieu Poirier wrote:
> On 1 June 2018 at 13:38, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> On Fri, Jun 01, 2018 at 02:16:01PM +0100, Suzuki K Poulose wrote:
>>> When parsing the remote endpoint of an output port, we do :
>>> rport = of_graph_get_remote_port(ep);
>>> rparent = of_graph_get_remote_port_parent(ep);
>>>
>>> and then parse the "remote_port" as if it was the remote endpoint,
>>> which is wrong. The code worked fine because we used endpoint number
>>> as the port number. Let us fix it and optimise a bit as:
>>>
>>> remote_ep = of_graph_get_remote_endpoint(ep);
>>> if (remote_ep)
>>> remote_parent = of_graph_get_port_parent(remote_ep);
>>>
>>> and then, parse the remote_ep for the port/endpoint details.
>>>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> drivers/hwtracing/coresight/of_coresight.c | 19 ++++++++++---------
>>> 1 file changed, 10 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
>>> index 7c37544..e0deab0 100644
>>> --- a/drivers/hwtracing/coresight/of_coresight.c
>>> +++ b/drivers/hwtracing/coresight/of_coresight.c
>>> @@ -128,7 +128,7 @@ of_get_coresight_platform_data(struct device *dev,
>>> struct device *rdev;
>>> struct device_node *ep = NULL;
>>> struct device_node *rparent = NULL;
>>> - struct device_node *rport = NULL;
>>> + struct device_node *rep = NULL;
>>>
>>> pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>> if (!pdata)
>>> @@ -169,16 +169,17 @@ of_get_coresight_platform_data(struct device *dev,
>>> pdata->outports[i] = endpoint.port;
>>>
>>> /*
>>> - * Get a handle on the remote port and parent
>>> - * attached to it.
>>> + * Get a handle on the remote endpoint and the device
>>> + * it is attached to.
>>> */
>>> - rparent = of_graph_get_remote_port_parent(ep);
>>> - rport = of_graph_get_remote_port(ep);
>>> -
>>> - if (!rparent || !rport)
>>> + rep = of_graph_get_remote_endpoint(ep);
>>> + if (!rep)
>>> + continue;
>>> + rparent = of_graph_get_port_parent(rep);
>>> + if (!rparent)
>>> continue;
>>>
>>> - if (of_graph_parse_endpoint(rport, &rendpoint))
>>> + if (of_graph_parse_endpoint(rep, &rendpoint))
>>> continue;
>>
>> You are correct and I'm out to lunch.
>>
>>>
>>> rdev = of_coresight_get_endpoint_device(rparent);
>>> @@ -186,7 +187,7 @@ of_get_coresight_platform_data(struct device *dev,
>>> return ERR_PTR(-EPROBE_DEFER);
>>>
>>> pdata->child_names[i] = dev_name(rdev);
>>> - pdata->child_ports[i] = rendpoint.id;
>>> + pdata->child_ports[i] = rendpoint.port;
>>
>> You need to do a of_node_put() here for both rep and rparent.
>
> Same thing for the "continue" and error condition above.
Mathieu,
Thanks for pointing that out. I see that we were missing them for the
existing code as well. I will clean all this up.
Cheers
Suzuki
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a77980: add GPIO support
From: Simon Horman @ 2018-06-04 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3c195d53-be0f-ad15-92e6-8ba43b14f076@cogentembedded.com>
On Fri, Jun 01, 2018 at 11:44:46PM +0300, Sergei Shtylyov wrote:
> Describe all 6 GPIO controllers in the R8A77980 device tree.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: v3hsk: specify GEther PHY IRQ
From: Simon Horman @ 2018-06-04 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e6c40eb-71d0-d35b-1cf7-9179e093ed10@cogentembedded.com>
On Fri, Jun 01, 2018 at 11:47:14PM +0300, Sergei Shtylyov wrote:
> Specify GEther PHY IRQ in the V3H Starter Kit board's device tree, now
> that we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
and the previous one.
Other than that, this patch looks good to me.
^ permalink raw reply
* [PATCH v12 0/5] Fix issues with huge mapping in ioremap for ARM64
From: Will Deacon @ 2018-06-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1a648674-da56-6664-bf3c-0cdf825ad1e3@codeaurora.org>
Hi Chintan,
On Mon, Jun 04, 2018 at 11:26:28AM +0530, Chintan Pandya wrote:
> Just curious to know, is there anything that I should be addressing
> in these patches ? For now, I don't see anything from my side that
> requires modification, unless one has some more review comments on
> this.
>
> Status so far on and around this:
> - Status of Toshi's series of patches is still not clear to me.
> However, if this series can get through first, there won't
> be conflicting scenarios as far as arm64 is concerned.
> - I've rebased these patches on tip
> - Also re-tested these patches for long duration tests with
> 1 GB mapping case also exercised enough. Test ended positively.
I'll try to review this version today.
Will
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: condor: specify EtherAVB PHY IRQ
From: Simon Horman @ 2018-06-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21578b79-7ba0-b3a6-ae45-7e9ffbb7c8db@cogentembedded.com>
On Fri, Jun 01, 2018 at 11:45:55PM +0300, Sergei Shtylyov wrote:
> Specify EtherAVB PHY IRQ in the Condor board's device tree, now that
> we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> ===================================================================
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -59,6 +59,8 @@
> phy0: ethernet-phy at 0 {
> rxc-skew-ps = <1500>;
> reg = <0>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
I don't see this documented. Perhaps I'm missing something obvious.
Or you have some extra information or newer documentation?
Also, given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
and the following one.
> };
> };
>
>
^ permalink raw reply
* [PATCH v3 3/3] serial: xuartps: remove unnecessary register write
From: Helmut Grohne @ 2018-06-04 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528106392.git.h.grohne@intenta.de>
This writel writes the exact same value as the previous writel and is
thus unnecessary. It accidentally became unnecessary in e3538c37ee38
("tty: xuartps: Beautify read-modify writes"), but the new behaviour is
now expected.
Link: https://www.spinics.net/lists/linux-serial/msg23168.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
---
drivers/tty/serial/xilinx_uartps.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index a34b2c757593..7a2b1a7350ac 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1238,8 +1238,6 @@ static void cdns_uart_console_write(struct console *co, const char *s,
CDNS_UART_SR_TXEMPTY)
cpu_relax();
- writel(ctrl, port->membase + CDNS_UART_CR);
-
/* restore interrupt state */
writel(imr, port->membase + CDNS_UART_IER);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/3] serial: xuartps: reduce hardware TX race condition
From: Helmut Grohne @ 2018-06-04 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528106392.git.h.grohne@intenta.de>
After sending data to the uart, the driver was waiting until the TX
FIFO was empty (for every single char written). After that, TX was
disabled by writing the original TX state to the status register. At
that time however, the state machine could still be shifting
characters. Not waiting can result in strange hardware states,
especially when coupled with calls to cdns_uart_set_termios, whose
symptom generally is garbage characters being received from uart or a
hang.
According to UG585, the TACTIVE bit of the channel status register
indicates the shifter operation and we should be waiting for that bit
to clear.
Sending characters does not require the TX FIFO to be empty, but merely
to not be full. So cdns_uart_console_putchar is updated accordingly.
During tests with an instrumented kernel and an oscilloscope, we could
determine that the chance of a race is reduced by this patch. It is not
removed entirely. On the oscilloscope, one can see that disabling the
transmitter early can result in the transmission hanging in the middle
of a character for a tiny duration. This hiccup is enough to
desynchronize with a remote device for a sequence of characters until a
data bit doesn't match the start or stop bits anymore.
Link: https://www.spinics.net/lists/linux-serial/msg23156.html
Link: https://www.spinics.net/lists/linux-serial/msg26139.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
---
drivers/tty/serial/xilinx_uartps.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index e4b2d8102a04..a34b2c757593 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -167,6 +167,7 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
#define CDNS_UART_SR_TXEMPTY 0x00000008 /* TX FIFO empty */
#define CDNS_UART_SR_TXFULL 0x00000010 /* TX FIFO full */
#define CDNS_UART_SR_RXTRIG 0x00000001 /* Rx Trigger */
+#define CDNS_UART_SR_TACTIVE 0x00000800 /* TX state machine active */
/* baud dividers min/max values */
#define CDNS_UART_BDIV_MIN 4
@@ -1138,23 +1139,14 @@ static struct uart_port *cdns_uart_get_port(int id)
#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
/**
- * cdns_uart_console_wait_tx - Wait for the TX to be full
- * @port: Handle to the uart port structure
- */
-static void cdns_uart_console_wait_tx(struct uart_port *port)
-{
- while (!(readl(port->membase + CDNS_UART_SR) & CDNS_UART_SR_TXEMPTY))
- barrier();
-}
-
-/**
* cdns_uart_console_putchar - write the character to the FIFO buffer
* @port: Handle to the uart port structure
* @ch: Character to be written
*/
static void cdns_uart_console_putchar(struct uart_port *port, int ch)
{
- cdns_uart_console_wait_tx(port);
+ while (readl(port->membase + CDNS_UART_SR) & CDNS_UART_SR_TXFULL)
+ cpu_relax();
writel(ch, port->membase + CDNS_UART_FIFO);
}
@@ -1241,7 +1233,10 @@ static void cdns_uart_console_write(struct console *co, const char *s,
writel(ctrl, port->membase + CDNS_UART_CR);
uart_console_write(port, s, count, cdns_uart_console_putchar);
- cdns_uart_console_wait_tx(port);
+ while ((readl(port->membase + CDNS_UART_SR) &
+ (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE)) !=
+ CDNS_UART_SR_TXEMPTY)
+ cpu_relax();
writel(ctrl, port->membase + CDNS_UART_CR);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 1/3] serial: xuartps: fix typo in cdns_uart_startup
From: Helmut Grohne @ 2018-06-04 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528106392.git.h.grohne@intenta.de>
The bit mask changes in commit 6e14f7c1f2c2 ("tty: xuartps: Improve
startup function") doesn't do what the commit message advertises. The
original behaviour was clearing the RX_DIS bit, but due to missing ~,
that bit is now the only bit kept.
Currently, the regression is harmless, because the previous write to the
control register sets it to TXRST | RXRST. Thus the RX_DIS bit is
previously cleared. The *RST bits are cleared by the hardware, so this
commit does not currently change behaviour, but makes future changes
less risky.
Link: https://www.spinics.net/lists/linux-serial/msg23157.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Fixes: 6e14f7c1f2c2 ("tty: xuartps: Improve startup function")
Reviewed-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
---
drivers/tty/serial/xilinx_uartps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index bd72dd843338..e4b2d8102a04 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -829,7 +829,7 @@ static int cdns_uart_startup(struct uart_port *port)
* the receiver.
*/
status = readl(port->membase + CDNS_UART_CR);
- status &= CDNS_UART_CR_RX_DIS;
+ status &= ~CDNS_UART_CR_RX_DIS;
status |= CDNS_UART_CR_RX_EN;
writel(status, port->membase + CDNS_UART_CR);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/3] serial: xuartps: hardware race condition and cleanup
From: Helmut Grohne @ 2018-06-04 10:21 UTC (permalink / raw)
To: linux-arm-kernel
The character transmission in xuartps is racy. If the transmitter is disabled
early, the device is confused and produces a desync. Garbage on the remote end
can be a visible symptom. The second patch in this series tries to reduce that
race condition in accordance with the hardware documentation, but it cannot
remove it entirely. The first and third patches are code cleanup.
Changes since v2:
* Do not attempt to disable the transmitter after a transmission (original
behaviour around 3.14). These patches no longer touch with the transmitter
state at all as requested by S?ren Brinkmann.
* Add Acked-by/Reviewed-by tags from S?ren Brinkmann after addressing his
remarks.
Earlier patches/discussion at:
https://www.spinics.net/lists/linux-serial/msg23145.html
https://www.spinics.net/lists/linux-serial/msg23156.html
https://www.spinics.net/lists/linux-serial/msg23157.html
Helmut Grohne (3):
serial: xuartps: fix typo in cdns_uart_startup
serial: xuartps: reduce hardware TX race condition
serial: xuartps: remove unnecessary register write
drivers/tty/serial/xilinx_uartps.c | 23 ++++++++---------------
1 file changed, 8 insertions(+), 15 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stuebner @ 2018-06-04 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215114427.32059-1-klaus.goger@theobroma-systems.com>
Am Freitag, 15. Dezember 2017, 12:44:25 CEST schrieb Klaus Goger:
> This patch series replaces all the license text in rockchip devicetree
> files text with a proper SPDX-License-Identifier.
> It follows the guidelines submitted[1] by Thomas Gleixner that are not
> yet merged.
>
> These series also fixes the issue with contradicting statements in most
> licenses. The introduction text claims to be GPL or X11[2] but the
> following verbatim copy of the license is actually a MIT[3] license.
> The X11 license includes a advertise clause and trademark information
> related to the X Consortium. As these X Consortium specfic points are
> irrelevant for us we stick with the actuall license text.
>
> [1] https://patchwork.kernel.org/patch/10091607/
> [2] https://spdx.org/licenses/X11.html
> [3] https://spdx.org/licenses/MIT.html
>
>
> Klaus Goger (2):
> arm64: dts: rockchip: use SPDX-License-Identifier
> ARM: dts: rockchip: use SPDX-License-Identifier
This had now 6 months for anybody concerned about this change to speak
up - with no NACKs received, so I've applied both patches for 4.19
Heiko
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stuebner @ 2018-06-04 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WA44n8MYtGZTQN3r0F86E=xDcdWhQDLDOkyqS=aaCXfQ@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 18:29:02 CEST schrieb Doug Anderson:
> Hi,
>
> On Fri, Dec 15, 2017 at 3:44 AM, Klaus Goger
> <klaus.goger@theobroma-systems.com> wrote:
> > This patch series replaces all the license text in rockchip devicetree
> > files text with a proper SPDX-License-Identifier.
> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> > yet merged.
> >
> > These series also fixes the issue with contradicting statements in most
> > licenses. The introduction text claims to be GPL or X11[2] but the
> > following verbatim copy of the license is actually a MIT[3] license.
> > The X11 license includes a advertise clause and trademark information
> > related to the X Consortium. As these X Consortium specfic points are
> > irrelevant for us we stick with the actuall license text.
> >
> > [1] https://patchwork.kernel.org/patch/10091607/
> > [2] https://spdx.org/licenses/X11.html
> > [3] https://spdx.org/licenses/MIT.html
> >
> >
> > Klaus Goger (2):
> > arm64: dts: rockchip: use SPDX-License-Identifier
> > ARM: dts: rockchip: use SPDX-License-Identifier
> >
> > arch/arm/boot/dts/rk3036-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3036-kylin.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3036.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-marsboard.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-mk808.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-rayeager.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3188-px3-evb.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3188-radxarock.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3188.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3228-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3229-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3229.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk322x.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb-act8846.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb-rk808.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-fennec.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-firefly-beta.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly-reload.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-miqi.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-phycore-rdk.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-popmetal.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-r89.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-rock2-som.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-rock2-square.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-tinker.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi | 5 +--
> > arch/arm/boot/dts/rk3288-veyron-brain.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-mickey.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-minnie.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-vyasa.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3xxx.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rv1108-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rv1108.dtsi | 40 +---------------------
> > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 39 +--------------------
> > .../arm64/boot/dts/rockchip/rk3368-evb-act8846.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 39 +--------------------
> > .../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 39 +--------------------
> > .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 39 +--------------------
> > .../dts/rockchip/rk3399-sapphire-excavator.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 +--------------------
> > 69 files changed, 69 insertions(+), 2603 deletions(-)
>
> This is just removing the verbatim license text and adding a link to
> another file with the text? ...and correcting the name of the
> alternate license to be the MIT license... I'm no lawyer, but if
> that's what everyone in the kernel agrees is the way they want it
> going forward then I have no objections to anything I was involved in.
correct.
Documentation/process/license-rules.rst Describes the process of
handling these license identifiers.
There was one criticism in the beginning, that an arbitary third-party
site would hold the binding license texts, but that got resolved by
including LICENSES/preferred/$identifier into the kernel sources itself.
Heiko
^ permalink raw reply
* [PATCH 0/6] ARM: shmobile: rcar: Drop lehacy SYSC fallbacks
From: Simon Horman @ 2018-06-04 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693916-11215-1-git-send-email-geert+renesas@glider.be>
On Wed, May 30, 2018 at 05:25:10PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> When DT SYSC support was introduced in v4.7, legacy fallbacks were kept
> to keep secondary CPUs working on R-Car H1, H2, and M2-W using old DTBs.
> However, the time has come to drop these fallbacks, and clean up the
> resulting code.
>
> Most of this was written when I worked on DT SYSC support, but postponed
> until the time was ripe. So basically I've been running this during the
> last +2 years.
>
> I avoided touching drivers/soc/renesas and arch/arm/mach-shmobile code
> in the same patch. If you prefer some patches to be squashed, please
> let me know.
>
> Tested on Marzen (R-Car H1), Lager (R-Car H2), and Koelsch (R-Car M2-W).
>
> Thanks!
>
> Geert Uytterhoeven (6):
> ARM: shmobile: rcar-gen2: Remove explicit SYSC config and init
> ARM: shmobile: r8a7779: Stop powering down secondary CPUs during early
> boot
> soc: renesas: rcar-sysc: Provide helpers to power up/down CPUs
> ARM: shmobile: r8a7779: Use rcar_sysc_power_{down,up}_cpu()
> ARM: shmobile: r8a7779: Remove explicit SYSC config and init
> soc: renesas: rcar-sysc: Drop legacy handling
>
> arch/arm/mach-shmobile/Makefile | 2 +-
> arch/arm/mach-shmobile/pm-r8a7779.c | 41 ----------------------
> arch/arm/mach-shmobile/pm-rcar-gen2.c | 25 --------------
> arch/arm/mach-shmobile/r8a7779.h | 2 --
> arch/arm/mach-shmobile/smp-r8a7779.c | 54 ++++-------------------------
> drivers/soc/renesas/rcar-sysc.c | 64 ++++++++++++++++++++++-------------
> include/linux/soc/renesas/rcar-sysc.h | 13 ++-----
> 7 files changed, 50 insertions(+), 151 deletions(-)
> delete mode 100644 arch/arm/mach-shmobile/pm-r8a7779.c
Thanks, I have applied this and intend to push shortly.
I had a conflict in the Makefile when applying patch 5/6.
Please check to make sure I applied that patch correctly.
^ permalink raw reply
* [PATCH] KVM: arm64: VHE: Migrate _elx sysreg accessors to msr_s/mrs_s
From: Dave Martin @ 2018-06-04 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601094224.ctyvafybcnzys6f4@salmiak>
On Fri, Jun 01, 2018 at 10:42:24AM +0100, Mark Rutland wrote:
> Hi,
>
> On Tue, May 29, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> > Currently, the {read,write}_sysreg_el*() accessors for accessing
> > particular ELs' sysregs in the presence of VHE rely on some local
> > hacks and define their system register encodings in a way that is
> > inconsistent with the core definitions in <asm/sysreg.h>.
> >
> > As a result, it is necessary to add duplicate definitions for any
> > system register that already needs a definition in sysreg.h for
> > other reasons.
> >
> > This is a bit of a maintenance headache, and the reasons for the
> > _el*() accessors working the way they do is a bit historical.
> >
> > This patch gets rid of the shadow sysreg definitions in
> > <asm/kvm_hyp.h>, converts the _el*() accessors to use the core
> > msr_s/mrs_s interface, and converts all call sites to use the
> > standard sysreg #define names (i.e., upper case, with SYS_ prefix).
>
> Nice!
>
> [...]
>
> > static inline unsigned long vcpu_read_elr_el1(const struct kvm_vcpu *vcpu)
> > {
> > if (vcpu->arch.sysregs_loaded_on_cpu)
> > - return read_sysreg_el1(elr);
> > + return read_sysreg_el1(SYS_ELR);
>
> Could we have the macro implicitly handle the SYS_ prefix?
>
> A further bit of cleanup that I'd like to do is make {read,write}_sysreg() use
> {mrs,msr}_s, implicitly handling the SYS_ prefix, so that we can kill off
> {read,write}_sysreg_s(), and always use a {read,write}_sysreg().
>
> A minor pain point is that we'd have to convert callers to pass the sysreg name
> in upper-case, but that conversion can be scripted fairly easily.
>
> e.g. for the above, read_sysreg() would take ELR_EL1, and read_sysreg_el1()
> would take ELR.
Ideally yes.
I will bear that in mind for the next iteration, but I hadn't figured
out how to solve the whole problem yet. I'll see if I can push a bit
further in that direction.
Cheers
---Dave
^ 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