* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Andrea Adami @ 2018-01-04 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104171637.GP28752@n2100.armlinux.org.uk>
On Thu, Jan 4, 2018 at 6:16 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Jan 04, 2018 at 06:02:38PM +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> I'm pretty sure it has already been reported, but just in case: I'm
>> testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
>> mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
>> Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
>> boot at all when built with gcc 7.2 (Fedora toolchain). Even when
>> configured and booted with earlyprintk, the kernel doesn't say anything.
>>
>> The toolchain being used is the default ARM toolchain provided by
>> Fedora 27. It says:
>>
>> gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
>> GNU ld version 2.29.1-1.fc27
>>
>> So it's quite bleeding edge.
>>
>> Let me know if this has already been fixed, or if I should test a
>> patch. I have not tested 4.15-rc or next at this point, assuming that
>> if a fix had been made, it would have been backported to 4.14-stable.
>
> It's a known issue -
>
> http://archive.armlinux.org.uk/lurker/message/20171018.095713.a56a717b.en.html
>
> but so far no patches have been forthcoming for the kernel, because
> (I guess) it's deemed to be a gcc bug.
>
> It's one of those discussions that just seemed to die without any
> real conclusion.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I am happy to report the gcc bug has been fixed in trunk.
I am as well dubious where they say this should also fix gcc6 where we
have no known issues with gcc6.
"
This should also fix
incorrect generation of ldrd/strd with unaligned accesses that could
previously have occurred on ARMv5e where all such operations must be
64-bit aligned."
https://github.com/gcc-mirror/gcc/commit/f59996b56aaa1c1d62a16cbb4010775b624cbde0
In OpenEmbedded we backported the patch a while ago, see the
discussion about qemu booting where real hw doesn't:
http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144045.html
Regards
Andrea
^ permalink raw reply
* [PATCH] arm64: fpsimd: Fix state leakage when migrating after sigreturn
From: Catalin Marinas @ 2018-01-04 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513362878-8787-1-git-send-email-Dave.Martin@arm.com>
On Fri, Dec 15, 2017 at 06:34:38PM +0000, Dave P Martin wrote:
> When refactoring the sigreturn code to handle SVE, I changed the
> sigreturn implementation to store the new FPSIMD state from the
> user sigframe into task_struct before reloading the state into the
> CPU regs. This makes it easier to convert the data for SVE when
> needed.
>
> However, it turns out that the fpsimd_state structure passed into
> fpsimd_update_current_state is not fully initialised, so assigning
> the structure as a whole corrupts current->thread.fpsimd_state.cpu
> with uninitialised data.
>
> This means that if the garbage data written to .cpu happens to be a
> valid cpu number, and the task is subsequently migrated to the cpu
> identified by the that number, and then tries to enter userspace,
> the CPU FPSIMD regs will be assumed to be correct for the task and
> not reloaded as they should be. This can result in returning to
> userspace with the FPSIMD registers containing data that is stale or
> that belongs to another task or to the kernel.
>
> Knowingly handing around a kernel structure that is incompletely
> initialised with user data is a potential source of mistakes,
> especially across source file boundaries. To help avoid a repeat
> of this issue, this patch adapts the relevant internal API to hand
> around the user-accessible subset only: struct user_fpsimd_state.
>
> To avoid future surprises, this patch also converts all uses of
> struct fpsimd_state that really only access the user subset, to use
> struct user_fpsimd_state. A few missing consts are added to
> function prototypes for good measure.
>
> Thanks to Will for spotting the cause of the bug here.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support")
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I've queued this patch for 4.16 but do we actually need "Fixes:" here?
AFAICT, mainline already has the fix, the latest being a45448313706
"arm64: fpsimd: Fix copying of FP state from signal frame into task
struct" in -rc4 (for-next/core is based on -rc3).
--
Catalin
^ permalink raw reply
* [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management
From: Lorenzo Pieralisi @ 2018-01-04 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104145838.qk5sbtg3vjg33txt@flea.lan>
On Thu, Jan 04, 2018 at 03:58:38PM +0100, Maxime Ripard wrote:
> On Thu, Jan 04, 2018 at 10:37:46PM +0800, Chen-Yu Tsai wrote:
> > This is v2 of my sun9i SMP support with MCPM series which was started
> > over two years ago [1]. We've tried to implement PSCI for both the A80
> > and A83T. Results were not promising. The issue is that these two chips
> > have a broken security extensions implementation. If a specific bit is
> > not burned in its e-fuse, most if not all security protections don't
> > work [2]. Even worse, non-secure access to the GIC become secure. This
> > requires a crazy workaround in the GIC driver which probably doesn't work
> > in all cases [3].
> >
> > Nicolas mentioned that the MCPM framework is likely overkill in our
> > case [4]. However the framework does provide cluster/core state tracking
> > and proper sequencing of cache related operations. We could rework
> > the code to use standard smp_ops, but I would like to actually get
> > a working version in first.
> >
> > Much of the sunxi-specific MCPM code is derived from Allwinner code and
> > documentation, with some references to the other MCPM implementations,
> > as well as the Cortex's Technical Reference Manuals for the power
> > sequencing info.
> >
> > One major difference compared to other platforms is we currently do not
> > have a standalone PMU or other embedded firmware to do the actually power
> > sequencing. All power/reset control is done by the kernel. Nicolas
> > mentioned that a new optional callback should be added in cases where the
> > kernel has to do the actual power down [5]. For now however I'm using a
> > dedicated single thread workqueue. CPU and cluster power off work is
> > queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
> > is somewhat heavy, as I have a total of 10 static work structs. It might
> > also be a bit racy, as nothing prevents the system from bringing a core
> > back before the asynchronous work shuts it down. This would likely
> > happen under a heavily loaded system with a scheduler that brings cores
> > in and out of the system frequently. In simple use-cases it performs OK.
>
> It all looks sane to me
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
It does not to me, sorry. You do not need MCPM (and workqueues) to
do SMP bring-up.
Nico explained why, just do it:
commit 905cdf9dda5d ("ARM: hisi/hip04: remove the MCPM overhead")
Lorenzo
^ permalink raw reply
* [PATCH] arm: asid: Do not replace active_asids if already 0
From: Catalin Marinas @ 2018-01-04 18:04 UTC (permalink / raw)
To: linux-arm-kernel
Under some uncommon timing conditions, a generation check and
xchg(active_asids, A1) in check_and_switch_context() on P1 can race with
an ASID roll-over on P2. If P2 has not seen the update to
active_asids[P1], it can re-allocate A1 to a new task T2 on P2. P1 ends
up waiting on the spinlock since the xchg() returned 0 while P2 can go
through a second ASID roll-over with (T2,A1,G2) active on P2. This
roll-over copies active_asids[P1] == A1,G1 into reserved_asids[P1] and
active_asids[P2] == A1,G2 into reserved_asids[P2]. A subsequent
scheduling of T1 on P1 and T2 on P2 would match reserved_asids and get
their generation bumped to G3:
P1 P2
-- --
TTBR0.BADDR = T0
TTBR0.ASID = A0
asid_generation = G1
check_and_switch_context(T1,A1,G1)
generation match
check_and_switch_context(T2,A0,G0)
new_context()
ASID roll-over
asid_generation = G2
flush_context()
active_asids[P1] = 0
asid_map[A1] = 0
reserved_asids[P1] = A0,G0
xchg(active_asids, A1)
active_asids[P1] = A1,G1
xchg returns 0
spin_lock_irqsave()
allocated ASID (T2,A1,G2)
asid_map[A1] = 1
active_asids[P2] = A1,G2
...
check_and_switch_context(T3,A0,G0)
new_context()
ASID roll-over
asid_generation = G3
flush_context()
active_asids[P1] = 0
asid_map[A1] = 1
reserved_asids[P1] = A1,G1
reserved_asids[P2] = A1,G2
allocated ASID (T3,A2,G3)
asid_map[A2] = 1
active_asids[P2] = A2,G3
new_context()
check_update_reserved_asid(A1,G1)
matches reserved_asid[P1]
reserved_asid[P1] = A1,G3
updated T1 ASID to (T1,A1,G3)
check_and_switch_context(T2,A1,G2)
new_context()
check_and_switch_context(A1,G2)
matches reserved_asids[P2]
reserved_asids[P2] = A1,G3
updated T2 ASID to (T2,A1,G3)
At this point, we have two tasks, T1 and T2 both using ASID A1 with the
latest generation G3. Any of them is allowed to be scheduled on the
other CPU leading to two different tasks with the same ASID on the same
CPU.
This patch changes the xchg to cmpxchg so that the active_asids is only
updated if non-zero to avoid a race with an ASID roll-over on a
different CPU.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
This is similar to the arm64 patch [1], with the difference that non-relaxed
(cmp)xchg is used as per the existing code.
[1] http://lkml.kernel.org/r/20180104111721.33834-1-catalin.marinas at arm.com
arch/arm/mm/context.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index c8c8b9ed02e0..3208319d72e7 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -241,7 +241,7 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk)
{
unsigned long flags;
unsigned int cpu = smp_processor_id();
- u64 asid;
+ u64 asid, old_active_asid;
if (unlikely(mm->context.vmalloc_seq != init_mm.context.vmalloc_seq))
__check_vmalloc_seq(mm);
@@ -254,8 +254,17 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk)
cpu_set_reserved_ttbr0();
asid = atomic64_read(&mm->context.id);
- if (!((asid ^ atomic64_read(&asid_generation)) >> ASID_BITS)
- && atomic64_xchg(&per_cpu(active_asids, cpu), asid))
+
+ /*
+ * If our active_asids is zero, we are racing with an ASID roll-over
+ * on a different CPU, so skip the update (using cmpxchg if non-zero)
+ * and take the slow path.
+ */
+ old_active_asid = atomic64_read(&per_cpu(active_asids, cpu));
+ if (old_active_asid &&
+ !((asid ^ atomic64_read(&asid_generation)) >> ASID_BITS) &&
+ atomic64_cmpxchg(&per_cpu(active_asids, cpu),
+ old_active_asid, asid))
goto switch_mm_fastpath;
raw_spin_lock_irqsave(&cpu_asid_lock, flags);
^ permalink raw reply related
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Jeremy Linton @ 2018-01-04 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e59f197d-eff9-9429-6e3b-519aeac354fc@huawei.com>
Hi,
On 01/03/2018 09:59 PM, Xiongfeng Wang wrote:
>
>
> On 2018/1/4 1:32, Jeremy Linton wrote:
>> Hi,
>>
>> On 01/03/2018 08:29 AM, Sudeep Holla wrote:
>>>
>>> On 02/01/18 02:29, Xiongfeng Wang wrote:
>>>> Hi,
>>>>
>>>> On 2017/12/18 20:42, Morten Rasmussen wrote:
>>>>> On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
>>>>>>> [+Morten, Dietmar]
>>>>>>>
>>>>>>> $SUBJECT should be:
>>>>>>>
>>>>>>> arm64: topology: rename cluster_id
>>>>>>
>>>> [cut]
>>>>>>
>>>> I think we still need the information describing which cores are in one
>>>> cluster. Many arm64 chips have the architecture core/cluster/socket. Cores
>>>> in one cluster may share a same L2 cache. That information can be used to
>>>> build the sched_domain. If we put cores in one cluster in one sched_domain,
>>>> the performance will be better.(please see kernel/sched/topology.c:1197,
>>>> cpu_coregroup_mask() uses 'core_sibling' to build a multi-core
>>>> sched_domain).
>>>
>>> We get all the cache information from DT/ACPI PPTT(mainly topology) and now
>>> even the geometry. So ideally, the sharing information must come from that.
>>> Any other solution might end up in conflict if DT/PPTT and that mismatch.
>>>
>>>> So I think we still need variable to record which cores are in one
>>>> sched_domain for future use.
>>>
>>> I tend to say no, at-least not as is.
>>>
>>
>> Well, either way, with DynamiQ (and a55/a75) the cores have private L2's, which means that the cluster sharing is happening at what is then the L3 level. So, the code I had in earlier versions would have needed tweaks to deal with that anyway.
>>
>> IMHO, if we want to detect this kind of sharing for future scheduling domains, it should probably be done independent of PPTT/DT/MIPDR by picking out shared cache levels from struct cacheinfo *. Which makes that change unrelated to the basic population of cacheinfo and cpu_topology in this patchset.
>>
> I think we need to build scheduling domains not only on the cache-sharing information,
> but also some other information, such as which cores use the same cache coherent interconnect
> (I don't know the detail, I just guess)
>
> I think PPTT is used to report the cores topology, which cores are more related to each other.
> They may share the same cache, or use the same CCI, or are physically near to each other.
> I think we should use this information to build MC(multi-cores) scheduling domains.
>
> Or maybe we can just discard the MC scheduling domain and handle this scheduling-domain-building
> task to the NUMA subsystem entirely, I don't know if it is proper.
For the immediate future what I would like is a way to identify where in
the PPTT topology the NUMA domains begin (rather than assuming socket,
which is the current plan). That allows the manufactures of systems
(with say say MCM based topologies) to dictate at which level in the
cpu/cache topology they want to start describing the topology with the
SLIT/SRAT tables. I think that moves us in the direction you are
indicating while still leaving the door open for something like a
cluster level scheduling domain (based on cores sharing caches) or a
split LLC domain (also based on cores sharing caches) that happens to be
on die...
^ permalink raw reply
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: Jeremy Linton @ 2018-01-04 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <020801d38528$0ed8c670$2c8a5350$@codeaurora.org>
Hi,
On 01/04/2018 12:48 AM, vkilari at codeaurora.org wrote:
> Hi Jeremy
>
>> -----Original Message-----
>> From: linux-arm-kernel
> [mailto:linux-arm-kernel-bounces at lists.infradead.org]
>> On Behalf Of Jeremy Linton
>> Sent: Wednesday, January 3, 2018 10:28 PM
>> To: vkilari at codeaurora.org
>> Cc: 'Mark Rutland' <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
>> Jayachandran.Nair at cavium.com; 'Lorenzo Pieralisi'
>> <lorenzo.pieralisi@arm.com>; austinwc at codeaurora.org; 'Linux PM' <linux-
>> pm at vger.kernel.org>; jhugo at codeaurora.org; 'Catalin Marinas'
>> <catalin.marinas@arm.com>; 'Sudeep Holla' <sudeep.holla@arm.com>; 'Will
>> Deacon' <will.deacon@arm.com>; 'Linux Kernel Mailing List' <linux-
>> kernel at vger.kernel.org>; wangxiongfeng2 at huawei.com; 'ACPI Devel Maling
>> List' <linux-acpi@vger.kernel.org>; 'Viresh Kumar'
> <viresh.kumar@linaro.org>;
>> 'Rafael J. Wysocki' <rjw@rjwysocki.net>; 'Hanjun Guo'
>> <hanjun.guo@linaro.org>; 'Greg Kroah-Hartman'
>> <gregkh@linuxfoundation.org>; 'Rafael J. Wysocki' <rafael@kernel.org>; 'Al
>> Stone' <ahs3@redhat.com>; linux-arm-kernel at lists.infradead.org; 'Len
> Brown'
>> <lenb@kernel.org>
>> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
>>
>> Hi,
>>
>> On 01/03/2018 02:49 AM, vkilari at codeaurora.org wrote:
>>> Hi Jeremy,
>>>
>>> Sorry, I don't have your previous patch emails to reply on right
>>> patch context.
>>> So commenting on top of this patch.
>>>
>>> AFAIU, the PPTT v5 patches still rely on CLIDR_EL1 register to know
>>> the type of Caches enabled/available on the platform. With PPTT, it
>>> should not rely on architecture registers. There can be platforms
>>> which can report cache availability in PPTT but not in architecture
>>> registers.
>>>
>>> The following code snippet shows usage of CLIDR_EL1
>>>
>>> In arch/arm64/kernel/cacheinfo.c
>>>
>>> static inline enum cache_type get_cache_type(int level) {
>>> u64 clidr;
>>>
>>> if (level > MAX_CACHE_LEVEL)
>>> return CACHE_TYPE_NOCACHE;
>>> clidr = read_sysreg(clidr_el1);
>>> return CLIDR_CTYPE(clidr, level); }
>>>
>>> static int __populate_cache_leaves(unsigned int cpu) {
>>> unsigned int level, idx;
>>> enum cache_type type;
>>> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>>> struct cacheinfo *this_leaf = this_cpu_ci->info_list;
>>>
>>> for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
>>> idx < this_cpu_ci->num_leaves; idx++, level++) {
>>> type = get_cache_type(level);
>>> if (type == CACHE_TYPE_SEPARATE) {
>>> ci_leaf_init(this_leaf++, CACHE_TYPE_DATA,
> level);
>>> ci_leaf_init(this_leaf++, CACHE_TYPE_INST,
> level);
>>> } else {
>>> ci_leaf_init(this_leaf++, type, level);
>>> }
>>> }
>>> return 0;
>>> }
>>>
>>> In populate_cache_leaves() the cache type is read from CLIDR_EL1
> register.
>>> If CLIDR_EL1 reports CACHE_TYPE_NOCACHE for a particular level then
>>> sysfs entry /sys/devices/system/cpu/cpu0/index<n>/type is not created
>>> and hence userspace tools like lstopo will not report this cache
>>> level.
>>
>>
>> This sounds suspiciously like one of things tweaked between v4->v5. If you
> look
>> at update_cache_properties() in patch 2/9, you will see that we only
>> update/find NOCACHE nodes and convert them to UNIFIED when all the
>> attributes in the node are supplied.
>>
>> This means that if the node has an incomplete set of attributes we won't
> update
>> it. Can you verify that you have all those attributes set for nodes which
> aren't
>> being described by the hardware?
>
> Thanks for pointing out.
> Why do we need to check for set of attributes and decide it as UNIFIED
> cache.?
> We can get cache type from attributes bits[3:2] if cache type valid flag is
> set
> irrespective of other attributes. If cache type valid flag is not set then
> we can assume
> it as NOCACHE type as neither architecture register nor in PPTT has valid
> cache type.
To answer the first question, in a strict sense we don't need to check
any of the attributes in order to override the cache type. That said,
initially I was going to trigger the override only when important
attributes were set to assure that we weren't exporting meaningless
nodes into sysfs. Then while picking which attributes I considered
important, I came to the conclusion that it was simply better to assure
that they were all set for nodes entirely generated by the PPTT. AKA, I
don't want to see L3 cache nodes with their size or associativity unset,
its better in that case that they remain hidden.
Per, the cache type valid bit. The code is written with the assumption
that it is overriding probed values (despite that not being true at the
moment for arm64) in the spirit of the standard. This informs/restricts
how the code works because we aren't simply generating the entire
cacheinfo directly from PPTT walks. Instead we are merging the PPTT
information with anything previously probed, meaning we need a way to
match existing cacheinfo structures with PPTT nodes.
So, the logic finding/matching an existing probed cache node requires
that the cache type is valid because the cache level, and type is used
as the match key. If the PPTT cache node doesn't have the cache type
valid set, then the match logic won't find the node, and the PPTT code
won't make any updates. That may also be what your seeing.. Basically
what is happening is that cacheinfo NOCACHE nodes that happen to match
valid PPTT UNIFIED nodes, can have their cache types overridden, but
only if we determine the remainder of the PPTT node has sufficient
information that we aren't exporting cacheinfo structures without useful
information. Currently, the only time this can happen is for nodes which
are entirely PPTT generated, so I think its fair the PPTT contain enough
information to make those nodes useful.
Thanks,
>
>>
>> Thanks,
>>
>>
>>>
>>> Regards
>>> Vijay
>>>
>>>> -----Original Message-----
>>>> From: linux-arm-kernel
>>> [mailto:linux-arm-kernel-bounces at lists.infradead.org]
>>>> On Behalf Of Rafael J. Wysocki
>>>> Sent: Thursday, December 14, 2017 4:40 AM
>>>> To: Jeremy Linton <jeremy.linton@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
>>>> Jayachandran.Nair at cavium.com; Lorenzo Pieralisi
>>>> <lorenzo.pieralisi@arm.com>; Catalin Marinas
>>>> <catalin.marinas@arm.com>; Rafael J. Wysocki <rafael@kernel.org>;
>>>> jhugo at codeaurora.org; Will Deacon <will.deacon@arm.com>; Linux PM
>> <linux-pm@vger.kernel.org>; Rafael J.
>>>> Wysocki <rjw@rjwysocki.net>; Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
>>>> kernel at vger.kernel.org>; ACPI Devel Maling List
>>> <linux-acpi@vger.kernel.org>;
>>>> Viresh Kumar <viresh.kumar@linaro.org>; Hanjun Guo
>>>> <hanjun.guo@linaro.org>; Al Stone <ahs3@redhat.com>; Sudeep Holla
>>>> <sudeep.holla@arm.com>; austinwc at codeaurora.org;
>>>> wangxiongfeng2 at huawei.com; linux-arm-kernel at lists.infradead.org; Len
>>>> Brown <lenb@kernel.org>
>>>> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
>>>>
>>>> On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton
>>>> <jeremy.linton@arm.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
>>>>>> <lorenzo.pieralisi@arm.com> wrote:
>>>>>>>
>>>>>>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> First, thanks for taking a look at this.
>>>>>>>>
>>>>>>>> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
>>>>>>>>>
>>>>>>>>> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
>>>>>>>>>>
>>>>>>>>>> The PPTT can be used to determine the groupings of CPU's at
>>>>>>>>>> given levels in the system. Lets add a few routines to the PPTT
>>>>>>>>>> parsing code to return a unique id for each unique level in the
>>>>>>>>>> processor hierarchy. This can then be matched to build
>>>>>>>>>> thread/core/cluster/die/package/etc mappings for each
>>>>>>>>>> processing element in the system.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why can't this be folded into patch [2/9]?
>>>>>>>>
>>>>>>>>
>>>>>>>> It can, and I will be happy squash it.
>>>>>>>>
>>>>>>>> It was requested that the topology portion of the parser be split
>>>>>>>> out back in v3.
>>>>>>>>
>>>>>>>> https://www.spinics.net/lists/linux-acpi/msg78487.html
>>>>>>>
>>>>>>>
>>>>>>> I asked to split cache/topology since I am not familiar with cache
>>>>>>> code and Sudeep - who looks after the cache code - won't be able
>>>>>>> to review this series in time for v4.16.
>>>>>>
>>>>>>
>>>>>> OK, so why do we need it in 4.16?
>>>>>
>>>>>
>>>>> I think its more case of as soon as possible. That is because there
>>>>> are machines where the topology is completely incorrect due to
>>>>> assumptions the kernel makes based on registers that aren't defined
>>>>> for that purpose (say describing which cores are in a physical
>>>>> socket, or LLC's attached to interconnects or memory controllers).
>>>>>
>>>>> This incorrect topology information is reported to things like the
>>>>> kernel scheduler, which then makes poor scheduling decisions
>>>>> resulting in sub-optimal system performance.
>>>>>
>>>>> This patchset (and ACPI 6.2) clears up a lot of those problems.
>>>>
>>>> As long as the ACPI tables are as expected that is, I suppose?
>>>>
>>>> Anyway, fair enough, but I don't want to rush it in.
>>>>
>>>> Thanks,
>>>> Rafael
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-01-04 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e36250ba-3f76-71d9-206f-475738d19e36@ti.com>
On 1/4/18 6:39 AM, Sekhar Nori wrote:
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> This converts all of arch/arm/mach-davinci to the common clock framework.
>> The clock drivers from clock.c and psc.c have been moved to drivers/clk,
>> so these files are removed.
>>
>> There is one subtle change in the clock trees. AUX, BPDIV and OSCDIV
>> clocks now have "ref_clk" as a parent instead of the PLL clock. These
>> clocks are part of the PLL's MMIO block, but they bypass the PLL and
>> therefore it makes more sense to have "ref_clk" as their parent since
>> "ref_clk" is the input clock of the PLL.
>>
>> CONFIG_DAVINCI_RESET_CLOCKS is removed since the common clock frameworks
>> takes care of disabling unused clocks.
>>
>> Known issue: This breaks CPU frequency scaling on da850.
>
> This functionality needs to be restored as part of this series since we
> cannot commit anything with regressions.
>
Do you have a suggestion on how to accomplish this? I don't have a board
for testing, so I don't have a way of knowing if my changes will work or
not.
>>
>> Also, the order of #includes are cleaned up in files while we are touching
>> this code.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> This is a pretty huge patch again and I hope it can be broken down.
> Ideally one per SoC converted and then the unused code removal.
>
Will do.
^ permalink raw reply
* [PATCH v4 5/7] clk: Introduce davinci clocks
From: David Lechner @ 2018-01-04 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0165dc8-c23c-c939-d1b7-f10be3b10553@ti.com>
On 1/4/18 6:43 AM, Sekhar Nori wrote:
> Hi David,
>
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> + /* TODO: old davinci clocks for da850 set MDCTL_FORCE bit for sata and
>> + * dsp here. Is this really needed?
>> + */
>
> The commit that introduced this flag suggests so.
>
> commit aad70de20fc69970a3080e7e8f02b54a4a3fe3e6
> Author: Sekhar Nori <nsekhar@ti.com>
> AuthorDate: Wed Jul 6 06:01:22 2011 +0000
> Commit: Sekhar Nori <nsekhar@ti.com>
> CommitDate: Fri Jul 8 11:10:09 2011 +0530
>
> davinci: enable forced transitions on PSC
>
> Some DaVinci modules like the SATA on DA850
> need forced module state transitions.
>
> Define a "force" flag which can be passed to
> the PSC config function to enable it to make
> forced transitions.
>
> Forced transitions shouldn't normally be attempted,
> unless the TRM explicitly specifies its usage.
>
> ChangeLog:
> v2:
> Modified to take care of the fact that
> davinci_psc_config() now takes the flags
> directly.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> I can check without that flag again, but I do recall it being needed.
>
OK, I will add it back. I need to add some other flags as well anyway.
^ permalink raw reply
* [PATCH v4 5/7] clk: Introduce davinci clocks
From: David Lechner @ 2018-01-04 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <521d77e1-1375-7ef0-4ef5-d8a3401d1b73@ti.com>
On 1/4/18 6:28 AM, Sekhar Nori wrote:
> On Wednesday 03 January 2018 03:01 AM, David Lechner wrote:
>> Forgot to cc linux-clk, so doing that now...
>>
>>
>> On 12/31/2017 05:39 PM, David Lechner wrote:
>>> This introduces new drivers for arch/arm/mach-davinci. The code is based
>>> on the clock drivers from there and adapted to use the common clock
>>> framework.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>> ? drivers/clk/Makefile????????????????????? |?? 1 +
>>> ? drivers/clk/davinci/Makefile????????????? |?? 3 +
>>> ? drivers/clk/davinci/da8xx-cfgchip-clk.c?? | 380
>>> ++++++++++++++++++++++++++++++
>>> ? drivers/clk/davinci/pll.c???????????????? | 333
>>> ++++++++++++++++++++++++++
>>> ? drivers/clk/davinci/psc.c???????????????? | 217 +++++++++++++++++
>>> ? include/linux/clk/davinci.h?????????????? |? 46 ++++
>>> ? include/linux/platform_data/davinci_clk.h |? 25 ++
>>> ? 7 files changed, 1005 insertions(+)
>
> This is a pretty huge patch and I think each of cfgchip, pll and PSC
> clocks deserve a patch of their own.
Will do.
>
> On the PLL patch, please describe how the PLL implementation on DaVinci
> is different from Keystone, so no reuse is really possible. Similarly
> for the PSC patch (no non-DT support in keystone etc).
OK.
>
>>> diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c
>>> new file mode 100644
>>> index 0000000..8ae85ee
>>> --- /dev/null
>>> +++ b/drivers/clk/davinci/psc.c
>>> @@ -0,0 +1,217 @@
>
>>> +static void psc_config(struct davinci_psc_clk *psc,
>>> +?????????????? enum davinci_psc_state next_state)
>>> +{
>>> +??? u32 epcpr, ptcmd, pdstat, pdctl, mdstat, mdctl, ptstat;
>>> +
>>> +??? mdctl = readl(psc->base + MDCTL + 4 * psc->lpsc);
>>> +??? mdctl &= ~MDSTAT_STATE_MASK;
>>> +??? mdctl |= next_state;
>>> +??? /* TODO: old davinci clocks for da850 set MDCTL_FORCE bit for
>>> sata and
>>> +???? * dsp here. Is this really needed?
>>> +???? */
>>> +??? writel(mdctl, psc->base + MDCTL + 4 * psc->lpsc);
>>> +
>>> +??? pdstat = readl(psc->base + PDSTAT + 4 * psc->pd);
>>> +??? if ((pdstat & PDSTAT_STATE_MASK) == 0) {
>>> +??????? pdctl = readl(psc->base + PDSTAT + 4 * psc->pd);
>>> +??????? pdctl |= PDCTL_NEXT;
>>> +??????? writel(pdctl, psc->base + PDSTAT + 4 * psc->pd);
>>> +
>>> +??????? ptcmd = BIT(psc->pd);
>>> +??????? writel(ptcmd, psc->base + PTCMD);
>>> +
>>> +??????? do {
>>> +??????????? epcpr = __raw_readl(psc->base + EPCPR);
>>> +??????? } while (!(epcpr & BIT(psc->pd)));
>>> +
>>> +??????? pdctl = __raw_readl(psc->base + PDCTL + 4 * psc->pd);
>>> +??????? pdctl |= PDCTL_EPCGOOD;
>>> +??????? __raw_writel(pdctl, psc->base + PDCTL + 4 * psc->pd);
>
> Can we shift to regmap here too? Then the polling loops like above can
> be converted to regmap_read_poll_timeout() too like you have done elsewhere.
>
I'll give it a try.
^ permalink raw reply
* [PATCH v4 3/7] ARM: davinci: fix duplicate clocks
From: David Lechner @ 2018-01-04 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3beaac9-c583-b181-38a8-d0aa6db44045@ti.com>
On 1/4/18 5:12 AM, Sekhar Nori wrote:
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> There are a number of clocks that were duplicated because they are used by
>> more than one device. It is no longer necessary to do this since we are
>> explicitly calling clk_register_clkdev() for each clock. In da830.c, some
>> clocks were using the same LPSC, which would cause problems with reference
>> counting, so these are combinded into one clock each. In da850.c the
>> duplicate clocks had already been fixed by creating dummy child clocks, so
>> these clocks are removed.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> If we do end up keeping 2/7, this should be done before that - to avoid
> retouching code that was just introduced.
>
FWIW, this can't be done before because it will cause broken linked
lists in the davinci clocks. But, as I mentioned already, I am going to
try a different approach, so this patch will go away completely.
^ permalink raw reply
* [PATCH v4 2/7] ARM: davinci: don't use static clk_lookup
From: David Lechner @ 2018-01-04 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17d6af61-a6db-9dc6-6fde-e9ff44e57389@ti.com>
On 1/4/18 5:10 AM, Sekhar Nori wrote:
> Hi David,
>
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> In preparation of moving to the common clock framework, usage of static
>> struct clk_lookup is removed. The common clock framework uses an opaque
>> struct clk, so we won't be able to use static tables as was previously
>> done.
>>
>> davinci_clk_init() is changed to init a single clock instead of a table
>> and an individual clk_register_clkdev() is added for each clock.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> Is there a need for this considering in 6/7 you end up modifying quite a
> bit of this patch again?
No, you are right. And I've been working ahead with device tree support
so I think I want to do this a bit differently anyway.
^ permalink raw reply
* Applied "ASoC: mediatek: add some core clocks for MT2701 AFE" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d93643da906e25360a7dbbdcbfaa2228dfd688bf.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: add some core clocks for MT2701 AFE
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 96365d9fdb2f0d81bfc010298289a8c168931cd0 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:07 +0800
Subject: [PATCH] ASoC: mediatek: add some core clocks for MT2701 AFE
Add three core clocks for MT2701 AFE.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 30 ++++++++++++++++++++++-
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 3 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index 56a057c78c9a..949fc3a1d025 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -18,8 +18,11 @@
#include "mt2701-afe-clock-ctrl.h"
static const char *const base_clks[] = {
+ [MT2701_INFRA_SYS_AUDIO] = "infra_sys_audio_clk",
[MT2701_TOP_AUD_MCLK_SRC0] = "top_audio_mux1_sel",
[MT2701_TOP_AUD_MCLK_SRC1] = "top_audio_mux2_sel",
+ [MT2701_TOP_AUD_A1SYS] = "top_audio_a1sys_hp",
+ [MT2701_TOP_AUD_A2SYS] = "top_audio_a2sys_hp",
[MT2701_AUDSYS_AFE] = "audio_afe_pd",
[MT2701_AUDSYS_AFE_CONN] = "audio_afe_conn_pd",
[MT2701_AUDSYS_A1SYS] = "audio_a1sys_pd",
@@ -169,10 +172,26 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
struct mt2701_afe_private *afe_priv = afe->platform_priv;
int ret;
- ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ /* Enable infra clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
if (ret)
return ret;
+ /* Enable top a1sys clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+ if (ret)
+ goto err_a1sys;
+
+ /* Enable top a2sys clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+ if (ret)
+ goto err_a2sys;
+
+ /* Internal clock gates */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ if (ret)
+ goto err_afe;
+
ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
if (ret)
goto err_audio_a1sys;
@@ -193,6 +212,12 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
err_audio_a1sys:
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+err_afe:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+err_a2sys:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+err_a1sys:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
return ret;
}
@@ -205,6 +230,9 @@ static void mt2701_afe_disable_audsys(struct mtk_base_afe *afe)
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A2SYS]);
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
}
int mt2701_afe_enable_clock(struct mtk_base_afe *afe)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 9a2b301a4c21..ae8ddeacfbfe 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -61,8 +61,11 @@ enum {
};
enum audio_base_clock {
+ MT2701_INFRA_SYS_AUDIO,
MT2701_TOP_AUD_MCLK_SRC0,
MT2701_TOP_AUD_MCLK_SRC1,
+ MT2701_TOP_AUD_A1SYS,
+ MT2701_TOP_AUD_A2SYS,
MT2701_AUDSYS_AFE,
MT2701_AUDSYS_AFE_CONN,
MT2701_AUDSYS_A1SYS,
--
2.15.1
^ permalink raw reply related
* Applied "ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90c34b9bb2cd7ef15c263a4267e7f083a4f56a85.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From dfa3cbb83e099d5ef9809b67ea3bff3a39dc2f06 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:08 +0800
Subject: [PATCH] ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
As the new MFD parent is in place, modify MT2701 AFE driver to adapt it.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 45 +++++++++++++-----------------
sound/soc/mediatek/mt2701/mt2701-reg.h | 1 -
2 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index 0edadca12a5e..f0cd08fa5c5d 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -17,6 +17,7 @@
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/mfd/syscon.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/pm_runtime.h>
@@ -1368,14 +1369,6 @@ static const struct mt2701_i2s_data mt2701_i2s_data[MT2701_I2S_NUM][2] = {
},
};
-static const struct regmap_config mt2701_afe_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .max_register = AFE_END_ADDR,
- .cache_type = REGCACHE_NONE,
-};
-
static irqreturn_t mt2701_asys_isr(int irq_id, void *dev)
{
int id;
@@ -1414,9 +1407,9 @@ static int mt2701_afe_runtime_resume(struct device *dev)
static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
{
+ struct snd_soc_component *component;
struct mtk_base_afe *afe;
struct mt2701_afe_private *afe_priv;
- struct resource *res;
struct device *dev;
int i, irq_id, ret;
@@ -1446,17 +1439,11 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- afe->base_addr = devm_ioremap_resource(&pdev->dev, res);
-
- if (IS_ERR(afe->base_addr))
- return PTR_ERR(afe->base_addr);
-
- afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
- &mt2701_afe_regmap_config);
- if (IS_ERR(afe->regmap))
- return PTR_ERR(afe->regmap);
+ afe->regmap = syscon_node_to_regmap(dev->parent->of_node);
+ if (!afe->regmap) {
+ dev_err(dev, "could not get regmap from parent\n");
+ return -ENODEV;
+ }
mutex_init(&afe->irq_alloc_lock);
@@ -1490,6 +1477,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
= &mt2701_i2s_data[i][I2S_IN];
}
+ component = kzalloc(sizeof(*component), GFP_KERNEL);
+ if (!component)
+ return -ENOMEM;
+
+ component->regmap = afe->regmap;
+
afe->mtk_afe_hardware = &mt2701_afe_hardware;
afe->memif_fs = mt2701_memif_fs;
afe->irq_fs = mt2701_irq_fs;
@@ -1502,7 +1495,7 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
ret = mt2701_init_clock(afe);
if (ret) {
dev_err(dev, "init clock error\n");
- return ret;
+ goto err_init_clock;
}
platform_set_drvdata(pdev, afe);
@@ -1521,10 +1514,10 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
goto err_platform;
}
- ret = snd_soc_register_component(&pdev->dev,
- &mt2701_afe_pcm_dai_component,
- mt2701_afe_pcm_dais,
- ARRAY_SIZE(mt2701_afe_pcm_dais));
+ ret = snd_soc_add_component(dev, component,
+ &mt2701_afe_pcm_dai_component,
+ mt2701_afe_pcm_dais,
+ ARRAY_SIZE(mt2701_afe_pcm_dais));
if (ret) {
dev_warn(dev, "err_dai_component\n");
goto err_dai_component;
@@ -1538,6 +1531,8 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
pm_runtime_put_sync(dev);
err_pm_disable:
pm_runtime_disable(dev);
+err_init_clock:
+ kfree(component);
return ret;
}
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index f17c76f37b5f..18e676974f22 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -145,5 +145,4 @@
#define ASYS_I2S_CON_WIDE_MODE_SET(x) ((x) << 1)
#define ASYS_I2S_IN_PHASE_FIX (0x1 << 31)
-#define AFE_END_ADDR 0x15e0
#endif
--
2.15.1
^ permalink raw reply related
* Applied "ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a716adbb734cefd8e8ea614a2e4686af8204490e.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7f12a56367bf526afde7e81820a8c7d97e75ed10 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:09 +0800
Subject: [PATCH] ASoC: mediatek: update MT2701 AFE documentation to adapt mfd
device
As the new MFD parent is in place, modify MT2701 AFE documentation to
adapt it. Also add three core clocks in example.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/mt2701-afe-pcm.txt | 171 +++++++++++----------
1 file changed, 93 insertions(+), 78 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
index 0450baad2813..6df87b97f7cb 100644
--- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
@@ -2,15 +2,17 @@ Mediatek AFE PCM controller for mt2701
Required properties:
- compatible = "mediatek,mt2701-audio";
-- reg: register location and size
- interrupts: should contain AFE and ASYS interrupts
- interrupt-names: should be "afe" and "asys"
- power-domains: should define the power domain
- clocks: Must contain an entry for each entry in clock-names
See ../clocks/clock-bindings.txt for details
- clock-names: should have these clock names:
+ "infra_sys_audio_clk",
"top_audio_mux1_sel",
"top_audio_mux2_sel",
+ "top_audio_a1sys_hp",
+ "top_audio_a2sys_hp",
"i2s0_src_sel",
"i2s1_src_sel",
"i2s2_src_sel",
@@ -45,85 +47,98 @@ Required properties:
- assigned-clocks-parents: parent of input clocks of assigned clocks.
- assigned-clock-rates: list of clock frequencies of assigned clocks.
+Must be a subnode of MediaTek audsys device tree node.
+See ../arm/mediatek/mediatek,audsys.txt for details about the parent node.
+
Example:
- afe: mt2701-afe-pcm at 11220000 {
- compatible = "mediatek,mt2701-audio";
- reg = <0 0x11220000 0 0x2000>,
- <0 0x112A0000 0 0x20000>;
- interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "afe", "asys";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
- clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
- <&audiosys CLK_AUD_I2SO1>,
- <&audiosys CLK_AUD_I2SO2>,
- <&audiosys CLK_AUD_I2SO3>,
- <&audiosys CLK_AUD_I2SO4>,
- <&audiosys CLK_AUD_I2SIN1>,
- <&audiosys CLK_AUD_I2SIN2>,
- <&audiosys CLK_AUD_I2SIN3>,
- <&audiosys CLK_AUD_I2SIN4>,
- <&audiosys CLK_AUD_ASRCO1>,
- <&audiosys CLK_AUD_ASRCO2>,
- <&audiosys CLK_AUD_ASRCO3>,
- <&audiosys CLK_AUD_ASRCO4>,
- <&audiosys CLK_AUD_AFE>,
- <&audiosys CLK_AUD_AFE_CONN>,
- <&audiosys CLK_AUD_A1SYS>,
- <&audiosys CLK_AUD_A2SYS>,
- <&audiosys CLK_AUD_AFE_MRGIF>;
+ audsys: audio-subsystem at 11220000 {
+ compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
+ ...
+
+ afe: audio-controller {
+ compatible = "mediatek,mt2701-audio";
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "afe", "asys";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+
+ clocks = <&infracfg CLK_INFRA_AUDIO>,
+ <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_48K_TIMING>,
+ <&topckgen CLK_TOP_AUD_44K_TIMING>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
+ <&audsys CLK_AUD_I2SO1>,
+ <&audsys CLK_AUD_I2SO2>,
+ <&audsys CLK_AUD_I2SO3>,
+ <&audsys CLK_AUD_I2SO4>,
+ <&audsys CLK_AUD_I2SIN1>,
+ <&audsys CLK_AUD_I2SIN2>,
+ <&audsys CLK_AUD_I2SIN3>,
+ <&audsys CLK_AUD_I2SIN4>,
+ <&audsys CLK_AUD_ASRCO1>,
+ <&audsys CLK_AUD_ASRCO2>,
+ <&audsys CLK_AUD_ASRCO3>,
+ <&audsys CLK_AUD_ASRCO4>,
+ <&audsys CLK_AUD_AFE>,
+ <&audsys CLK_AUD_AFE_CONN>,
+ <&audsys CLK_AUD_A1SYS>,
+ <&audsys CLK_AUD_A2SYS>,
+ <&audsys CLK_AUD_AFE_MRGIF>;
- clock-names = "top_audio_mux1_sel",
- "top_audio_mux2_sel",
- "i2s0_src_sel",
- "i2s1_src_sel",
- "i2s2_src_sel",
- "i2s3_src_sel",
- "i2s0_src_div",
- "i2s1_src_div",
- "i2s2_src_div",
- "i2s3_src_div",
- "i2s0_mclk_en",
- "i2s1_mclk_en",
- "i2s2_mclk_en",
- "i2s3_mclk_en",
- "i2so0_hop_ck",
- "i2so1_hop_ck",
- "i2so2_hop_ck",
- "i2so3_hop_ck",
- "i2si0_hop_ck",
- "i2si1_hop_ck",
- "i2si2_hop_ck",
- "i2si3_hop_ck",
- "asrc0_out_ck",
- "asrc1_out_ck",
- "asrc2_out_ck",
- "asrc3_out_ck",
- "audio_afe_pd",
- "audio_afe_conn_pd",
- "audio_a1sys_pd",
- "audio_a2sys_pd",
- "audio_mrgif_pd";
+ clock-names = "infra_sys_audio_clk",
+ "top_audio_mux1_sel",
+ "top_audio_mux2_sel",
+ "top_audio_a1sys_hp",
+ "top_audio_a2sys_hp",
+ "i2s0_src_sel",
+ "i2s1_src_sel",
+ "i2s2_src_sel",
+ "i2s3_src_sel",
+ "i2s0_src_div",
+ "i2s1_src_div",
+ "i2s2_src_div",
+ "i2s3_src_div",
+ "i2s0_mclk_en",
+ "i2s1_mclk_en",
+ "i2s2_mclk_en",
+ "i2s3_mclk_en",
+ "i2so0_hop_ck",
+ "i2so1_hop_ck",
+ "i2so2_hop_ck",
+ "i2so3_hop_ck",
+ "i2si0_hop_ck",
+ "i2si1_hop_ck",
+ "i2si2_hop_ck",
+ "i2si3_hop_ck",
+ "asrc0_out_ck",
+ "asrc1_out_ck",
+ "asrc2_out_ck",
+ "asrc3_out_ck",
+ "audio_afe_pd",
+ "audio_afe_conn_pd",
+ "audio_a1sys_pd",
+ "audio_a2sys_pd",
+ "audio_mrgif_pd";
- assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_MUX1_DIV>,
- <&topckgen CLK_TOP_AUD_MUX2_DIV>;
- assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
- <&topckgen CLK_TOP_AUD2PLL_90M>;
- assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX1_DIV>,
+ <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+ assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
+ <&topckgen CLK_TOP_AUD2PLL_90M>;
+ assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ };
};
--
2.15.1
^ permalink raw reply related
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Gary R Hook @ 2018-01-04 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9014a9e1-9545-4f3c-08c2-8e8eb4762101@codeaurora.org>
On 01/04/2018 10:32 AM, Sinan Kaya wrote:
> On 1/4/2018 11:28 AM, Gary R Hook wrote:
>> On 01/04/2018 06:25 AM, Sinan Kaya wrote:
>>> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>>>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>>>> where a PCI device is present. This restricts the device drivers to be
>>>> reused for other domain numbers.
>>>>
>>>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>>>> pci_get_domain_bus_and_slot().
>>>>
>>>> Hard-code the domain number as 0 for the AMD IOMMU driver.
>>
>> <snip>
>>
>>>
>>> Any comments from the IOMMU people?
>>>
>>
>> pci_get_bus_and_slot() appears to (now) be a convenience function that wraps pci_get_domain_bus_and_slot() while using a 0 for the domain value. Exactly what you are doing here, albeit in a more overt way.
>>
>> How is this patch advantageous? Seems to me that if other domains need to be enabled, that driver could be changed if and when that requirement arises.
>>
>> But perhaps I'm missing a nuance here.
>>
>>
>
> The benefit of the change was discussed here:
>
> https://lkml.org/lkml/2017/12/19/349
>
> I hope it helps.
>
>
Thank you for pointing out that thread directly. I read through it and
thought further about this change.
I am not the maintainer, but as an AMD developer, this is fine change. I
can't ACK but I can agree.
Gary
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: John Garry @ 2018-01-04 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221193917.GB1105@krava>
On 21/12/2017 19:39, Jiri Olsa wrote:
>> Hi Jirka,
>> >
>> > When you say reasonable size for x86, I ran a string duplication finder on
>> > the x86 JSONs and the results show a huge amount of duplication. Please
>> > check this:
>> > https://gist.githubusercontent.com/johnpgarry/68bc87e823ae2ce0f7b475b4e55e5795/raw/f4cea138999d8b34151b9586d733592e01774d7a/x86%2520JSON%2520duplication
>> >
>> > Extract:
>> > "Found a 65 line (311 tokens) duplication in the following files:
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/ivytown/ivt-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/broadwell/bdw-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
>> > Starting at line 76 of
>> > /linux/tools/perf/pmu-events/arch/x86/jaketown/jkt-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
>> > Starting at line 76 of
>> > /linux/tools/perf/pmu-events/arch/x86/sandybridge/snb-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/broadwellx/bdx-metrics.json"
>> >
Hi Jirka,
Sorry for the slow reply.
>> > Won't this all potentially have a big maintainence cost?
> as Andi said it's mostly just the disk space,
> which is not big deal
>
> I'm not doing JSON file updates, but I think having
> simple single dir for platform/cpu could save us some
> confusion in future
Understood. But for ARM, which has very standardised architecture
events, it is good to reduce this event duplication between platforms.
>
> however I won't oppose if you want to add this logic,
> but please:
> - use the list_head ;-)
Of course
> - leave the process_one_file function simple
> and separate the level0 processing
ok, this is how it should look already, albeit a couple of
process_one_file() modifications. I'll re-check this.
> - you are using 'EventCode' as an unique ID to find
> the base, but it's not unique for x86, you'll need
> to add some other ID scheme that fits to all archs
Right, so you mentioned earlier using a new keyword token to identify
whether we use the standard event, so we can go his way - ok?
I would also like to mention at this point why I did the event
pre-processing in jevents, and not a separate script:
- current build does not transverse the arch tree
- tree transversal for JSON processing is done in jevents
- a script would mean derived objects, which means:
- makefile changes for derived objects
- jevents would have to deal with derived objects
- jevents already has support for JSON processing
The advantage of using a script is that we keep the JSON processing in
jevents simple.
All the best,
John
>
> thanks,
> jirka
>
^ permalink raw reply
* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Russell King - ARM Linux @ 2018-01-04 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104180238.581b202c@windsurf.lan>
On Thu, Jan 04, 2018 at 06:02:38PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> I'm pretty sure it has already been reported, but just in case: I'm
> testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
> mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
> Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
> boot at all when built with gcc 7.2 (Fedora toolchain). Even when
> configured and booted with earlyprintk, the kernel doesn't say anything.
>
> The toolchain being used is the default ARM toolchain provided by
> Fedora 27. It says:
>
> gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
> GNU ld version 2.29.1-1.fc27
>
> So it's quite bleeding edge.
>
> Let me know if this has already been fixed, or if I should test a
> patch. I have not tested 4.15-rc or next at this point, assuming that
> if a fix had been made, it would have been backported to 4.14-stable.
It's a known issue -
http://archive.armlinux.org.uk/lurker/message/20171018.095713.a56a717b.en.html
but so far no patches have been forthcoming for the kernel, because
(I guess) it's deemed to be a gcc bug.
It's one of those discussions that just seemed to die without any
real conclusion.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Marc Zyngier @ 2018-01-04 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8E=yWRE9PThFeG3efuT5JLbAK+RpmhTvuEeXwk-iuN9g@mail.gmail.com>
On 04/01/18 16:31, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
>> and can theoretically be attacked by malicious code.
>>
>> This patch implements a PSCI-based mitigation for these CPUs when available.
>> The call into firmware will invalidate the branch predictor state, preventing
>> any malicious entries from affecting other victim contexts.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
>> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 66 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
>> index 06a931eb2673..2b10d52a0321 100644
>> --- a/arch/arm64/kernel/bpi.S
>> +++ b/arch/arm64/kernel/bpi.S
>> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
>> vectors __kvm_hyp_vector
>> .endr
>> ENTRY(__bp_harden_hyp_vecs_end)
>> +ENTRY(__psci_hyp_bp_inval_start)
>> + stp x0, x1, [sp, #-16]!
>> + stp x2, x3, [sp, #-16]!
>> + stp x4, x5, [sp, #-16]!
>> + stp x6, x7, [sp, #-16]!
>> + stp x8, x9, [sp, #-16]!
>> + stp x10, x11, [sp, #-16]!
>> + stp x12, x13, [sp, #-16]!
>> + stp x14, x15, [sp, #-16]!
>> + stp x16, x17, [sp, #-16]!
>> + stp x18, x19, [sp, #-16]!
>
> Would it be better to update sp only once here?
Maybe. I suppose that's quite uarch dependent, but worth trying.
> Also, do x18 and x19 need to be preserved/restored here?
My bad. I misread the SMCCC and though I needed to save it too. For the
reference, the text says:
"Registers X18-X30 and stack pointers SP_EL0 and SP_ELx are saved by
the function that is called, and must be preserved over the SMC or HVC
call."
I'll amend the patch.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Ard Biesheuvel @ 2018-01-04 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <060b7c34-bce9-da78-f9cb-2e67dd2ee142@arm.com>
On 4 January 2018 at 17:04, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 04/01/18 16:28, Ard Biesheuvel wrote:
>> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>>>
>>
>> Why does bp hardening require per-cpu vectors?
>
> The description is not 100% accurate. We have per *CPU type* vectors.
> This stems from the following, slightly conflicting requirements:
>
> - We have systems with more than one CPU type (think big-little)
> - Different implementations require different BP hardening sequences
> - The BP hardening sequence must be executed before doing any branch
>
> The natural solution is to have one set of vectors per CPU type,
> containing the BP hardening sequence for that particular implementation,
> ending with a branch to the common code.
>
Crystal clear, thanks.
^ permalink raw reply
* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Marc Zyngier @ 2018-01-04 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_wNtjh57PW0jyr39iswiqRMR=5wFezGhgcM4uyv_yuww@mail.gmail.com>
On 04/01/18 16:28, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>>
>
> Why does bp hardening require per-cpu vectors?
The description is not 100% accurate. We have per *CPU type* vectors.
This stems from the following, slightly conflicting requirements:
- We have systems with more than one CPU type (think big-little)
- Different implementations require different BP hardening sequences
- The BP hardening sequence must be executed before doing any branch
The natural solution is to have one set of vectors per CPU type,
containing the BP hardening sequence for that particular implementation,
ending with a branch to the common code.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Thomas Petazzoni @ 2018-01-04 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm pretty sure it has already been reported, but just in case: I'm
testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
boot at all when built with gcc 7.2 (Fedora toolchain). Even when
configured and booted with earlyprintk, the kernel doesn't say anything.
The toolchain being used is the default ARM toolchain provided by
Fedora 27. It says:
gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
GNU ld version 2.29.1-1.fc27
So it's quite bleeding edge.
Let me know if this has already been fixed, or if I should test a
patch. I have not tested 4.15-rc or next at this point, assuming that
if a fix had been made, it would have been backported to 4.14-stable.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/3] ARM: dts: renesas: Reduce size of thermal registers
From: Simon Horman @ 2018-01-04 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220121445.31896-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:14:42PM +0100, Simon Horman wrote:
> Reduce size of thermal registers in DT for the following SoCs:
> * r8a7790 (R-Car H2)
> * r8a7791 (R-Car M3-W)
> * r8a7793 (R-Car M3-N)
>
> According to the "User's Manual: Hardware" v2.00 the registers at base
> 0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
> on the r8a73a4 (R-Mobile APE6).
>
> This should not have any runtime affect as mapping granularity is PAGE_SIZE.
>
> As pointed out by Geert Uytterhoeven.
>
> Based on renesas-devel-20171220-v4.15-rc4
>
> Simon Horman (3):
> ARM: dts: r8a7790: Reduce size of thermal registers
> ARM: dts: r8a7791: Reduce size of thermal registers
> ARM: dts: r8a7793: Reduce size of thermal registers
Applied
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.16, take 2
From: Arnd Bergmann @ 2018-01-04 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZB7UFXesbQJHjuM_fdkY7w0USD5suGQevo3efsr+wgOg@mail.gmail.com>
On Fri, Dec 22, 2017 at 10:08 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> I realized I forgot two DTS patches and the panel
> driver for enabling video on DIR-685 was merged, so here is
> a second pull request on top of the Gemini DTS pull request
> from yesterday.
>
> Please pull it in on top of the other Gemini DTS patches!
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77995: move nodes which have no reg property out of bus
From: Simon Horman @ 2018-01-04 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220122442.9199-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:24:42PM +0100, Simon Horman wrote:
> Move pmu_a53 and timer nodes from soc node to root node. The nodes that
> have been moved do not have any register properties and thus shouldn't be
> placed on the bus.
>
> This problem is flagged by the compiler as follows:
> $ make W=1
> ...
> arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: move node which has no reg property out of bus
From: Simon Horman @ 2018-01-04 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220122549.9452-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:25:49PM +0100, Simon Horman wrote:
> Move timer node from soc node to root node. The node that have been moved
> do not have any register properties and thus shouldn't be placed on the
> bus.
>
> This problem is flagged by the compiler as follows:
> $ make W=1
> ...
> DTC arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb
> arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied
^ 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