Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
On Thu, 2019-08-08 at 11:51 +0530, Anshuman Khandual wrote:
>
> On 08/08/2019 11:31 AM, Miles Chen wrote:
> > On Thu, 2019-08-08 at 11:19 +0530, Anshuman Khandual wrote:
> >>
> >> On 08/07/2019 06:03 AM, Miles Chen wrote:
> >>> This change prints the hexadecimal EC value in mem_abort_decode(),
> >>> which makes it easier to lookup the corresponding EC in
> >>> the ARM Architecture Reference Manual.
> >>>
> >>> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> >>> faults") prints useful information when memory abort occurs. It would
> >>> be easier to lookup "0x25" instead of "DABT" in the document. Then we
> >>> can check the corresponding ISS.
> >>>
> >>> For example:
> >>> Current infoDocument
> >>> EC Exception class
> >>> "CP15 MCR/MRC"0x3 "MCR or MRC access to CP15a..."
> >>> "ASIMD" 0x7 "Access to SIMD or floating-point..."
> >>> "DABT (current EL)" 0x25"Data Abort taken without..."
> >>> ...
> >>>
> >>> Before:
> >>> Unable to handle kernel paging request at virtual address c000
> >>> Mem abort info:
> >>> ESR = 0x9646
> >>> Exception class = DABT (current EL), IL = 32 bits
> >>> SET = 0, FnV = 0
> >>> EA = 0, S1PTW = 0
> >>> Data abort info:
> >>> ISV = 0, ISS = 0x0046
> >>> CM = 0, WnR = 1
> >>>
> >>> After:
> >>> Unable to handle kernel paging request at virtual address c000
> >>> Mem abort info:
> >>> ESR = 0x9646
> >>> EC = 0x25: DABT (current EL), IL = 32 bits
> >>> SET = 0, FnV = 0
> >>> EA = 0, S1PTW = 0
> >>> Data abort info:
> >>> ISV = 0, ISS = 0x0046
> >>> CM = 0, WnR = 1
> >>>
> >>> Change since v1:
> >>> print "EC" instead of "Exception class"
> >>> print EC in fixwidth
> >>>
> >>> Cc: Mark Rutland
> >>> Cc: Anshuman Khandual
> >>> Cc: James Morse
> >>> Signed-off-by: Miles Chen
> >>
> >> This version implements the suggestion, hence it should have
> >> also contained acked-by tag from Mark from earlier version.
> >>
> >
> > No problem. Sorry for not including the tag.
> > I was not sure if I should add the acked-by tag from Mark in patch v2.
>
> Yeah because V2 has now implemented the suggestion as required for
> getting the tag per Mark in V1.
>
Understood. thanks for the explanation
> >
> >> Reviewed-by: Anshuman Khandual
> >
> > If I send patch v3, I should include acked-by tag from Mark and
> > Reviewed-by tag from you, right?
>
> Right.
Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
On 08/08/2019 11:50 AM, Justin He (Arm Technology China) wrote:
> Hi Anshuman
> Thanks for the comments, please see my comments below
>
>> -Original Message-
>> From: Anshuman Khandual
>> Sent: 2019年8月8日 13:19
>> To: Justin He (Arm Technology China) ; Catalin
>> Marinas ; Will Deacon ;
>> Mark Rutland ; James Morse
>>
>> Cc: Christoffer Dall ; Punit Agrawal
>> ; Qian Cai ; Jun Yao
>> ; Alex Van Brunt ;
>> Robin Murphy ; Thomas Gleixner
>> ; linux-arm-ker...@lists.infradead.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in
>> pte_mkdevmap on arm64
>>
> [...]
>>> diff --git a/arch/arm64/include/asm/pgtable.h
>> b/arch/arm64/include/asm/pgtable.h
>>> index 5fdcfe237338..e09760ece844 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
>>>
>>> static inline pte_t pte_mkdevmap(pte_t pte)
>>> {
>>> - return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
>>> + return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
>>> }
>>>
>>> static inline void set_pte(pte_t *ptep, pte_t pte)
>>> @@ -396,7 +396,10 @@ static inline int pmd_protnone(pmd_t pmd)
>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> #define pmd_devmap(pmd)pte_devmap(pmd_pte(pmd))
>>> #endif
>>> -#define pmd_mkdevmap(pmd)
>> pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
>>> +static inline pmd_t pmd_mkdevmap(pmd_t pmd)
>>> +{
>>> + return pte_pmd(set_pte_bit(pmd_pte(pmd),
>> __pgprot(PTE_DEVMAP)));
>>> +}
>>
>> Though I could see other platforms like powerpc and x86 following same
>> approach (DEVMAP + SPECIAL) for pte so that it checks positive for
>> pte_special() but then just DEVMAP for pmd which could never have a
>> pmd_special(). But a more fundamental question is - why should a devmap
>> be a special pte as well ?
>
> IIUC, special pte bit make things handling easier compare with those arches
> which
> have no special bit. The memory codes will regard devmap page as a special
> one
> compared with normal page.
For that we have PTE_DEVMAP on arm64 which differentiates device memory
entries from others and it should not again need PTE_SPECIAL as well for
that. We set both bits while creating the entries with pte_mkdevmap()
and check just one bit PTE_DEVMAP with pte_devmap(). Problem is it will
also test positive for pte_special() and risks being identified as one.
> Devmap page structure can be stored in ram/pmem/none.
That is altogether a different aspect which is handled with vmem_altmap
during hotplug and nothing to do with how device memory is mapped in the
page table. I am not sure about "none" though. IIUC unlike traditional
device pfn all ZONE_DEVICE memory will have struct page backing either
on system RAM or in the device memory itself.
>
>>
>> Also in vm_normal_page() why cannot it tests for pte_devmap() before it
>> starts looking for CONFIG_ARCH_HAS_PTE_SPECIAL. Is this the only path
>> for
>
> AFAICT, yes, but it changes to much besides arm codes. 😊
If this is the only path for which all platforms have to set PTE_SPECIAL
in their device mapping, then it should just be fixed in vm_normal_page().
>
>> which we need to set SPECIAL bit on a devmap pte or there are other paths
>> where this semantics is assumed ?
>
> No idea
Probably something to be asked in the mm community.
1. Why pte_mkdevmap() should set SPECIAL bit for a positive pte_special()
check. Why the same mapping be identified as pte_devmap() as well as
pte_special().
2. Can pte_devmap() and pte_special() re-ordering at vm_normal_page() will
remove this dependency or there are other commons MM paths which assume
this behavior ?
+ linux...@kvack.org
+ Dan Williams
+ Jérôme Glisse
+ Logan Gunthorpe
+ Christoph Hellwig
powerpc flush_inval_dcache_range() was buggy until v5.3-rc1 (was Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range())
[ deliberately broke threading so this doesn't get buried ]
Christophe Leroy writes:
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index a4fd536efb44..1b0a42c50ef1 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -115,35 +115,6 @@ _ASM_NOKPROBE_SYMBOL(flush_icache_range)
> EXPORT_SYMBOL(flush_icache_range)
>
> /*
> - * Like above, but only do the D-cache.
> - *
> - * flush_dcache_range(unsigned long start, unsigned long stop)
> - *
> - *flush all bytes from start to stop-1 inclusive
> - */
> -
> -_GLOBAL_TOC(flush_dcache_range)
> - ld r10,PPC64_CACHES@toc(r2)
> - lwz r7,DCACHEL1BLOCKSIZE(r10) /* Get dcache block size */
> - addir5,r7,-1
> - andcr6,r3,r5/* round low to line bdy */
> - subfr8,r6,r4/* compute length */
> - add r8,r8,r5/* ensure we get enough */
> - lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
> - srw.r8,r8,r9/* compute line count */
^
> - beqlr /* nothing to do? */
Alastair noticed that this was a 32-bit right shift.
Meaning if you called flush_dcache_range() with a range larger than 4GB,
it did nothing and returned.
That code (which was previously called flush_inval_dcache_range()) was
merged back in 2005:
https://github.com/mpe/linux-fullhistory/commit/faa5ee3743ff9b6df9f9a03600e34fdae596cfb2#diff-67c7ffa8e420c7d4206cae4a9e888e14
Back then it was only used by the smu.c driver, which presumably wasn't
flushing more than 4GB.
Over time it grew more users:
v4.17 (Apr 2018): fb5924fddf9e ("powerpc/mm: Flush cache on memory
hot(un)plug")
v4.15 (Nov 2017): 6c44741d75a2 ("powerpc/lib: Implement UACCESS_FLUSHCACHE
API")
v4.15 (Nov 2017): 32ce3862af3c ("powerpc/lib: Implement PMEM API")
v4.8 (Jul 2016): c40785ad305b ("powerpc/dart: Use a cachable DART")
The DART case doesn't matter, but the others probably could. I assume
the lack of bug reports is due to the fact that pmem stuff is still in
development and the lack of flushing usually doesn't actually matter? Or
are people flushing/hotplugging < 4G at a time?
Anyway we probably want to backport the fix below to various places?
cheers
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 1ad4089dd110..802f5abbf061 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -148,7 +148,7 @@ _GLOBAL(flush_inval_dcache_range)
subfr8,r6,r4/* compute length */
add r8,r8,r5/* ensure we get enough */
lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
- srw.r8,r8,r9/* compute line count */
+ srd.r8,r8,r9/* compute line count */
beqlr /* nothing to do? */
sync
isync
[tip:irq/urgent] genirq/affinity: Create affinity mask for single vector
Commit-ID: 491beed3b102b6e6c0e7734200661242226e3933
Gitweb: https://git.kernel.org/tip/491beed3b102b6e6c0e7734200661242226e3933
Author: Ming Lei
AuthorDate: Mon, 5 Aug 2019 09:19:06 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 8 Aug 2019 08:47:55 +0200
genirq/affinity: Create affinity mask for single vector
Since commit c66d4bd110a1f8 ("genirq/affinity: Add new callback for
(re)calculating interrupt sets"), irq_create_affinity_masks() returns
NULL in case of single vector. This change has caused regression on some
drivers, such as lpfc.
The problem is that single vector requests can happen in some generic cases:
1) kdump kernel
2) irq vectors resource is close to exhaustion.
If in that situation the affinity mask for a single vector is not created,
every caller has to handle the special case.
There is no reason why the mask cannot be created, so remove the check for
a single vector and create the mask.
Fixes: c66d4bd110a1f8 ("genirq/affinity: Add new callback for (re)calculating
interrupt sets")
Signed-off-by: Ming Lei
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190805011906.5020-1-ming@redhat.com
---
kernel/irq/affinity.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 4352b08ae48d..6fef48033f96 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -251,11 +251,9 @@ irq_create_affinity_masks(unsigned int nvecs, struct
irq_affinity *affd)
* Determine the number of vectors which need interrupt affinities
* assigned. If the pre/post request exhausts the available vectors
* then nothing to do here except for invoking the calc_sets()
-* callback so the device driver can adjust to the situation. If there
-* is only a single vector, then managing the queue is pointless as
-* well.
+* callback so the device driver can adjust to the situation.
*/
- if (nvecs > 1 && nvecs > affd->pre_vectors + affd->post_vectors)
+ if (nvecs > affd->pre_vectors + affd->post_vectors)
affvecs = nvecs - affd->pre_vectors - affd->post_vectors;
else
affvecs = 0;
Re: [RFC][PATCH 12/13] sched/deadline: Introduce deadline servers
Hi Dietmar,
On 07/08/19 18:31, Dietmar Eggemann wrote:
> On 7/26/19 4:54 PM, Peter Zijlstra wrote:
> >
> >
> > Signed-off-by: Peter Zijlstra (Intel)
>
> [...]
>
> > @@ -889,6 +891,8 @@ static void update_curr(struct cfs_rq *c
> > trace_sched_stat_runtime(curtask, delta_exec, curr->vruntime);
> > cgroup_account_cputime(curtask, delta_exec);
> > account_group_exec_runtime(curtask, delta_exec);
> > + if (curtask->server)
> > + dl_server_update(curtask->server, delta_exec);
> > }
>
> I get a lockdep_assert_held(&rq->lock) related warning in start_dl_timer()
> when running the full stack.
>
> ...
> [0.530216] root domain span: 0-5 (max cpu_capacity = 1024)
> [0.538655] devtmpfs: initialized
> [0.556485] update_curr: rq mismatch rq[0] != rq[4]
> [0.561519] update_curr: rq mismatch rq[0] != rq[4]
> [0.566497] update_curr: rq mismatch rq[0] != rq[4]
> [0.571443] update_curr: rq mismatch rq[0] != rq[4]
> [0.576762] update_curr: rq mismatch rq[2] != rq[4]
> [0.581674] update_curr: rq mismatch rq[2] != rq[4]
> [0.586569] [ cut here ]
> [0.591220] WARNING: CPU: 2 PID: 2 at kernel/sched/deadline.c:916
> start_dl_timer+0x160/0x178
> [0.599686] Modules linked in:
> [0.602756] CPU: 2 PID: 2 Comm: kthreadd Tainted: GW
> 5.3.0-rc3-00013-ga33cf033cc99-dirty #64
> [0.612620] Hardware name: ARM Juno development board (r0) (DT)
> [0.618560] pstate: 6085 (nZCv daIf -PAN -UAO)
> [0.623369] pc : start_dl_timer+0x160/0x178
> [0.627572] lr : start_dl_timer+0x160/0x178
> [0.631768] sp : 10013cb0
> ...
> [0.715075] Call trace:
> [0.717531] start_dl_timer+0x160/0x178
> [0.721382] update_curr_dl_se+0x108/0x208
> [0.725494] dl_server_update+0x2c/0x38
> [0.729348] update_curr+0x1b4/0x3b8
> [0.732934] task_tick_fair+0x74/0xa88
> [0.736698] scheduler_tick+0x94/0x110
> [0.740461] update_process_times+0x48/0x60
> ...
>
> Seems to be related to the fact that the rq can change:
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e4c14851a34c..5e3130a200ec 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -891,8 +891,17 @@ static void update_curr(struct cfs_rq *cfs_rq)
> trace_sched_stat_runtime(curtask, delta_exec, curr->vruntime);
> cgroup_account_cputime(curtask, delta_exec);
> account_group_exec_runtime(curtask, delta_exec);
> - if (curtask->server)
> + if (curtask->server) {
> + struct rq *rq = rq_of(cfs_rq);
> + struct rq *rq2 = curtask->server->rq;
> +
> + if (rq != rq2) {
> + printk("update_curr: rq mismatch rq[%d] !=
> rq[%d]\n",
> + cpu_of(rq), cpu_of(rq2));
> + }
> +
> dl_server_update(curtask->server, delta_exec);
> + }
> }
>
> ...
Yeah, I actually noticed the same. Some debugging seems to point to
early boot spawning of kthreads. I can reliably for example attribute
this mismatch to ksoftirqd(s). It looks like they can avoid the
dl_server assignment in pick_next_task_dl() and this breaks things.
Still need to figure out why this happens and how to fix it, though.
Best,
Juri
Re: remove sn2, hpsim and ia64 machvecs
On Wed, Aug 07, 2019 at 04:07:37PM -0700, Luck, Tony wrote: > On Wed, Aug 07, 2019 at 01:26:17PM -0700, Luck, Tony wrote: > > Ugh! The rule to do the compression was in arch/ia64/hp/sim/boot/Makefile > > which went away as part of the deletion of hpsim. > > This fixes it ... should fold into the patch that dropped the > arch/ia64/hp/sim/boot/Makefile > > I just cut/pasted in those cmd_gzip and cmd_objcopy definitions > from elsewhere in the tree. It might be possible to simplify them. Lets keep it simple. I've picked this up for the hpsim removal patch.
[PATCH] perf db-export: Fix thread__exec_comm()
Threads synthesized from /proc have comms with a start time of zero, and
not marked as "exec". Currently, there can be 2 such comms. The first is
created by processing a synthesized fork event and is set to the parent's
comm string, and the second by processing a synthesized comm event set to
the thread's current comm string.
In the absence of an "exec" comm, thread__exec_comm() picks the last
(oldest) comm, which, in the case above, is the parent's comm string. For a
main thread, that is very probably wrong. Use the second-to-last in that
case.
This affects only db-export because it is the only user of
thread__exec_comm().
Example:
$ sudo perf record -a -o pt-a-sleep-1 -e intel_pt//u -- sleep 1
$ sudo chown ahunter pt-a-sleep-1
Before:
$ perf script -i pt-a-sleep-1 --itrace=bep -s
tools/perf/scripts/python/export-to-sqlite.py pt-a-sleep-1.db branches calls
$ sqlite3 -header -column pt-a-sleep-1.db 'select * from comm_threads_view'
comm_id command thread_id pid tid
-- -- -- -- --
1 swapper 1 0 0
2 rcu_sched 2 10 10
3 kthreadd3 78 78
5 sudo4 15180 15180
5 sudo5 15180 15182
7 kworker/4: 6 10335 10335
8 kthreadd7 55 55
10 systemd 8 865 865
10 systemd 9 865 875
13 perf10 15181 15181
15 sleep 10 15181 15181
16 kworker/3: 11 14179 14179
17 kthreadd12 29376 29376
19 systemd 13 746 746
21 systemd 14 401 401
23 systemd 15 879 879
23 systemd 16 879 945
25 kthreadd17 556 556
27 kworker/u1 18 14136 14136
28 kworker/u1 19 15021 15021
29 kthreadd20 509 509
31 systemd 21 836 836
31 systemd 22 836 967
33 systemd 23 11481148
33 systemd 24 11481163
35 kworker/2: 25 17988 17988
36 kworker/0: 26 13478 13478
After:
$ perf script -i pt-a-sleep-1 --itrace=bep -s
tools/perf/scripts/python/export-to-sqlite.py pt-a-sleep-1b.db branches calls
$ sqlite3 -header -column pt-a-sleep-1b.db 'select * from comm_threads_view'
comm_id command thread_id pid tid
-- -- -- -- --
1 swapper 1 0 0
2 rcu_sched 2 10 10
3 kswapd0 3 78 78
4 perf4 15180 15180
4 perf5 15180 15182
6 kworker/4: 6 10335 10335
7 kcompactd0 7 55 55
8 accounts-d 8 865 865
8 accounts-d 9 865 875
10 perf10 15181 15181
12 sleep 10 15181 15181
13 kworker/3: 11 14179 14179
14 kworker/1: 12 29376 29376
15 haveged 13 746 746
16 systemd-jo 14 401 401
17 NetworkMan 15 879 879
17 NetworkMan 16 879 945
19 irq/131-iw 17 556 556
20 kworker/u1 18 14136 14136
21 kworker/u1 19 15021 15021
22 kworker/u1 20 509 509
23 thermald21 836 836
23 thermald22 836 967
25 unity-sett 23 11481148
25 unity-sett 24 11481163
27 kworker/2: 25 17988 17988
28 kworker/0: 26 13478 13478
Signed-off-by: Adrian Hunter
Fixes: 65de51f93ebf ("perf tools: Identify which comms are from exec")
Cc: sta...@vger.kernel.org
---
tools/perf/util/thread.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 873ab505ca80..590793cc5142 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -214,14 +214,24 @@ struct comm *thread__comm(const struct thread *thread)
struct comm *thread__exec_comm(const struct thread *thread)
{
- struct comm *comm, *last = NULL;
+ struct comm *comm, *last = NULL, *second_last = NULL;
list_for_each_entry(comm, &thread->comm_list, list)
[GIT PULL] SMB3 Fixes
Please pull the following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d: Linux 5.3-rc3 (2019-08-04 18:40:12 -0700) are available in the Git repository at: git://git.samba.org/sfrench/cifs-2.6.git tags/5.3-rc3-smb3-fixes for you to fetch changes up to ee9d66182392695535cc9fccfcb40c16f72de2a9: SMB3: Kernel oops mounting a encryptData share with CONFIG_DEBUG_VIRTUAL (2019-08-05 22:50:38 -0500) six small SMB3 fixes, two for stable Pavel Shilovsky (2): SMB3: Fix deadlock in validate negotiate hits reconnect SMB3: Fix potential memory leak when processing compound chain Sebastien Tisserant (1): SMB3: Kernel oops mounting a encryptData share with CONFIG_DEBUG_VIRTUAL Steve French (3): cifs: fix rmmod regression in cifs.ko caused by force_sig changes smb3: send CAP_DFS capability during session setup smb3: update TODO list of missing features Documentation/filesystems/cifs/TODO | 26 -- fs/cifs/connect.c | 1 + fs/cifs/smb2ops.c | 39 ++- fs/cifs/smb2pdu.c | 7 ++- 4 files changed, 49 insertions(+), 24 deletions(-) -- Thanks, Steve
Re: [RFC PATCH v3 00/16] Core scheduling v3
On Tue, Aug 06, 2019 at 02:19:57PM -0700, Tim Chen wrote:
> +void account_core_idletime(struct task_struct *p, u64 exec)
> +{
> + const struct cpumask *smt_mask;
> + struct rq *rq;
> + bool force_idle, refill;
> + int i, cpu;
> +
> + rq = task_rq(p);
> + if (!sched_core_enabled(rq) || !p->core_cookie)
> + return;
I don't see why return here for untagged task. Untagged task can also
preempt tagged task and force a CPU thread enter idle state.
Untagged is just another tag to me, unless we want to allow untagged
task to coschedule with a tagged task.
> + cpu = task_cpu(p);
> + force_idle = false;
> + refill = true;
> + smt_mask = cpu_smt_mask(cpu);
> +
> + for_each_cpu(i, smt_mask) {
> + if (cpu == i)
> + continue;
> +
> + if (cpu_rq(i)->core_forceidle)
> + force_idle = true;
> +
> + /* Only refill if everyone has run out of allowance */
> + if (cpu_rq(i)->core_idle_allowance > 0)
> + refill = false;
> + }
> +
> + if (force_idle)
> + rq->core_idle_allowance -= (s64) exec;
> +
> + if (rq->core_idle_allowance < 0 && refill) {
> + for_each_cpu(i, smt_mask) {
> + cpu_rq(i)->core_idle_allowance += (s64)
> SCHED_IDLE_ALLOWANCE;
> + }
> + }
> +}
Re: [RT BUG] isolcpus causes sleeping function called from invalid context (4.19.59-rt24)
Hi, On 07/08/19 16:07, Steven Rostedt wrote: > On Mon, 5 Aug 2019 12:06:46 +0200 > Juri Lelli wrote: > > > This only happens if isolcpus are configured at boot. > > > > AFAIU, RT is reworking workqueues and 5.x-rt shouldn't suffer from this. > > As a matter of fact, I could verify that backporting the workqueue > > rework all-in change from 5.0-rt [1] fixes this problem. > > So you have backported this and it fixed the bug? Yeah. I did backport it to a downstream kernel and the splat is gone (plus I couldn't spot any other problems my backport might have introduced :). > > I'm thus wondering if there is any plan on backporting the rework to > > 4.19-rt stable, and if that patch has dependencies, or if any alternative > > fix might be found for this problem. > > I could do it after I fix the bug with 4.19.63 merge :-/ (which may be > related. Who knows). Ok, thanks! Best, Juri
Re: [f2fs-dev] [PATCH] f2fs: Fix build error while CONFIG_NLS=m
On 2019/8/8 14:18, Chao Yu wrote:
> Hi Haibing,
>
> Thanks for the patch!
>
> Out of curiosity, does Hulk Robot check linux-next git repo as well? This will
> be more valuable if the bug can be found during development of related patch?
Yes, Hulk Robot now do this on linux-next.git and linux.git every day.
>
> On 2019/8/8 10:02, YueHaibing wrote:
>> If CONFIG_F2FS_FS=y but CONFIG_NLS=m, building fails:
>>
>> fs/f2fs/file.o: In function `f2fs_ioctl':
>> file.c:(.text+0xb86f): undefined reference to `utf16s_to_utf8s'
>> file.c:(.text+0xe651): undefined reference to `utf8s_to_utf16s'
>>
>> Select CONFIG_NLS to fix this.
>>
>> Reported-by: Hulk Robot
>> Fixes: 61a3da4d5ef8 ("f2fs: support FS_IOC_{GET,SET}FSLABEL")
>> Signed-off-by: YueHaibing
>
> Reviewed-by: Chao Yu
>
> Thanks,
>
> .
>
Re: [PATCH] kernfs: fix memleak in kernel_ops_readdir()
On Wed, Aug 07, 2019 at 11:45:18AM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2019 at 06:29:28AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Tejun Heo [691231 23:00]:
> > > From: Andrea Arcangeli
> > >
> > > If getdents64 is killed or hits on segfault, it'll leave cgroups
> > > directories in sysfs pinned leaking memory because the kernfs node
> > > won't be freed on rmdir and the parent neither.
> >
> > Somehow this causes a regression in Linux next for me where I'm seeing
> > lots of sysfs entries now missing under /sys/bus/platform/devices.
> >
> > For example, I now only see one .serial entry show up in sysfs.
> > Things work again if I revert commit cc798c83898e ("kernfs: fix memleak
> > inkernel_ops_readdir()"). Any ideas why that would be?
> >
> > Below is a diff -u of ls /sys/bus/platform/devices for reference
> > showing the missing entries with cc798c83898e.
>
> Ugh, you're right. It can get double-put cuz ctx->pos is put by
> release too. Greg, sorry about the noise but can you please revert
> the patch? I'll look into why this looked like memory leak from
> slabinfo side.
Now reverted, thanks.
greg k-h
[PATCH v6 14/14] riscv: Make mmap allocation top-down by default
In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp fe:00 7187 /lib/libc-2.28.so 1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so 1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so 155567a000-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp fe:00 7187 /lib/libc-2.28.so 3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so 3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so 3ff7fdc000-3ff7fe2000 rw-p 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp fe:00 7193 /lib/ld-2.28.so 3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 3ff7fff000-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/riscv/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 59a4727ecd6c..87dc5370becb 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -54,6 +54,18 @@ config RISCV select EDAC_SUPPORT select ARCH_HAS_GIGANTIC_PAGE select ARCH_WANT_HUGE_PMD_SHARE if 64BIT + select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU + select HAVE_ARCH_MMAP_RND_BITS + +config ARCH_MMAP_RND_BITS_MIN + default 18 if 64BIT + default 8 + +# max bits determined by the following formula: +# VA_BITS - PAGE_SHIFT - 3 +config ARCH_MMAP_RND_BITS_MAX + default 24 if 64BIT # SV39 based + default 17 config MMU def_bool y -- 2.20.1
Re: Please revert c4b230ac34ce for today's linux-next
Hi Masahiro, On Thu, 8 Aug 2019 15:20:11 +0900 Masahiro Yamada wrote: > > I queued the following commit in linux-kbuild/fixes, > but it turned out to produce false-positive warnings for single-targets. > > commit c4b230ac34ce64bdd4006f5e0e9be880b8a4d0a5 (origin/fixes) > Author: Masahiro Yamada > Date: Tue Aug 6 19:03:23 2019 +0900 > > kbuild: show hint if subdir-y/m is used to visit module Makefile > > > If it is not too late, could you revert it for today's linux-next ? Just caught me in time :-) I have reverted it. -- Cheers, Stephen Rothwell pgphvrAEPSrOG.pgp Description: OpenPGP digital signature
[tip:x86/urgent] x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
Commit-ID: b059f801a937d164e03b33c1848bb3dca67c0b04
Gitweb: https://git.kernel.org/tip/b059f801a937d164e03b33c1848bb3dca67c0b04
Author: Nick Desaulniers
AuthorDate: Wed, 7 Aug 2019 15:15:33 -0700
Committer: Thomas Gleixner
CommitDate: Thu, 8 Aug 2019 08:25:53 +0200
x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
KBUILD_CFLAGS is very carefully built up in the top level Makefile,
particularly when cross compiling or using different build tools.
Resetting KBUILD_CFLAGS via := assignment is an antipattern.
The comment above the reset mentions that -pg is problematic. Other
Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when
CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of
the important KBUILD_CFLAGS then manually having to re-add them. Seems
also that __stack_chk_fail references are generated when using
CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG.
Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Reported-by: Vaibhav Rustagi
Suggested-by: Peter Zijlstra
Suggested-by: Thomas Gleixner
Signed-off-by: Nick Desaulniers
Signed-off-by: Thomas Gleixner
Tested-by: Vaibhav Rustagi
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190807221539.94583-2-ndesaulni...@google.com
---
arch/x86/purgatory/Makefile | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 91ef244026d2..8901a1f89cf5 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -20,11 +20,34 @@ KCOV_INSTRUMENT := n
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
-# sure how to relocate those. Like kexec-tools, use custom flags.
-
-KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes
-fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -Os -mcmodel=large
-KBUILD_CFLAGS += -m$(BITS)
-KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
+# sure how to relocate those.
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_sha256.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_purgatory.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_string.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_kexec-purgatory.o+= $(CC_FLAGS_FTRACE)
+endif
+
+ifdef CONFIG_STACKPROTECTOR
+CFLAGS_REMOVE_sha256.o += -fstack-protector
+CFLAGS_REMOVE_purgatory.o += -fstack-protector
+CFLAGS_REMOVE_string.o += -fstack-protector
+CFLAGS_REMOVE_kexec-purgatory.o+= -fstack-protector
+endif
+
+ifdef CONFIG_STACKPROTECTOR_STRONG
+CFLAGS_REMOVE_sha256.o += -fstack-protector-strong
+CFLAGS_REMOVE_purgatory.o += -fstack-protector-strong
+CFLAGS_REMOVE_string.o += -fstack-protector-strong
+CFLAGS_REMOVE_kexec-purgatory.o+= -fstack-protector-strong
+endif
+
+ifdef CONFIG_RETPOLINE
+CFLAGS_REMOVE_sha256.o += $(RETPOLINE_CFLAGS)
+CFLAGS_REMOVE_purgatory.o += $(RETPOLINE_CFLAGS)
+CFLAGS_REMOVE_string.o += $(RETPOLINE_CFLAGS)
+CFLAGS_REMOVE_kexec-purgatory.o+= $(RETPOLINE_CFLAGS)
+endif
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
$(call if_changed,ld)
[PATCH v6 13/14] mips: Use generic mmap top-down layout and brk randomization
mips uses a top-down layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for mips to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Signed-off-by: Alexandre Ghiti
Acked-by: Paul Burton
Reviewed-by: Kees Cook
Reviewed-by: Luis Chamberlain
---
arch/mips/Kconfig | 2 +-
arch/mips/include/asm/processor.h | 5 --
arch/mips/mm/mmap.c | 96 ---
3 files changed, 1 insertion(+), 102 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..4e85d7d2cf1a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -5,7 +5,6 @@ config MIPS
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
- select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
@@ -13,6 +12,7 @@ config MIPS
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/arch/mips/include/asm/processor.h
b/arch/mips/include/asm/processor.h
index aca909bd7841..fba18d4a9190 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -29,11 +29,6 @@
extern unsigned int vced_count, vcei_count;
-/*
- * MIPS does have an arch_pick_mmap_layout()
- */
-#define HAVE_ARCH_PICK_MMAP_LAYOUT 1
-
#ifdef CONFIG_32BIT
#ifdef CONFIG_KVM_GUEST
/* User space process size is limited to 1GB in KVM Guest Mode */
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d5106c26ac6a..00fe90c6db3e 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,49 +16,10 @@
#include
#include
#include
-#include
-#include
unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
-/* gap between mmap and stack */
-#define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((STACK_TOP)/6*5)
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = stack_guard_gap;
-
- /* Account for stack randomization if necessary */
- if (current->flags & PF_RANDOMIZE)
- pad += (STACK_RND_MASK << PAGE_SHIFT);
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
#define COLOUR_ALIGN(addr, pgoff) \
addr) + shm_align_mask) & ~shm_align_mask) +\
(((pgoff) << PAGE_SHIFT) & shm_align_mask))
@@ -156,63 +117,6 @@ unsigned long arch_get_unmapped_area_topdown(struct file
*filp,
addr0, len, pgoff, flags, DOWN);
}
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
- if (TASK_IS_32BIT_ADDR)
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
- else
-#endif /* CONFIG_COMPAT */
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
- return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
-static inline unsigned long brk_rnd(void)
-{
- unsigned long rnd = get_random_long();
-
- rnd = rnd << PAGE_SHIFT;
- /* 32MB for 32bit, 1GB for 64bit */
- if (!IS_ENABLED(CONFIG_64BIT)
[tip:x86/urgent] x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
Commit-ID: 4ce97317f41d38584fb93578e922fcd19e535f5b
Gitweb: https://git.kernel.org/tip/4ce97317f41d38584fb93578e922fcd19e535f5b
Author: Nick Desaulniers
AuthorDate: Wed, 7 Aug 2019 15:15:32 -0700
Committer: Thomas Gleixner
CommitDate: Thu, 8 Aug 2019 08:25:52 +0200
x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
Implementing memcpy and memset in terms of __builtin_memcpy and
__builtin_memset is problematic.
GCC at -O2 will replace calls to the builtins with calls to memcpy and
memset (but will generate an inline implementation at -Os). Clang will
replace the builtins with these calls regardless of optimization level.
$ llvm-objdump -dr arch/x86/purgatory/string.o | tail
0339 memcpy:
339: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
033b: R_X86_64_64 memcpy
343: ff e0 jmpq*%rax
0345 memset:
345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
0347: R_X86_64_64 memset
34f: ff e0
Such code results in infinite recursion at runtime. This is observed
when doing kexec.
Instead, reuse an implementation from arch/x86/boot/compressed/string.c.
This requires to implement a stub function for warn(). Also, Clang may
lower memcmp's that compare against 0 to bcmp's, so add a small definition,
too. See also: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Reported-by: Vaibhav Rustagi
Debugged-by: Vaibhav Rustagi
Debugged-by: Manoj Gupta
Suggested-by: Alistair Delva
Signed-off-by: Nick Desaulniers
Signed-off-by: Thomas Gleixner
Tested-by: Vaibhav Rustagi
Cc: sta...@vger.kernel.org
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=984056
Link: https://lkml.kernel.org/r/20190807221539.94583-1-ndesaulni...@google.com
---
arch/x86/boot/string.c | 8
arch/x86/purgatory/Makefile| 3 +++
arch/x86/purgatory/purgatory.c | 6 ++
arch/x86/purgatory/string.c| 23 ---
4 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 401e30ca0a75..8272a4492844 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -37,6 +37,14 @@ int memcmp(const void *s1, const void *s2, size_t len)
return diff;
}
+/*
+ * Clang may lower `memcmp == 0` to `bcmp == 0`.
+ */
+int bcmp(const void *s1, const void *s2, size_t len)
+{
+ return memcmp(s1, s2, len);
+}
+
int strcmp(const char *str1, const char *str2)
{
const unsigned char *s1 = (const unsigned char *)str1;
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 3cf302b26332..91ef244026d2 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -6,6 +6,9 @@ purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o
entry64.o string
targets += $(purgatory-y)
PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
+$(obj)/string.o: $(srctree)/arch/x86/boot/compressed/string.c FORCE
+ $(call if_changed_rule,cc_o_c)
+
$(obj)/sha256.o: $(srctree)/lib/sha256.c FORCE
$(call if_changed_rule,cc_o_c)
diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c
index 6d8d5a34c377..b607bda786f6 100644
--- a/arch/x86/purgatory/purgatory.c
+++ b/arch/x86/purgatory/purgatory.c
@@ -68,3 +68,9 @@ void purgatory(void)
}
copy_backup_region();
}
+
+/*
+ * Defined in order to reuse memcpy() and memset() from
+ * arch/x86/boot/compressed/string.c
+ */
+void warn(const char *msg) {}
diff --git a/arch/x86/purgatory/string.c b/arch/x86/purgatory/string.c
deleted file mode 100644
index 01ad43873ad9..
--- a/arch/x86/purgatory/string.c
+++ /dev/null
@@ -1,23 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Simple string functions.
- *
- * Copyright (C) 2014 Red Hat Inc.
- *
- * Author:
- * Vivek Goyal
- */
-
-#include
-
-#include "../boot/string.c"
-
-void *memcpy(void *dst, const void *src, size_t len)
-{
- return __builtin_memcpy(dst, src, len);
-}
-
-void *memset(void *dst, int c, size_t len)
-{
- return __builtin_memset(dst, c, len);
-}
[PATCH v6 12/14] mips: Replace arch specific way to determine 32bit task with generic version
Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition. Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index ff6ab87e9c56..d5106c26ac6a 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -17,6 +17,7 @@ #include #include #include +#include unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */ EXPORT_SYMBOL(shm_align_mask); @@ -191,7 +192,7 @@ static inline unsigned long brk_rnd(void) rnd = rnd << PAGE_SHIFT; /* 32MB for 32bit, 1GB for 64bit */ - if (TASK_IS_32BIT_ADDR) + if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task()) rnd = rnd & (SZ_32M - 1); else rnd = rnd & (SZ_1G - 1); -- 2.20.1
Re: [PATCH 3/3] kbuild: show hint if subdir-y/m is used to visit module Makefile
On Tue, Aug 6, 2019 at 7:03 PM Masahiro Yamada
wrote:
>
> Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead
> of $(MODVERDIR)/*.mod"), a module is no longer built in the following
> pattern:
>
> [Makefile]
> subdir-y := some-module
>
> [some-module/Makefile]
> obj-m := some-module.o
>
> You cannot write Makefile this way in upstream because modules.order is
> not correctly generated. subdir-y is used to descend to a sub-directory
> that builds tools, device trees, etc.
>
> For external modules, the modules order does not matter. So, the
> Makefile above was known to work.
>
> I believe the Makefile should be re-written as follows:
>
> [Makefile]
> obj-m := some-module/
>
> [some-module/Makefile]
> obj-m := some-module.o
>
> However, people will have no idea if their Makefile suddenly stops
> working. In fact, I received questions from multiple people.
>
> Show a warning if obj-m is specified in a Makefile visited by subdir-y
> or subdir-m.
>
> Cc: Jan Kiszka
> Cc: Tom Stonecypher
> Signed-off-by: Masahiro Yamada
> ---
This produces false-positive warnings for single-targets.
I will fix up as follows:
diff --git a/Makefile b/Makefile
index 0e37ad2f77bf..fac25e279da6 100644
--- a/Makefile
+++ b/Makefile
@@ -1783,7 +1783,7 @@ PHONY += /
/: ./
%/: prepare FORCE
- $(Q)$(MAKE) KBUILD_MODULES=1 $(build)=$(build-dir)
+ $(Q)$(MAKE) KBUILD_MODULES=1 $(build)=$(build-dir) need-modorder=1
# FIXME Should go into a make.lib or something
# ===
>
> scripts/Makefile.build | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 37a1d2cd49d4..4a26c7ed9198 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -52,6 +52,13 @@ ifndef obj
> $(warning kbuild: Makefile.build is included improperly)
> endif
>
> +ifeq ($(need-modorder),)
> +ifneq ($(obj-m),)
> +$(warning $(patsubst %.o,'%.ko',$(obj-m)) will not be built even though
> obj-m is specified.)
> +$(warning You cannot use subdir-y/m to visit a module Makefile. Use obj-y/m
> instead.)
> +endif
> +endif
> +
> # ===
>
> ifneq ($(strip $(lib-y) $(lib-m) $(lib-)),)
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
[PATCH v6 11/14] mips: Adjust brk randomization offset to fit generic version
This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index a7e84b2e71d7..ff6ab87e9c56 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -16,6 +16,7 @@ #include #include #include +#include unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */ EXPORT_SYMBOL(shm_align_mask); @@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void) unsigned long rnd = get_random_long(); rnd = rnd << PAGE_SHIFT; - /* 8MB for 32bit, 256MB for 64bit */ + /* 32MB for 32bit, 1GB for 64bit */ if (TASK_IS_32BIT_ADDR) - rnd = rnd & 0x7ful; + rnd = rnd & (SZ_32M - 1); else - rnd = rnd & 0xffful; + rnd = rnd & (SZ_1G - 1); return rnd; } -- 2.20.1
[PATCH v3] arm64: mm: print hexadecimal EC value in mem_abort_decode()
This change prints the hexadecimal EC value in mem_abort_decode(),
which makes it easier to lookup the corresponding EC in
the ARM Architecture Reference Manual.
The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
faults") prints useful information when memory abort occurs. It would
be easier to lookup "0x25" instead of "DABT" in the document. Then we
can check the corresponding ISS.
For example:
Current infoDocument
EC Exception class
"CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
"ASIMD" 0x7 "Access to SIMD or floating-point..."
"DABT (current EL)" 0x25"Data Abort taken without..."
...
Before:
Unable to handle kernel paging request at virtual address c000
Mem abort info:
ESR = 0x9646
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0046
CM = 0, WnR = 1
After:
Unable to handle kernel paging request at virtual address c000
Mem abort info:
ESR = 0x9646
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0046
CM = 0, WnR = 1
Change since v1:
print "EC" instead of "Exception class"
print EC in fixwidth
Change since v2:
add acked-by tag from Mark since v2 implemented the suggestion in v1
add reviewed-by tag from Anshuman in v2
Acked-by: Mark Rutland
Reviewed-by: Anshuman Khandual
Cc: Mark Rutland
Cc: Anshuman Khandual
Cc: James Morse
Signed-off-by: Miles Chen
---
arch/arm64/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index cfd65b63f36f..ad4980a27edb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
pr_alert("Mem abort info:\n");
pr_alert(" ESR = 0x%08x\n", esr);
- pr_alert(" Exception class = %s, IL = %u bits\n",
-esr_get_class_string(esr),
+ pr_alert(" EC = 0x%02lx: %s, IL = %u bits\n",
+ESR_ELx_EC(esr), esr_get_class_string(esr),
(esr & ESR_ELx_IL) ? 32 : 16);
pr_alert(" SET = %lu, FnV = %lu\n",
(esr & ESR_ELx_SET_MASK) >> ESR_ELx_SET_SHIFT,
--
2.18.0
[PATCH v6 10/14] mips: Use STACK_TOP when computing mmap base address
mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Acked-by: Paul Burton Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index f5c778113384..a7e84b2e71d7 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -22,7 +22,7 @@ EXPORT_SYMBOL(shm_align_mask); /* gap between mmap and stack */ #define MIN_GAP(128*1024*1024UL) -#define MAX_GAP((TASK_SIZE)/6*5) +#define MAX_GAP((STACK_TOP)/6*5) #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) static int mmap_is_legacy(struct rlimit *rlim_stack) @@ -54,7 +54,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) else if (gap > MAX_GAP) gap = MAX_GAP; - return PAGE_ALIGN(TASK_SIZE - gap - rnd); + return PAGE_ALIGN(STACK_TOP - gap - rnd); } #define COLOUR_ALIGN(addr, pgoff) \ -- 2.20.1
RE: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"
> -Original Message-
> From: Kai-Heng Feng
> Sent: Thursday, August 08, 2019 1:45 AM
> To: Huang, Ray
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; amd-gfx list ;
> dri-de...@lists.freedesktop.org; LKML ;
> Anthony Wong
> Subject: Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series
> (v2)"
>
> Hi Ray,
>
> at 00:03, Huang, Ray wrote:
>
> > May I know the all firmware version in your system?
Seems to the issue we encountered with IOMMU enabled. Could you please disable
iommu in SBIOS or GRUB?
Thanks,
Ray
>
> # cat amdgpu_firmware_info
> VCE feature version: 0, firmware version: 0x
> UVD feature version: 0, firmware version: 0x
> MC feature version: 0, firmware version: 0x
> ME feature version: 40, firmware version: 0x0099
> PFP feature version: 40, firmware version: 0x00ae
> CE feature version: 40, firmware version: 0x004d
> RLC feature version: 1, firmware version: 0x0213
> RLC SRLC feature version: 1, firmware version: 0x0001
> RLC SRLG feature version: 1, firmware version: 0x0001
> RLC SRLS feature version: 1, firmware version: 0x0001
> MEC feature version: 40, firmware version: 0x018b
> MEC2 feature version: 40, firmware version: 0x018b
> SOS feature version: 0, firmware version: 0x
> ASD feature version: 0, firmware version: 0x001ad4d4
> TA XGMI feature version: 0, firmware version: 0x
> TA RAS feature version: 0, firmware version: 0x
> SMC feature version: 0, firmware version: 0x1e44
> SDMA0 feature version: 41, firmware version: 0x00a9
> VCN feature version: 0, firmware version: 0x0110901c
> DMCU feature version: 0, firmware version: 0x
> VBIOS version: 113-RAVEN-103
>
> Kai-Heng
>
> >
> > Thanks,
> > Ray
> >
> > From: Kai-Heng Feng
> > Sent: Wednesday, August 7, 2019 8:50 PM
> > To: Huang, Ray
> > Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); amd-
> gfx
> > list; dri-de...@lists.freedesktop.org; LKML; Anthony Wong
> > Subject: [Regression] "drm/amdgpu: enable gfxoff again on raven series
> > (v2)"
> >
> > Hi,
> >
> > After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven
> series
> > (v2)”), browsers on Raven Ridge systems cause serious corruption like this:
> > https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-
> 08-07%2004-20-34.png
> >
> > Firmwares for Raven Ridge is up-to-date.
> >
> > Kai-Heng
>
Re: [Sound-open-firmware] [PATCH v2 3/5] ASoC: SOF: Add DT DSP device support
On Wed, Aug 7, 2019 at 6:28 PM Daniel Baluta wrote:
>
> On Wed, Aug 7, 2019 at 6:22 PM Pierre-Louis Bossart
> wrote:
> >
> >
> > +static int sof_dt_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + const struct sof_dev_desc *desc;
> > + /*TODO: create a generic snd_soc_xxx_mach */
> > + struct snd_soc_acpi_mach *mach;
> > >>>
> > >>> I wonder if you really need to use the same structures. For Intel we get
> > >>> absolutely zero info from the firmware so rely on an ACPI codec ID as a
> > >>> key to find information on which firmware and topology to use, and which
> > >>> machine driver to load. You could have all this information in a DT
> > >>> blob?
> > >>
> > >> Yes. I see your point. I will still need to make a generic structure for
> > >> snd_soc_acpi_mach so that everyone can use sof_nocodec_setup function.
> > >>
> > >> Maybe something like this:
> > >>
> > >> struct snd_soc_mach {
> > >>union {
> > >>struct snd_soc_acpi_mach acpi_mach;
> > >>struct snd_soc_of_mach of_mach;
> > >>}
> > >> };
> > >>
> > >> and then change the prototype of sof_nocodec_setup.
> > >
> > > Hi Pierre,
> > >
> > > I fixed all the comments except the one above. Replacing snd_soc_acpi_mach
> > > with a generic snd_soc_mach is not trivial task.
> > >
> > > I wonder if it is acceptable to get the initial patches as they are
> > > now and later switch to
> > > generic ACPI/OF abstraction.
> > >
> > > Asking this because for the moment on the i.MX side I have only
> > > implemented no codec
> > > version and we don't probe any of the machine drivers we have.
> > >
> > > So, there is this only one member of snd_soc_acpi_mach that imx
> > > version is making use of:
> > >
> > >mach->drv_name = "sof-nocodec";
> > >
> > > That's all.
> > >
> > > I think the change as it is now is very clean and non-intrusive. Later
> > > we will get options to
> > > read firmware name and stuff from DT.
> > >
> > > Anyhow, I don't think we can get rid of snd_dev_desc structure on
> > > i.MX. This will be used
> > > to store the information read from DT:
> > >
> > > static struct sof_dev_desc sof_of_imx8qxp_desc = {
> > > » .default_fw_path = "imx/sof",
> > > » .default_tplg_path = "imx/sof-tplg",
> > > » .nocodec_fw_filename = "sof-imx8.ri",
> > > » .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
> > > » .ops = &sof_imx8_ops,
> > > };
> > >
> > > For the moment we will only use the default values.
> >
> > Yes, that's fine for now. If you don't have a real machine driver then
> > there's nothing urgent to change.
> >
> > Is the new version on GitHub?
>
> Not yet, will push it today and ping you.
PR updated: https://github.com/thesofproject/linux/pull/1048
[PATCH v6 09/14] mips: Properly account for stack randomization and stack guard gap
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com
Signed-off-by: Alexandre Ghiti
Acked-by: Kees Cook
Acked-by: Paul Burton
Reviewed-by: Luis Chamberlain
---
arch/mips/mm/mmap.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d79f2b432318..f5c778113384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -21,8 +21,9 @@ unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches
*/
EXPORT_SYMBOL(shm_align_mask);
/* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MIN_GAP(128*1024*1024UL)
+#define MAX_GAP((TASK_SIZE)/6*5)
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
static int mmap_is_legacy(struct rlimit *rlim_stack)
{
@@ -38,6 +39,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
{
unsigned long gap = rlim_stack->rlim_cur;
+ unsigned long pad = stack_guard_gap;
+
+ /* Account for stack randomization if necessary */
+ if (current->flags & PF_RANDOMIZE)
+ pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+ /* Values close to RLIM_INFINITY can overflow. */
+ if (gap + pad > gap)
+ gap += pad;
if (gap < MIN_GAP)
gap = MIN_GAP;
--
2.20.1
[PATCH v6 08/14] arm: Use generic mmap top-down layout and brk randomization
arm uses a top-down mmap layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for arm to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Note that it is safe to remove STACK_RND_MASK since it matches the default
value.
Signed-off-by: Alexandre Ghiti
Acked-by: Kees Cook
Reviewed-by: Luis Chamberlain
---
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/processor.h | 2 --
arch/arm/kernel/process.c| 5 ---
arch/arm/mm/mmap.c | 62
4 files changed, 1 insertion(+), 70 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..81b08b027e4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
- select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
@@ -30,6 +29,7 @@ config ARM
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 20c2f42454b8..614bf829e454 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -140,8 +140,6 @@ static inline void prefetchw(const void *ptr)
#endif
#endif
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
#endif
#endif /* __ASM_ARM_PROCESSOR_H */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f934a6739fc0..9485acc520a4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -319,11 +319,6 @@ unsigned long get_wchan(struct task_struct *p)
return 0;
}
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
- return randomize_page(mm->brk, 0x0200);
-}
-
#ifdef CONFIG_MMU
#ifdef CONFIG_KUSER_HELPERS
/*
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 0b94b674aa91..b8d912ac9e61 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -17,43 +17,6 @@
addr)+SHMLBA-1)&~(SHMLBA-1)) + \
(((pgoff)<> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = stack_guard_gap;
-
- /* Account for stack randomization if necessary */
- if (current->flags & PF_RANDOMIZE)
- pad += (STACK_RND_MASK << PAGE_SHIFT);
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
/*
* We need to ensure that shared mappings are correctly aligned to
* avoid aliasing issues with VIPT caches. We need to ensure that
@@ -181,31 +144,6 @@ arch_get_unmapped_area_topdown(struct file *filp, const
unsigned long addr0,
return addr;
}
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
- return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
/*
* You really shouldn't be using read() or write() on /dev/mem. This
* might go away in the future.
--
2.20.1
[PATCH v6 07/14] arm: Use STACK_TOP when computing mmap base address
mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index bff3d00bda5b..0b94b674aa91 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c @@ -19,7 +19,7 @@ /* gap between mmap and stack */ #define MIN_GAP(128*1024*1024UL) -#define MAX_GAP((TASK_SIZE)/6*5) +#define MAX_GAP((STACK_TOP)/6*5) #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) static int mmap_is_legacy(struct rlimit *rlim_stack) @@ -51,7 +51,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) else if (gap > MAX_GAP) gap = MAX_GAP; - return PAGE_ALIGN(TASK_SIZE - gap - rnd); + return PAGE_ALIGN(STACK_TOP - gap - rnd); } /* -- 2.20.1
[PATCH v6 06/14] arm: Properly account for stack randomization and stack guard gap
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com
Signed-off-by: Alexandre Ghiti
Acked-by: Kees Cook
Reviewed-by: Luis Chamberlain
---
arch/arm/mm/mmap.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index f866870db749..bff3d00bda5b 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -18,8 +18,9 @@
(((pgoff)<> (PAGE_SHIFT - 12))
static int mmap_is_legacy(struct rlimit *rlim_stack)
{
@@ -35,6 +36,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
{
unsigned long gap = rlim_stack->rlim_cur;
+ unsigned long pad = stack_guard_gap;
+
+ /* Account for stack randomization if necessary */
+ if (current->flags & PF_RANDOMIZE)
+ pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+ /* Values close to RLIM_INFINITY can overflow. */
+ if (gap + pad > gap)
+ gap += pad;
if (gap < MIN_GAP)
gap = MIN_GAP;
--
2.20.1
[PATCH v6 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout
This commits selects ARCH_HAS_ELF_RANDOMIZE when an arch uses the generic
topdown mmap layout functions so that this security feature is on by
default.
Note that this commit also removes the possibility for arm64 to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Signed-off-by: Alexandre Ghiti
Acked-by: Catalin Marinas
Acked-by: Kees Cook
Reviewed-by: Christoph Hellwig
Reviewed-by: Luis Chamberlain
---
arch/Kconfig| 1 +
arch/arm64/Kconfig | 1 -
arch/arm64/kernel/process.c | 8
mm/util.c | 11 +--
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index a0bb6fa4d381..d4c1f0551dfe 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -705,6 +705,7 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
bool
depends on MMU
+ select ARCH_HAS_ELF_RANDOMIZE
config HAVE_COPY_THREAD_TLS
bool
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 14a194e63458..399f595ef852 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -16,7 +16,6 @@ config ARM64
select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
- select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f674f28df663..8ddc2471b054 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -548,14 +548,6 @@ unsigned long arch_align_stack(unsigned long sp)
return sp & ~0xf;
}
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
- if (is_compat_task())
- return randomize_page(mm->brk, SZ_32M);
- else
- return randomize_page(mm->brk, SZ_1G);
-}
-
/*
* Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
*/
diff --git a/mm/util.c b/mm/util.c
index 0781e5575cb3..16f1e56e2996 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -321,7 +321,15 @@ unsigned long randomize_stack_top(unsigned long stack_top)
}
#ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
-#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+ /* Is the current task 32bit ? */
+ if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
+ return randomize_page(mm->brk, SZ_32M);
+
+ return randomize_page(mm->brk, SZ_1G);
+}
+
unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;
@@ -335,7 +343,6 @@ unsigned long arch_mmap_rnd(void)
return rnd << PAGE_SHIFT;
}
-#endif /* CONFIG_ARCH_HAS_ELF_RANDOMIZE */
static int mmap_is_legacy(struct rlimit *rlim_stack)
{
--
2.20.1
[PATCH v2] team: Add vlan tx offload to hw_enc_features
We should also enable team's vlan tx offload in hw_enc_features,
pass the vlan packets to the slave devices with vlan tci, let the
slave handle vlan tunneling offload implementation.
Fixes: 3268e5cb494d ("team: Advertise tunneling offload features")
Signed-off-by: YueHaibing
---
v2: fix commit log typo
---
drivers/net/team/team.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index abfa0da..e8089de 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1004,6 +1004,8 @@ static void __team_compute_features(struct team *team)
team->dev->vlan_features = vlan_features;
team->dev->hw_enc_features = enc_features | NETIF_F_GSO_ENCAP_ALL |
+NETIF_F_HW_VLAN_CTAG_TX |
+NETIF_F_HW_VLAN_STAG_TX |
NETIF_F_GSO_UDP_L4;
team->dev->hard_header_len = max_hard_header_len;
--
2.7.4
[PATCH v6 04/14] arm64, mm: Move generic mmap layout functions to mm
arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that can be set by other architectures to benefit from those functions.
Note that this new config depends on MMU being enabled, if selected
without MMU support, a warning will be thrown.
Suggested-by: Christoph Hellwig
Signed-off-by: Alexandre Ghiti
Acked-by: Catalin Marinas
Acked-by: Kees Cook
Reviewed-by: Christoph Hellwig
Reviewed-by: Luis Chamberlain
---
arch/Kconfig | 10
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 2 -
arch/arm64/mm/mmap.c | 76 -
kernel/sysctl.c| 6 ++-
mm/util.c | 78 +-
6 files changed, 92 insertions(+), 81 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..a0bb6fa4d381 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -696,6 +696,16 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
and vice-versa 32-bit applications to call 64-bit mmap().
Required for applications doing different bitness syscalls.
+# This allows to use a set of generic functions to determine mmap base
+# address by giving priority to top-down scheme only if the process
+# is not in legacy mode (compat task, unlimited stack size or
+# sysctl_legacy_va_layout).
+# Architecture that selects this option can provide its own version of:
+# - STACK_RND_MASK
+config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
+ bool
+ depends on MMU
+
config HAVE_COPY_THREAD_TLS
bool
help
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..14a194e63458 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -72,6 +72,7 @@ config ARM64
select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 || CC_IS_CLANG
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES
&& !ARM64_VA_BITS_36)
select ARCH_HAS_UBSAN_SANITIZE_ALL
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 844e2964b0f5..65e2de00913f 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -281,8 +281,6 @@ static inline void spin_lock_prefetch(const void *ptr)
"nop") : : "p" (ptr));
}
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
#endif
extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index e4acaead67de..3028bacbc4e9 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -20,82 +20,6 @@
#include
-/*
- * Leave enough space between the mmap area and the stack to honour ulimit in
- * the face of randomisation.
- */
-#define MIN_GAP (SZ_128M)
-#define MAX_GAP(STACK_TOP/6*5)
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
- if (is_compat_task())
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
- else
-#endif
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
- return rnd << PAGE_SHIFT;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = stack_guard_gap;
-
- /* Account for stack randomization if necessary */
- if (current->flags & PF_RANDOMIZE)
- pad += (STACK_RND_MASK << PAGE_SHIFT);
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
-/*
- * This function, called very early during the creation of a new process VM
- * image, sets up which VM layout function to use:
- */
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- /*
-* Fall back to the standard layout if the personality bit is set, or
-* if the expected stack growth is unlimited:
-*/
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-
Re: [PATCH 1/3] mm/mlock.c: convert put_page() to put_user_page*()
On Wed 07-08-19 16:32:08, John Hubbard wrote: > On 8/7/19 4:01 AM, Michal Hocko wrote: > > On Mon 05-08-19 15:20:17, john.hubb...@gmail.com wrote: > >> From: John Hubbard > >> > >> For pages that were retained via get_user_pages*(), release those pages > >> via the new put_user_page*() routines, instead of via put_page() or > >> release_pages(). > > > > Hmm, this is an interesting code path. There seems to be a mix of pages > > in the game. We get one page via follow_page_mask but then other pages > > in the range are filled by __munlock_pagevec_fill and that does a direct > > pte walk. Is using put_user_page correct in this case? Could you explain > > why in the changelog? > > > > Actually, I think follow_page_mask() gets all the pages, right? And the > get_page() in __munlock_pagevec_fill() is there to allow a pagevec_release() > later. Maybe I am misreading the code (looking at Linus tree) but munlock_vma_pages_range calls follow_page for the start address and then if not THP tries to fill up the pagevec with few more pages (up to end), do the shortcut via manual pte walk as an optimization and use generic get_page there. -- Michal Hocko SUSE Labs
RE: [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
Hi Anshuman
Thanks for the comments, please see my comments below
> -Original Message-
> From: Anshuman Khandual
> Sent: 2019年8月8日 13:19
> To: Justin He (Arm Technology China) ; Catalin
> Marinas ; Will Deacon ;
> Mark Rutland ; James Morse
>
> Cc: Christoffer Dall ; Punit Agrawal
> ; Qian Cai ; Jun Yao
> ; Alex Van Brunt ;
> Robin Murphy ; Thomas Gleixner
> ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in
> pte_mkdevmap on arm64
>
[...]
> > diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> > index 5fdcfe237338..e09760ece844 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
> >
> > static inline pte_t pte_mkdevmap(pte_t pte)
> > {
> > - return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
> > + return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
> > }
> >
> > static inline void set_pte(pte_t *ptep, pte_t pte)
> > @@ -396,7 +396,10 @@ static inline int pmd_protnone(pmd_t pmd)
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > #define pmd_devmap(pmd)pte_devmap(pmd_pte(pmd))
> > #endif
> > -#define pmd_mkdevmap(pmd)
> pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
> > +static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> > +{
> > + return pte_pmd(set_pte_bit(pmd_pte(pmd),
> __pgprot(PTE_DEVMAP)));
> > +}
>
> Though I could see other platforms like powerpc and x86 following same
> approach (DEVMAP + SPECIAL) for pte so that it checks positive for
> pte_special() but then just DEVMAP for pmd which could never have a
> pmd_special(). But a more fundamental question is - why should a devmap
> be a special pte as well ?
IIUC, special pte bit make things handling easier compare with those arches
which
have no special bit. The memory codes will regard devmap page as a special one
compared with normal page.
Devmap page structure can be stored in ram/pmem/none.
>
> Also in vm_normal_page() why cannot it tests for pte_devmap() before it
> starts looking for CONFIG_ARCH_HAS_PTE_SPECIAL. Is this the only path
> for
AFAICT, yes, but it changes to much besides arm codes. 😊
> which we need to set SPECIAL bit on a devmap pte or there are other paths
> where this semantics is assumed ?
No idea
--
Cheers,
Justin (Jia He)
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
On 08/08/2019 11:31 AM, Miles Chen wrote:
> On Thu, 2019-08-08 at 11:19 +0530, Anshuman Khandual wrote:
>>
>> On 08/07/2019 06:03 AM, Miles Chen wrote:
>>> This change prints the hexadecimal EC value in mem_abort_decode(),
>>> which makes it easier to lookup the corresponding EC in
>>> the ARM Architecture Reference Manual.
>>>
>>> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
>>> faults") prints useful information when memory abort occurs. It would
>>> be easier to lookup "0x25" instead of "DABT" in the document. Then we
>>> can check the corresponding ISS.
>>>
>>> For example:
>>> Current infoDocument
>>> EC Exception class
>>> "CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
>>> "ASIMD" 0x7 "Access to SIMD or floating-point..."
>>> "DABT (current EL)" 0x25"Data Abort taken without..."
>>> ...
>>>
>>> Before:
>>> Unable to handle kernel paging request at virtual address c000
>>> Mem abort info:
>>> ESR = 0x9646
>>> Exception class = DABT (current EL), IL = 32 bits
>>> SET = 0, FnV = 0
>>> EA = 0, S1PTW = 0
>>> Data abort info:
>>> ISV = 0, ISS = 0x0046
>>> CM = 0, WnR = 1
>>>
>>> After:
>>> Unable to handle kernel paging request at virtual address c000
>>> Mem abort info:
>>> ESR = 0x9646
>>> EC = 0x25: DABT (current EL), IL = 32 bits
>>> SET = 0, FnV = 0
>>> EA = 0, S1PTW = 0
>>> Data abort info:
>>> ISV = 0, ISS = 0x0046
>>> CM = 0, WnR = 1
>>>
>>> Change since v1:
>>> print "EC" instead of "Exception class"
>>> print EC in fixwidth
>>>
>>> Cc: Mark Rutland
>>> Cc: Anshuman Khandual
>>> Cc: James Morse
>>> Signed-off-by: Miles Chen
>>
>> This version implements the suggestion, hence it should have
>> also contained acked-by tag from Mark from earlier version.
>>
>
> No problem. Sorry for not including the tag.
> I was not sure if I should add the acked-by tag from Mark in patch v2.
Yeah because V2 has now implemented the suggestion as required for
getting the tag per Mark in V1.
>
>> Reviewed-by: Anshuman Khandual
>
> If I send patch v3, I should include acked-by tag from Mark and
> Reviewed-by tag from you, right?
Right.
[PATCH v6 03/14] arm64: Consider stack randomization for mmap base only when necessary
Do not offset mmap base address because of stack randomization if
current task does not want randomization.
Note that x86 already implements this behaviour.
Signed-off-by: Alexandre Ghiti
Acked-by: Catalin Marinas
Acked-by: Kees Cook
Reviewed-by: Christoph Hellwig
Reviewed-by: Luis Chamberlain
---
arch/arm64/mm/mmap.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index bb0140afed66..e4acaead67de 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -54,7 +54,11 @@ unsigned long arch_mmap_rnd(void)
static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
{
unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = (STACK_RND_MASK << PAGE_SHIFT) + stack_guard_gap;
+ unsigned long pad = stack_guard_gap;
+
+ /* Account for stack randomization if necessary */
+ if (current->flags & PF_RANDOMIZE)
+ pad += (STACK_RND_MASK << PAGE_SHIFT);
/* Values close to RLIM_INFINITY can overflow. */
if (gap + pad > gap)
--
2.20.1
[PATCH v6 02/14] arm64: Make use of is_compat_task instead of hardcoding this test
Each architecture has its own way to determine if a task is a compat task, by using is_compat_task in arch_mmap_rnd, it allows more genericity and then it prepares its moving to mm/. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- arch/arm64/mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c index b050641b5139..bb0140afed66 100644 --- a/arch/arm64/mm/mmap.c +++ b/arch/arm64/mm/mmap.c @@ -43,7 +43,7 @@ unsigned long arch_mmap_rnd(void) unsigned long rnd; #ifdef CONFIG_COMPAT - if (test_thread_flag(TIF_32BIT)) + if (is_compat_task()) rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1); else #endif -- 2.20.1
Re: [PATCH] sound: fix a memory leak bug
On Thu, 08 Aug 2019 07:15:21 +0200, Wenwen Wang wrote: > > In sound_insert_unit(), the controlling structure 's' is allocated through > kmalloc(). Then it is added to the sound driver list by invoking > __sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is > removed from the list through __sound_remove_unit(). If 'index' is not less > than 0, -EBUSY is returned to indicate the error. However, 's' is not > deallocated on this execution path, leading to a memory leak bug. > > To fix the above issue, free 's' before -EBUSY is returned. > > Signed-off-by: Wenwen Wang Oh, it's a really old bug. Applied now. Thanks! Takashi
Re: [PATCH net] net: phy: rtl8211f: do a double read to get real time link status
On 2019/8/8 14:11, Heiner Kallweit wrote: > On 08.08.2019 03:15, Yonglong Liu wrote: >> >> >> On 2019/8/8 0:47, Heiner Kallweit wrote: >>> On 07.08.2019 15:16, Yonglong Liu wrote: [ 27.232781] hns3 :bd:00.3 eth7: net open [ 27.237303] 8021q: adding VLAN 0 to HW filter on device eth7 [ 27.242972] IPv6: ADDRCONF(NETDEV_CHANGE): eth7: link becomes ready [ 27.29] hns3 :bd:00.3: invalid speed (-1) [ 27.253904] hns3 :bd:00.3 eth7: failed to adjust link. [ 27.259379] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state change UP -> RUNNING [ 27.924903] hns3 :bd:00.3 eth7: link up [ 28.280479] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state change RUNNING -> NOLINK [ 29.208452] hns3 :bd:00.3 eth7: link down [ 32.376745] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state change NOLINK -> RUNNING [ 33.208448] hns3 :bd:00.3 eth7: link up [ 35.253821] hns3 :bd:00.3 eth7: net stop [ 35.258270] hns3 :bd:00.3 eth7: link down When using rtl8211f in polling mode, may get a invalid speed, because of reading a fake link up and autoneg complete status immediately after starting autoneg: ifconfig-1176 [007] 27.232763: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x00 val:0x1040 kworker/u257:1-670 [015] 27.232805: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x04 val:0x01e1 kworker/u257:1-670 [015] 27.232815: mdio_access: mii-:bd:00.3 write phy:0x07 reg:0x04 val:0x05e1 kworker/u257:1-670 [015] 27.232869: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad kworker/u257:1-670 [015] 27.232904: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x09 val:0x0200 kworker/u257:1-670 [015] 27.232940: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x00 val:0x1040 kworker/u257:1-670 [015] 27.232949: mdio_access: mii-:bd:00.3 write phy:0x07 reg:0x00 val:0x1240 kworker/u257:1-670 [015] 27.233003: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad kworker/u257:1-670 [015] 27.233039: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x0a val:0x3002 kworker/u257:1-670 [015] 27.233074: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x09 val:0x0200 kworker/u257:1-670 [015] 27.233110: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x05 val:0x kworker/u257:1-670 [000] 28.280475: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x7989 kworker/u257:1-670 [000] 29.304471: mdio_access: mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x7989 According to the datasheet of rtl8211f, to get the real time link status, need to read MII_BMSR twice. This patch add a read_status hook for rtl8211f, and do a fake phy_read before genphy_read_status(), so that can get real link status in genphy_read_status(). Signed-off-by: Yonglong Liu --- drivers/net/phy/realtek.c | 13 + 1 file changed, 13 insertions(+) >>> Is this an accidental resubmit? Because we discussed this in >>> https://marc.info/?t=15641350993&r=1&w=2 and a fix has >>> been applied already. >>> >>> Heiner >>> >>> . >>> >> >> In https://marc.info/?t=15641350993&r=1&w=2 , the invalid speed >> recurrence rate is almost 100%, and I had test the solution about >> 5 times and it works. But yesterday it happen again suddenly, and than >> I fount that the recurrence rate reduce to 10%. This time we get 0x79ad >> after autoneg started which is not 0x798d from last discussion. >> >> >> > OK, I'll have a look. > However the approach is wrong. The double read is related to the latching > of link-down events. This is done by all PHY's and not specific to RT8211F. > Also it's not related to the problem. I assume any sufficient delay would > do instead of the read. > > . > So you will send a new patch to fix this problem? I am waiting for it, and can do a full test this time.
Please revert c4b230ac34ce for today's linux-next
Hi Stephen, I queued the following commit in linux-kbuild/fixes, but it turned out to produce false-positive warnings for single-targets. commit c4b230ac34ce64bdd4006f5e0e9be880b8a4d0a5 (origin/fixes) Author: Masahiro Yamada Date: Tue Aug 6 19:03:23 2019 +0900 kbuild: show hint if subdir-y/m is used to visit module Makefile If it is not too late, could you revert it for today's linux-next ? -- Best Regards Masahiro Yamada
Re: [PATCH v5 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure
On 2019/8/7 21:04, Michael Ellerman wrote: Jason Yan writes: This patch add support to boot kernel from places other than KERNELBASE. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. So to be 100% clear you are randomising the location of the kernel in virtual and physical space, by the same amount, and retaining the 1:1 linear mapping. 100% right :) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 77f6ebf97113..755378887912 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -548,6 +548,17 @@ config RELOCATABLE setting can still be useful to bootwrappers that need to know the load address of the kernel (eg. u-boot/mkimage). +config RANDOMIZE_BASE + bool "Randomize the address of the kernel image" + depends on (FSL_BOOKE && FLATMEM && PPC32) + select RELOCATABLE I think this should depend on RELOCATABLE, rather than selecting it. diff --git a/arch/powerpc/kernel/kaslr_booke.c b/arch/powerpc/kernel/kaslr_booke.c new file mode 100644 index ..30f84c0321b2 --- /dev/null +++ b/arch/powerpc/kernel/kaslr_booke.c @@ -0,0 +1,84 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2019 Jason Yan + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. You don't need that paragraph now that you have the SPDX tag. Rather than using a '//' comment followed by a single line block comment you can format it as: // SPDX-License-Identifier: GPL-2.0-only // // Copyright (C) 2019 Jason Yan > +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include Do you really need all those headers? I will remove useless headers. +extern int is_second_reloc; That should be in a header. Any reason why it isn't a bool? Oh yes, it should be in a header. This variable is already defined before and also used in assembly code. I think it was not defined as a bool just because there is no 'bool' in assembly code. cheers .
[PATCH v6 01/14] mm, fs: Move randomize_stack_top from fs to mm
This preparatory commit moves this function so that further introduction
of generic topdown mmap layout is contained only in mm/util.c.
Signed-off-by: Alexandre Ghiti
Acked-by: Kees Cook
Reviewed-by: Christoph Hellwig
Reviewed-by: Luis Chamberlain
---
fs/binfmt_elf.c| 20
include/linux/mm.h | 2 ++
mm/util.c | 22 ++
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d4e11b2e04f6..cec3b4146440 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -670,26 +670,6 @@ static unsigned long load_elf_interp(struct elfhdr
*interp_elf_ex,
* libraries. There is no binary dependent code anywhere else.
*/
-#ifndef STACK_RND_MASK
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))/* 8MB of VA */
-#endif
-
-static unsigned long randomize_stack_top(unsigned long stack_top)
-{
- unsigned long random_variable = 0;
-
- if (current->flags & PF_RANDOMIZE) {
- random_variable = get_random_long();
- random_variable &= STACK_RND_MASK;
- random_variable <<= PAGE_SHIFT;
- }
-#ifdef CONFIG_STACK_GROWSUP
- return PAGE_ALIGN(stack_top) + random_variable;
-#else
- return PAGE_ALIGN(stack_top) - random_variable;
-#endif
-}
-
static int load_elf_binary(struct linux_binprm *bprm)
{
struct file *interpreter = NULL; /* to shut gcc up */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..ae0e5d241eb8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2351,6 +2351,8 @@ extern int install_special_mapping(struct mm_struct *mm,
unsigned long addr, unsigned long len,
unsigned long flags, struct page **pages);
+unsigned long randomize_stack_top(unsigned long stack_top);
+
extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned
long, unsigned long, unsigned long);
extern unsigned long mmap_region(struct file *file, unsigned long addr,
diff --git a/mm/util.c b/mm/util.c
index e6351a80f248..15a4fb0f5473 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -293,6 +295,26 @@ int vma_is_stack_for_current(struct vm_area_struct *vma)
return (vma->vm_start <= KSTK_ESP(t) && vma->vm_end >= KSTK_ESP(t));
}
+#ifndef STACK_RND_MASK
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
+#endif
+
+unsigned long randomize_stack_top(unsigned long stack_top)
+{
+ unsigned long random_variable = 0;
+
+ if (current->flags & PF_RANDOMIZE) {
+ random_variable = get_random_long();
+ random_variable &= STACK_RND_MASK;
+ random_variable <<= PAGE_SHIFT;
+ }
+#ifdef CONFIG_STACK_GROWSUP
+ return PAGE_ALIGN(stack_top) + random_variable;
+#else
+ return PAGE_ALIGN(stack_top) - random_variable;
+#endif
+}
+
#if defined(CONFIG_MMU) && !defined(HAVE_ARCH_PICK_MMAP_LAYOUT)
void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
{
--
2.20.1
Re: [PATCHv5 06/37] alarmtimer: Provide get_timespec() callback
On Wed, Aug 07, 2019 at 08:04:10AM +0200, Thomas Gleixner wrote:
> On Mon, 29 Jul 2019, Dmitry Safonov wrote:
> > /**
> > @@ -869,8 +871,10 @@ static int __init alarmtimer_init(void)
> > /* Initialize alarm bases */
> > alarm_bases[ALARM_REALTIME].base_clockid = CLOCK_REALTIME;
> > alarm_bases[ALARM_REALTIME].get_ktime = &ktime_get_real;
> > + alarm_bases[ALARM_REALTIME].get_timespec = posix_get_timespec,
>
> That's just wrong:
>
> > /*
> > * Get monotonic time for posix timers
> > */
> > -static int posix_get_timespec(clockid_t which_clock, struct timespec64 *tp)
> > +int posix_get_timespec(clockid_t which_clock, struct timespec64 *tp)
> > {
> > ktime_get_ts64(tp);
> > return 0;
>
> Using a proper function name would have avoided this.
You are right. Will fix. Thanks!
>
Re: [f2fs-dev] [PATCH] f2fs: Fix build error while CONFIG_NLS=m
Hi Haibing,
Thanks for the patch!
Out of curiosity, does Hulk Robot check linux-next git repo as well? This will
be more valuable if the bug can be found during development of related patch?
On 2019/8/8 10:02, YueHaibing wrote:
> If CONFIG_F2FS_FS=y but CONFIG_NLS=m, building fails:
>
> fs/f2fs/file.o: In function `f2fs_ioctl':
> file.c:(.text+0xb86f): undefined reference to `utf16s_to_utf8s'
> file.c:(.text+0xe651): undefined reference to `utf8s_to_utf16s'
>
> Select CONFIG_NLS to fix this.
>
> Reported-by: Hulk Robot
> Fixes: 61a3da4d5ef8 ("f2fs: support FS_IOC_{GET,SET}FSLABEL")
> Signed-off-by: YueHaibing
Reviewed-by: Chao Yu
Thanks,
[PATCH v6 00/14] Provide generic top-down mmap layout functions
This series introduces generic functions to make top-down mmap layout easily accessible to architectures, in particular riscv which was the initial goal of this series. The generic implementation was taken from arm64 and used successively by arm, mips and finally riscv. Note that in addition the series fixes 2 issues: - stack randomization was taken into account even if not necessary. - [1] fixed an issue with mmap base which did not take into account randomization but did not report it to arm and mips, so by moving arm64 into a generic library, this problem is now fixed for both architectures. This work is an effort to factorize architecture functions to avoid code duplication and oversights as in [1]. [1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html Changes in v6: - Do not handle sv48 as it will be correctly implemented later: assume 64BIT <=> sv39. - Add acked-by from Paul Changes in v5: - Fix [PATCH 11/14] - Rebase on top of v5.3rc2 and commit "riscv: kbuild: add virtual memory system selection" - [PATCH 14/14] now takes into account the various virtual memory systems Changes in v4: - Make ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT select ARCH_HAS_ELF_RANDOMIZE by default as suggested by Kees, - ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT depends on MMU and defines the functions needed by ARCH_HAS_ELF_RANDOMIZE => architectures that use the generic mmap topdown functions cannot have ARCH_HAS_ELF_RANDOMIZE selected without MMU, but I think it's ok since randomization without MMU does not add much security anyway. - There is no common API to determine if a process is 32b, so I came up with !IS_ENABLED(CONFIG_64BIT) || is_compat_task() in [PATCH v4 12/14]. - Mention in the change log that x86 already takes care of not offseting mmap base address if the task does not want randomization. - Re-introduce a comment that should not have been removed. - Add Reviewed/Acked-By from Paul, Christoph and Kees, thank you for that. - I tried to minimize the changes from the commits in v3 in order to make easier the review of the v4, the commits changed or added are: - [PATCH v4 5/14] - [PATCH v4 8/14] - [PATCH v4 11/14] - [PATCH v4 12/14] - [PATCH v4 13/14] Changes in v3: - Split into small patches to ease review as suggested by Christoph Hellwig and Kees Cook - Move help text of new config as a comment, as suggested by Christoph - Make new config depend on MMU, as suggested by Christoph Changes in v2 as suggested by Christoph Hellwig: - Preparatory patch that moves randomize_stack_top - Fix duplicate config in riscv - Align #if defined on next line => this gives rise to a checkpatch warning. I found this pattern all around the tree, in the same proportion as the previous pattern which was less pretty: git grep -C 1 -n -P "^#if defined.+\|\|.*$" Alexandre Ghiti (14): mm, fs: Move randomize_stack_top from fs to mm arm64: Make use of is_compat_task instead of hardcoding this test arm64: Consider stack randomization for mmap base only when necessary arm64, mm: Move generic mmap layout functions to mm arm64, mm: Make randomization selected by generic topdown mmap layout arm: Properly account for stack randomization and stack guard gap arm: Use STACK_TOP when computing mmap base address arm: Use generic mmap top-down layout and brk randomization mips: Properly account for stack randomization and stack guard gap mips: Use STACK_TOP when computing mmap base address mips: Adjust brk randomization offset to fit generic version mips: Replace arch specific way to determine 32bit task with generic version mips: Use generic mmap top-down layout and brk randomization riscv: Make mmap allocation top-down by default arch/Kconfig | 11 +++ arch/arm/Kconfig | 2 +- arch/arm/include/asm/processor.h | 2 - arch/arm/kernel/process.c | 5 -- arch/arm/mm/mmap.c | 52 -- arch/arm64/Kconfig | 2 +- arch/arm64/include/asm/processor.h | 2 - arch/arm64/kernel/process.c| 8 --- arch/arm64/mm/mmap.c | 72 --- arch/mips/Kconfig | 2 +- arch/mips/include/asm/processor.h | 5 -- arch/mips/mm/mmap.c| 84 -- arch/riscv/Kconfig | 12 fs/binfmt_elf.c| 20 -- include/linux/mm.h | 2 + kernel/sysctl.c| 6 +- mm/util.c | 107 - 17 files changed, 138 insertions(+), 256 deletions(-) -- 2.20.1
Re: [PATCH] scripts/checkpatch.pl - fix *_NOTIFIER_HEAD handling
On Thu, 2019-08-08 at 02:08 -0400, Valdis Klētnieks wrote:
> On Wed, 07 Aug 2019 22:50:47 -0700, Joe Perches said:
> > On Wed, 2019-08-07 at 21:36 -0400, Valdis Kltnieks wrote:
> > > ^.DEFINE_$Ident\(\Q$name\E\)|
> > > ^.DECLARE_$Ident\(\Q$name\E\)|
> > > ^.LIST_HEAD\(\Q$name\E\)|
> > > - ^.{$Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
> > > + ^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
> >
> > Perhaps also better to convert all the '\Q$name\E' to '\s*\Q$name\E\s*'
>
> Yes, but that would need to be a separate patch.
Maybe so.
I'm just not a big fan of micro patches.
> The question would be if we
> consider 'DEFINE_foo( barbaz )' and similar with whitespace to be desirable
> style or not.
Oh, it would definitely be an uncomfortable style,
it's just allowing it in the regex.
btw: I'm also fine with it being a separate global patch.
cheers, Joe
> We already have the \s* in one place. Somebody else can decide if it should
> be in the other 5 places or not. :)
Is that supposed to be me? ;)
[PATCH 2/2] drivers: qcom: Add SoC sleep stats driver
Qualcomm Technologies Inc's (QTI) chipsets support SoC level
low power modes. Statistics for SoC sleep stats are produced
by remote processor.
Lets's add a driver to read the shared memory exported by the
remote processor and export to sysfs.
Signed-off-by: Mahesh Sivasubramanian
Signed-off-by: Lina Iyer
Signed-off-by: Maulik Shah
---
drivers/soc/qcom/Kconfig | 9 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/soc_sleep_stats.c | 249 +
3 files changed, 259 insertions(+)
create mode 100644 drivers/soc/qcom/soc_sleep_stats.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 880cf0290962..7aac24430e99 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -163,6 +163,15 @@ config QCOM_SMSM
Say yes here to support the Qualcomm Shared Memory State Machine.
The state machine is represented by bits in shared memory.
+config QCOM_SOC_SLEEP_STATS
+ tristate "Qualcomm Technologies Inc. (QTI) SoC sleep stats driver"
+ depends on ARCH_QCOM
+ help
+ Qualcomm Technologies Inc. (QTI) SoC sleep stats driver to read
+ the shared memory exported by the remote processor related to
+ various SoC level low power modes statistics and export to sysfs
+ interface.
+
config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..1530e0e73075 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_QCOM_SMEM) +=smem.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
+obj-$(CONFIG_QCOM_SOC_SLEEP_STATS) += soc_sleep_stats.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
diff --git a/drivers/soc/qcom/soc_sleep_stats.c
b/drivers/soc/qcom/soc_sleep_stats.c
new file mode 100644
index ..5b95d68512ec
--- /dev/null
+++ b/drivers/soc/qcom/soc_sleep_stats.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (c) 2011-2019, The Linux Foundation. All rights reserved.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARCH_TIMER_FREQ1920
+
+struct stats_config {
+ u32 offset_addr;
+ u32 num_records;
+ bool appended_stats_avail;
+};
+
+struct soc_sleep_stats_data {
+ phys_addr_t stats_base;
+ resource_size_t stats_size;
+ const struct stats_config *config;
+ struct kobject *kobj;
+ struct kobj_attribute ka;
+ struct mutex lock;
+};
+
+struct entry {
+ __le32 stat_type;
+ __le32 count;
+ __le64 last_entered_at;
+ __le64 last_exited_at;
+ __le64 accumulated;
+};
+
+struct appended_entry {
+ __le32 client_votes;
+ __le32 reserved[3];
+};
+
+struct stats_entry {
+ struct entry entry;
+ struct appended_entry appended_entry;
+};
+
+static inline u64 get_time_in_sec(u64 counter)
+{
+ do_div(counter, ARCH_TIMER_FREQ);
+
+ return counter;
+}
+
+static inline ssize_t append_data_to_buf(char *buf, int length,
+struct stats_entry *data)
+{
+ char stat_type[5] = {0};
+
+ memcpy(stat_type, &data->entry.stat_type, sizeof(u32));
+
+ return scnprintf(buf, length,
+"%s\n"
+"\tCount:%u\n"
+"\tLast Entered At(sec) :%llu\n"
+"\tLast Exited At(sec) :%llu\n"
+"\tAccumulated Duration(sec):%llu\n"
+"\tClient Votes :0x%x\n\n",
+stat_type, data->entry.count,
+data->entry.last_entered_at,
+data->entry.last_exited_at,
+data->entry.accumulated,
+data->appended_entry.client_votes);
+}
+
+static ssize_t stats_show(struct kobject *obj, struct kobj_attribute *attr,
+ char *buf)
+{
+ void __iomem *reg;
+ int i;
+ uint32_t offset;
+ ssize_t length = 0, op_length;
+ struct stats_entry data;
+ struct entry *e = &data.entry;
+ struct appended_entry *ae = &data.appended_entry;
+ struct soc_sleep_stats_data *drv = container_of(attr,
+ struct soc_sleep_stats_data, ka);
+
+ mutex_lock(&drv->lock);
+ reg = ioremap_nocache(drv->stats_base, drv->stats_size);
+ if (!reg) {
+ pr_err("io remap failed\n");
+ mutex_unlock(&drv->lock);
+ return length;
+ }
+
+ for
[PATCH 1/2] dt-bindings: Introduce soc sleep stats bindings for Qualcomm SoCs
Add device binding documentation for Qualcomm Technology Inc's (QTI)
SoC sleep stats driver. The driver is used for displaying SoC sleep
statistic maintained by Always On Processor or Resource Power Manager.
Cc: devicet...@vger.kernel.org
Signed-off-by: Mahesh Sivasubramanian
Signed-off-by: Lina Iyer
Signed-off-by: Maulik Shah
---
.../bindings/soc/qcom/soc-sleep-stats.txt | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.txt
b/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.txt
new file mode 100644
index ..ee40687ded34
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.txt
@@ -0,0 +1,36 @@
+* SoC Sleep Stats
+
+Always On Processor/Resource Power Manager maintains statistics of the SoC
+sleep modes involving lowering or powering down of the backbone rails - Cx
+and Mx and the oscillator clock, XO.
+
+Statistics includes SoC sleep mode type, number of times low power mode were
+entered, time of last entry, time of last exit and accumulated sleep duration.
+SoC Sleep Stats driver provides sysfs interface to display this information.
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: Should be "qcom,rpmh-sleep-stats" or "qcom,rpm-sleep-stats".
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: The base address on the Always On Processor or Resource
Power
+ Manager from where the stats are read.
+
+EXAMPLE 1:
+
+ rpmh_sleep_stats: soc-sleep-stats@c3f {
+ compatible = "qcom,rpmh-sleep-stats";
+ reg = <0 0xc3f 0 0x400>;
+ };
+
+EXAMPLE 2:
+
+ rpm_sleep_stats: soc-sleep-stats@469 {
+ compatible = "qcom,rpm-sleep-stats";
+ reg = <0 0x0469 0 0x400>;
+ };
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
the Code Aurora Forum, hosted by The Linux Foundation.
[PATCH 0/2] Introduce SoC sleep stats driver
Qualcomm Technologies Inc's (QTI) chipsets support SoC level low power modes. SoCs Always On Processor/Resource Power Manager produces statistics of the SoC sleep modes involving lowering or powering down of the backbone rails - Cx and Mx and the oscillator clock, XO. Statistics includes SoC sleep mode type, number of times LPM entered, time of last entry, exit, and accumulated sleep duration. This series adds a driver to read the stats produced by remote processor and exports using sysfs. Maulik Shah (2): dt-bindings: Introduce soc sleep stats bindings for Qualcomm SoCs drivers: qcom: Add SoC sleep stats driver .../bindings/soc/qcom/soc-sleep-stats.txt | 36 +++ drivers/soc/qcom/Kconfig | 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/soc_sleep_stats.c| 249 ++ 4 files changed, 295 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/soc-sleep-stats.txt create mode 100644 drivers/soc/qcom/soc_sleep_stats.c -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation.
Re: [PATCH net] net: phy: rtl8211f: do a double read to get real time link status
On 08.08.2019 03:15, Yonglong Liu wrote: > > > On 2019/8/8 0:47, Heiner Kallweit wrote: >> On 07.08.2019 15:16, Yonglong Liu wrote: >>> [ 27.232781] hns3 :bd:00.3 eth7: net open >>> [ 27.237303] 8021q: adding VLAN 0 to HW filter on device eth7 >>> [ 27.242972] IPv6: ADDRCONF(NETDEV_CHANGE): eth7: link becomes ready >>> [ 27.29] hns3 :bd:00.3: invalid speed (-1) >>> [ 27.253904] hns3 :bd:00.3 eth7: failed to adjust link. >>> [ 27.259379] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state >>> change UP -> RUNNING >>> [ 27.924903] hns3 :bd:00.3 eth7: link up >>> [ 28.280479] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state >>> change RUNNING -> NOLINK >>> [ 29.208452] hns3 :bd:00.3 eth7: link down >>> [ 32.376745] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: PHY state >>> change NOLINK -> RUNNING >>> [ 33.208448] hns3 :bd:00.3 eth7: link up >>> [ 35.253821] hns3 :bd:00.3 eth7: net stop >>> [ 35.258270] hns3 :bd:00.3 eth7: link down >>> >>> When using rtl8211f in polling mode, may get a invalid speed, >>> because of reading a fake link up and autoneg complete status >>> immediately after starting autoneg: >>> >>> ifconfig-1176 [007] 27.232763: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x00 val:0x1040 >>> kworker/u257:1-670 [015] 27.232805: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x04 val:0x01e1 >>> kworker/u257:1-670 [015] 27.232815: mdio_access: >>> mii-:bd:00.3 write phy:0x07 reg:0x04 val:0x05e1 >>> kworker/u257:1-670 [015] 27.232869: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad >>> kworker/u257:1-670 [015] 27.232904: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x09 val:0x0200 >>> kworker/u257:1-670 [015] 27.232940: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x00 val:0x1040 >>> kworker/u257:1-670 [015] 27.232949: mdio_access: >>> mii-:bd:00.3 write phy:0x07 reg:0x00 val:0x1240 >>> kworker/u257:1-670 [015] 27.233003: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad >>> kworker/u257:1-670 [015] 27.233039: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x0a val:0x3002 >>> kworker/u257:1-670 [015] 27.233074: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x09 val:0x0200 >>> kworker/u257:1-670 [015] 27.233110: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x05 val:0x >>> kworker/u257:1-670 [000] 28.280475: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x7989 >>> kworker/u257:1-670 [000] 29.304471: mdio_access: >>> mii-:bd:00.3 read phy:0x07 reg:0x01 val:0x7989 >>> >>> According to the datasheet of rtl8211f, to get the real time >>> link status, need to read MII_BMSR twice. >>> >>> This patch add a read_status hook for rtl8211f, and do a fake >>> phy_read before genphy_read_status(), so that can get real link >>> status in genphy_read_status(). >>> >>> Signed-off-by: Yonglong Liu >>> --- >>> drivers/net/phy/realtek.c | 13 + >>> 1 file changed, 13 insertions(+) >>> >> Is this an accidental resubmit? Because we discussed this in >> https://marc.info/?t=15641350993&r=1&w=2 and a fix has >> been applied already. >> >> Heiner >> >> . >> > > In https://marc.info/?t=15641350993&r=1&w=2 , the invalid speed > recurrence rate is almost 100%, and I had test the solution about > 5 times and it works. But yesterday it happen again suddenly, and than > I fount that the recurrence rate reduce to 10%. This time we get 0x79ad > after autoneg started which is not 0x798d from last discussion. > > > OK, I'll have a look. However the approach is wrong. The double read is related to the latching of link-down events. This is done by all PHY's and not specific to RT8211F. Also it's not related to the problem. I assume any sufficient delay would do instead of the read.
Re: [Intel-wired-lan] MDI errors during resume from ACPI S3 (suspend to ram)
On 8/7/2019 17:55, Paul Menzel wrote:
Dear Sasha,
On 07.08.19 09:23, Neftin, Sasha wrote:
On 8/6/2019 18:53, mario.limoncie...@dell.com wrote:
-Original Message-
From: Paul Menzel
Sent: Tuesday, August 6, 2019 10:36 AM
To: Jeff Kirsher
Cc: intel-wired-...@lists.osuosl.org; Linux Kernel Mailing List; Limonciello,
Mario
Subject: MDI errors during resume from ACPI S3 (suspend to ram)
Dear Linux folks,
Trying to decrease the resume time of Linux 5.3-rc3 on the Dell OptiPlex
5040 with the device below
$ lspci -nn -s 00:1f.6
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection
(2)
I219-V [8086:15b8] (rev 31)
pm-graph’s script `sleepgraph.py` shows, that the driver *e1000e* takes
around 400 ms, which is quite a lot. The call graph trace shows that
`e1000e_read_phy_reg_mdic()` is responsible for a lot of those. From
`drivers/net/ethernet/intel/e1000e/phy.c` [1]:
for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 3); i++) {
udelay(50);
mdic = er32(MDIC);
if (mdic & E1000_MDIC_READY)
break;
}
if (!(mdic & E1000_MDIC_READY)) {
e_dbg("MDI Read did not complete\n");
return -E1000_ERR_PHY;
}
if (mdic & E1000_MDIC_ERROR) {
e_dbg("MDI Error\n");
return -E1000_ERR_PHY;
}
Unfortunately, errors are not logged if dynamic debug is disabled,
so rebuilding the Linux kernel with `CONFIG_DYNAMIC_DEBUG`, and
echo "file drivers/net/ethernet/* +p" | sudo tee
/sys/kernel/debug/dynamic_debug/control
I got the messages below.
[ 4159.204192] e1000e :00:1f.6 net00: MDI Error
[ 4160.267950] e1000e :00:1f.6 net00: MDI Write did not complete
[ 4160.359855] e1000e :00:1f.6 net00: MDI Error
Can you please shed a little more light into these errors? Please
find the full log attached.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/e1000e/phy.c#n206
Strictly as a reference point you may consider trying the out-of-tree driver to
see if these
behaviors persist.
https://sourceforge.net/projects/e1000/
I can try that in the next days.
We are using external PHY. Required ~200 ms to complete MDIC
transaction (depended on the project).
Are you referring to the out-of-tree driver?
I believe the out of tree driver have a same approach to MDIC access.
You need to take to consider this time before access to the PHY. I do
not recommend decrease timer in a 'e1000e_read_phy_reg_mdic()'
method. We could hit on wrong MDI access.
My point was more, if you know that more time is needed, before the MDI
setting(?) will succeed, why try it anyway and go into the error paths?
Isn’t there some polling possible to find out, when MDI can be set up?
e1000e is very old driver and serve pretty lot of 1G clients. Each 1Gbe
MAC/PHY controller have a different configuration depend platform.
Kind regards,
Paul
Hello Paul,
Let me back later with more information specific your device. I will try
find out more details with design team.
Re: [PATCH] scripts/checkpatch.pl - fix *_NOTIFIER_HEAD handling
On Wed, 07 Aug 2019 22:50:47 -0700, Joe Perches said:
> On Wed, 2019-08-07 at 21:36 -0400, Valdis KlÄtnieks wrote:
> > ^.DEFINE_$Ident\(\Q$name\E\)|
> > ^.DECLARE_$Ident\(\Q$name\E\)|
> > ^.LIST_HEAD\(\Q$name\E\)|
> > - ^.{$Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
> > + ^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
>
> Perhaps also better to convert all the '\Q$name\E' to '\s*\Q$name\E\s*'
Yes, but that would need to be a separate patch. The question would be if we
consider 'DEFINE_foo( barbaz )' and similar with whitespace to be desirable
style or not.
[/usr/src/linux-next] grep '\\Q$name\\E' scripts/checkpatch.pl
^.DEFINE_$Ident\(\Q$name\E\)|
^.DECLARE_$Ident\(\Q$name\E\)|
^.LIST_HEAD\(\Q$name\E\)|
^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
^.(?:$Storage\s+)?$Type\s*\(\s*\*\s*\Q$name\E\s*\)\s*\(|
\b\Q$name\E(?:\s+$Attribute)*\s*(?:;|=|\[|\()
We already have the \s* in one place. Somebody else can decide if it should
be in the other 5 places or not. :)
pgpEZyZLWwJqm.pgp
Description: PGP signature
RE: [PATCH V2] usb: dwc3: gadget: trb_dequeue is not updated properly
Hi, "Yang, Fei" writes: >> I need tracepoints to see what's going on, please collect tracepoints. > > See attached. Search for "length 16384/16384" to the USB request using > sg list. And the transfer stalls at a request with "length 512/512". which gadget driver is this btw? Let's look at what happened leading up to this problem: ><...>-3107 [001] d..1 164.184431: dwc3_alloc_request: ep1out: req > 66963d3c length 0/0 zsI ==> 0 Allocated a new request ><...>-3107 [001] d..2 164.184432: dwc3_ep_queue: ep1out: req > 66963d3c length 0/16384 zsI ==> -115 queued it for a 16kiB transfer (split into 3 sglist entries) ><...>-3107 [001] d..2 164.184433: dwc3_prepare_trb: ep1out: trb > 11fb30b4 buf 77caf000 size 4096 ctrl 001d (HlCS:sc:normal) first one, 4kiB. Note the capital 'C', this one is chained. ><...>-3107 [001] d..2 164.184433: dwc3_prepare_trb: ep1out: trb > bc197bc2 buf 77cb size 8192 ctrl 001d (HlCS:sc:normal) second one, 8kiB. Also chained. ><...>-3107 [001] d..2 164.184433: dwc3_prepare_trb: ep1out: trb > ae5c00ad buf 77cb2000 size 4096 ctrl 0819 (HlcS:sC:normal) last one, 4kiB. NOT CHAINED! ><...>-3107 [001] d..2 164.184438: dwc3_gadget_ep_cmd: ep1out: cmd > 'Update Transfer' [20007] params --> status: > Successful issue update transfer ><...>-3107 [001] d..1 164.18: dwc3_alloc_request: ep1out: req > fe2c6e9d length 0/0 zsI ==> 0 now gadget driver allocates a NEW request ><...>-3107 [001] d..2 164.18: dwc3_ep_queue: ep1out: req > fe2c6e9d length 0/512 zsI ==> -115 ... and queues it for zero bytes. Why? Why didn't gadget driver set the ZERO flag in the original request? ><...>-3107 [001] d..2 164.184445: dwc3_prepare_trb: ep1out: trb > 55827a46 buf 77cb3000 size 512 ctrl 0819 (HlcS:sC:normal) a single TRB is prepared correctly. ><...>-3107 [001] d..2 164.184449: dwc3_gadget_ep_cmd: ep1out: cmd > 'Update Transfer' [20007] params --> status: > Successful Update transfer is issued. ><...>-3165 [001] d..1 164.192315: dwc3_event: event (4084): > ep1out: Transfer In Progress [0] (sIm) ><...>-3165 [001] d..1 164.192316: dwc3_complete_trb: ep1out: trb > 17050f80 buf 77c63000 size 0 ctrl 001c (hlCS:sc:normal) ><...>-3165 [001] d..1 164.192325: dwc3_gadget_giveback: ep1out: req > af8aa80e length 16384/16384 zsI ==> 0 > kworker/u8:5-1165 [001] 164.192353: dwc3_free_request: ep1out: req > af8aa80e length 16384/16384 zsI ==> 0 ><...>-3165 [001] d..1 164.192849: dwc3_event: event (4084): > ep1out: Transfer In Progress [0] (sIm) ><...>-3165 [001] d..1 164.192851: dwc3_complete_trb: ep1out: trb > c1f0fd23 buf 77c64000 size 0 ctrl 001c (hlCS:sc:normal) ><...>-3165 [001] d..1 164.192860: dwc3_gadget_giveback: ep1out: req > 66963d3c length 16384/16384 zsI ==> 0 here we giveback the request to the gadget driver. Note that the TRB addresses that were completed do NOT match the TRB addresses of the prepared TRBs. Again, which gadget driver is this? Where is the source code for this gadget driver? Also note that we requested for event upon completion of the final TRB only but we get events for each and every TRB. > kworker/u8:5-1165 [002] 164.192981: dwc3_free_request: ep1out: req > 66963d3c length 16384/16384 zsI ==> 0 ><...>-3165 [001] d..1 164.193055: dwc3_event: event (6084): > ep1out: Transfer In Progress [0] (SIm) ><...>-3165 [001] d..1 164.193056: dwc3_complete_trb: ep1out: trb > b8513800 buf 77c66000 size 0 ctrl 0818 (hlcS:sC:normal) ><...>-3165 [001] d..1 164.193058: dwc3_gadget_giveback: ep1out: req > fe2c6e9d length 512/512 zsI ==> 0 > kworker/u8:5-1165 [002] 164.193116: dwc3_free_request: ep1out: req > fe2c6e9d length 512/512 zsI ==> 0 None of this makes sense to me. Even worse, we have here a large block of the trace where none of prepared TRBs match the completed TRBs: <...>-3107 [001] d..1 164.183201: dwc3_alloc_request: ep1out: req fdd0cc66 length 0/0 zsI ==> 0 <...>-3107 [001] d..2 164.183204: dwc3_ep_queue: ep1out: req fdd0cc66 length 0/24 zsI ==> -115 <...>-3107 [001] d..2 164.183208: dwc3_prepare_trb: ep1out: trb e2f3f8ed buf 77c72000 size 24 ctrl 001d (HlCS:sc:normal) <...>-3107 [001] d..2 164.183210: dwc3_prepare_trb: ep1out: trb 4dd57f90 buf 7688 size 488 ctrl 0819 (HlcS:sC:normal) <...>-3107 [001] d..2 164.183216: dwc3_gadget_ep_cmd: ep1out: cmd 'Update Transfer' [20007] params --> status
Re: [PATCH] mm/mmap.c: refine data locality of find_vma_prev
On Thu 08-08-19 11:26:38, Wei Yang wrote: > On Wed, Aug 07, 2019 at 09:51:01AM +0200, Michal Hocko wrote: > >On Wed 07-08-19 08:31:09, Wei Yang wrote: > >> On Tue, Aug 06, 2019 at 11:29:52AM +0200, Vlastimil Babka wrote: > >> >On 8/6/19 10:11 AM, Wei Yang wrote: > >> >> When addr is out of the range of the whole rb_tree, pprev will points to > >> >> the biggest node. find_vma_prev gets is by going through the right most > >> > > >> >s/biggest/last/ ? or right-most? > >> > > >> >> node of the tree. > >> >> > >> >> Since only the last node is the one it is looking for, it is not > >> >> necessary to assign pprev to those middle stage nodes. By assigning > >> >> pprev to the last node directly, it tries to improve the function > >> >> locality a little. > >> > > >> >In the end, it will always write to the cacheline of pprev. The caller > >> >has most > >> >likely have it on stack, so it's already hot, and there's no other CPU > >> >stealing > >> >it. So I don't understand where the improved locality comes from. The > >> >compiler > >> >can also optimize the patched code so the assembly is identical to the > >> >previous > >> >code, or vice versa. Did you check for differences? > >> > >> Vlastimil > >> > >> Thanks for your comment. > >> > >> I believe you get a point. I may not use the word locality. This patch > >> tries > >> to reduce some unnecessary assignment of pprev. > >> > >> Original code would assign the value on each node during iteration, this is > >> what I want to reduce. > > > >Is there any measurable difference (on micro benchmarks or regular > >workloads)? > > I wrote a test case to compare these two methods, but not find visible > difference in run time. What is the point in changing this code if it doesn't lead to any measurable improvement? -- Michal Hocko SUSE Labs
Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
On Thu, 2019-08-08 at 11:19 +0530, Anshuman Khandual wrote:
>
> On 08/07/2019 06:03 AM, Miles Chen wrote:
> > This change prints the hexadecimal EC value in mem_abort_decode(),
> > which makes it easier to lookup the corresponding EC in
> > the ARM Architecture Reference Manual.
> >
> > The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> > faults") prints useful information when memory abort occurs. It would
> > be easier to lookup "0x25" instead of "DABT" in the document. Then we
> > can check the corresponding ISS.
> >
> > For example:
> > Current infoDocument
> > EC Exception class
> > "CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
> > "ASIMD" 0x7 "Access to SIMD or floating-point..."
> > "DABT (current EL)" 0x25"Data Abort taken without..."
> > ...
> >
> > Before:
> > Unable to handle kernel paging request at virtual address c000
> > Mem abort info:
> > ESR = 0x9646
> > Exception class = DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > Data abort info:
> > ISV = 0, ISS = 0x0046
> > CM = 0, WnR = 1
> >
> > After:
> > Unable to handle kernel paging request at virtual address c000
> > Mem abort info:
> > ESR = 0x9646
> > EC = 0x25: DABT (current EL), IL = 32 bits
> > SET = 0, FnV = 0
> > EA = 0, S1PTW = 0
> > Data abort info:
> > ISV = 0, ISS = 0x0046
> > CM = 0, WnR = 1
> >
> > Change since v1:
> > print "EC" instead of "Exception class"
> > print EC in fixwidth
> >
> > Cc: Mark Rutland
> > Cc: Anshuman Khandual
> > Cc: James Morse
> > Signed-off-by: Miles Chen
>
> This version implements the suggestion, hence it should have
> also contained acked-by tag from Mark from earlier version.
>
No problem. Sorry for not including the tag.
I was not sure if I should add the acked-by tag from Mark in patch v2.
> Reviewed-by: Anshuman Khandual
If I send patch v3, I should include acked-by tag from Mark and
Reviewed-by tag from you, right?
Miles
[PATCH] ALSA: firewire: fix a memory leak bug
In iso_packets_buffer_init(), 'b->packets' is allocated through
kmalloc_array(). Then, the aligned packet size is checked. If it is
larger than PAGE_SIZE, -EINVAL will be returned to indicate the error.
However, the allocated 'b->packets' is not deallocated on this path,
leading to a memory leak.
To fix the above issue, free 'b->packets' before returning the error code.
Signed-off-by: Wenwen Wang
---
sound/firewire/packets-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/firewire/packets-buffer.c b/sound/firewire/packets-buffer.c
index 0d35359..0ecafd0 100644
--- a/sound/firewire/packets-buffer.c
+++ b/sound/firewire/packets-buffer.c
@@ -37,7 +37,7 @@ int iso_packets_buffer_init(struct iso_packets_buffer *b,
struct fw_unit *unit,
packets_per_page = PAGE_SIZE / packet_size;
if (WARN_ON(!packets_per_page)) {
err = -EINVAL;
- goto error;
+ goto err_packets;
}
pages = DIV_ROUND_UP(count, packets_per_page);
--
2.7.4
Re: [PATCH] scripts/checkpatch.pl - fix *_NOTIFIER_HEAD handling
On Wed, 2019-08-07 at 21:36 -0400, Valdis Klētnieks wrote:
> commit 81398d99e9de80d9dbe65dfe7aadec9497f88242
> Author: Gilad Ben-Yossef
> Date: Wed Jul 31 14:44:23 2019 +1000
>
> checkpatch: add *_NOTIFIER_HEAD as var definition
>
> has a typo, resulting in a truly amazing error message:
Ouch, thanks.
> Unescaped left brace in regex is passed through in regex; marked by <-- HERE
> in m/(?:
[]
> Fix the typo.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3891,7 +3891,7 @@ sub process {
> ^.DEFINE_$Ident\(\Q$name\E\)|
> ^.DECLARE_$Ident\(\Q$name\E\)|
> ^.LIST_HEAD\(\Q$name\E\)|
> - ^.{$Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
> + ^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
Perhaps also better to convert all the '\Q$name\E' to '\s*\Q$name\E\s*'
Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
On 08/07/2019 06:03 AM, Miles Chen wrote:
> This change prints the hexadecimal EC value in mem_abort_decode(),
> which makes it easier to lookup the corresponding EC in
> the ARM Architecture Reference Manual.
>
> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> faults") prints useful information when memory abort occurs. It would
> be easier to lookup "0x25" instead of "DABT" in the document. Then we
> can check the corresponding ISS.
>
> For example:
> Current infoDocument
> EC Exception class
> "CP15 MCR/MRC"0x3 "MCR or MRC access to CP15a..."
> "ASIMD" 0x7 "Access to SIMD or floating-point..."
> "DABT (current EL)" 0x25"Data Abort taken without..."
> ...
>
> Before:
> Unable to handle kernel paging request at virtual address c000
> Mem abort info:
> ESR = 0x9646
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0046
> CM = 0, WnR = 1
>
> After:
> Unable to handle kernel paging request at virtual address c000
> Mem abort info:
> ESR = 0x9646
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0046
> CM = 0, WnR = 1
>
> Change since v1:
> print "EC" instead of "Exception class"
> print EC in fixwidth
>
> Cc: Mark Rutland
> Cc: Anshuman Khandual
> Cc: James Morse
> Signed-off-by: Miles Chen
This version implements the suggestion, hence it should have
also contained acked-by tag from Mark from earlier version.
Reviewed-by: Anshuman Khandual
Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
On Wed, Aug 7, 2019 at 6:55 PM Alexandre Belloni wrote: > > Hi, > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote: > > Maybe whether XO or DCXO is used also matters if you want to do some fine > > tunning of DCXO (control register has pletny of options), but that's > > probably > > better done in u-boot. And there's still no need to read HOSC source from > > DT. > > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL > > is 1, > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will > > be using this info to gate/disable the osciallator. > > > > It is actually useful to be able to tweak the crystal tuning at > runtime to be able to reduce clock drift and compare with a reliable > source (e.g. NTP). > I'm curious, what kind of options does this RTC have? It has options to set the current, trim cap value, band gap voltage, and also change the mode to just accept an external clock signal, instead of driving a crystal. The settings for the former parameters are not explained though. See page 364 of http://linux-sunxi.org/File:Allwinner_H6_V200_User_Manual_V1.1.pdf ChenYu
Re: [PATCH] team: Add vlan tx offload to hw_enc_features
On Wed, 7 Aug 2019 10:38:08 +0800
YueHaibing wrote:
> We should also enable bonding's vlan tx offload in hw_enc_features,
You mean team's vlan tx offload?
> pass the vlan packets to the slave devices with vlan tci, let them
s/let them to/let the slave/
> to handle vlan tunneling offload implementation.
>
> Fixes: 3268e5cb494d ("team: Advertise tunneling offload features")
> Signed-off-by: YueHaibing
[PATCH] net/netfilter/nf_nat_proto.c - make tables static
Sparse warns about two tables not being declared.
CHECK net/netfilter/nf_nat_proto.c
net/netfilter/nf_nat_proto.c:725:26: warning: symbol 'nf_nat_ipv4_ops' was not
declared. Should it be static?
net/netfilter/nf_nat_proto.c:964:26: warning: symbol 'nf_nat_ipv6_ops' was not
declared. Should it be static?
And in fact they can indeed be static.
Signed-off-by: Valdis Kletnieks
diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
index 7ac733ebd060..0a59c14b5177 100644
--- a/net/netfilter/nf_nat_proto.c
+++ b/net/netfilter/nf_nat_proto.c
@@ -722,7 +722,7 @@ nf_nat_ipv4_local_fn(void *priv, struct sk_buff *skb,
return ret;
}
-const struct nf_hook_ops nf_nat_ipv4_ops[] = {
+static const struct nf_hook_ops nf_nat_ipv4_ops[] = {
/* Before packet filtering, change destination */
{
.hook = nf_nat_ipv4_in,
@@ -961,7 +961,7 @@ nf_nat_ipv6_local_fn(void *priv, struct sk_buff *skb,
return ret;
}
-const struct nf_hook_ops nf_nat_ipv6_ops[] = {
+static const struct nf_hook_ops nf_nat_ipv6_ops[] = {
/* Before packet filtering, change destination */
{
.hook = nf_nat_ipv6_in,
Re: [PATCH] myri10ge: remove unneeded variable
On Wed, 31 Jul 2019 16:53:46 +0800 Ding Xiang wrote: > "error" is unneeded,just return 0 > > Signed-off-by: Ding Xiang Reviewed-by: Jesse Brandeburg
Re: [PATCH 2/2] net: ag71xx: Use GFP_KERNEL instead of GFP_ATOMIC in 'ag71xx_rings_init()'
On Wed, 31 Jul 2019 10:06:48 +0200 Christophe JAILLET wrote: > There is no need to use GFP_ATOMIC here, GFP_KERNEL should be enough. > The 'kcalloc()' just a few lines above, already uses GFP_KERNEL. > > Signed-off-by: Christophe JAILLET Reviewed-by: Jesse Brandeburg
Re: [PATCH 1/2] net: ag71xx: Slighly simplify code in 'ag71xx_rings_init()'
On Wed, 31 Jul 2019 10:06:38 +0200 Christophe JAILLET wrote: > A few lines above, we have: >tx_size = BIT(tx->order); > > So use 'tx_size' directly to be consistent with the way 'rx->descs_cpu' and > 'rx->descs_dma' are computed below. > > Signed-off-by: Christophe JAILLET Reviewed-by: Jesse Brandeburg
[PATCH] net/netfilter - add missing prototypes.
Sparse rightly complains about undeclared symbols.
CHECK net/netfilter/nft_set_hash.c
net/netfilter/nft_set_hash.c:647:21: warning: symbol 'nft_set_rhash_type' was
not declared. Should it be static?
net/netfilter/nft_set_hash.c:670:21: warning: symbol 'nft_set_hash_type' was
not declared. Should it be static?
net/netfilter/nft_set_hash.c:690:21: warning: symbol 'nft_set_hash_fast_type'
was not declared. Should it be static?
CHECK net/netfilter/nft_set_bitmap.c
net/netfilter/nft_set_bitmap.c:296:21: warning: symbol 'nft_set_bitmap_type'
was not declared. Should it be static?
CHECK net/netfilter/nft_set_rbtree.c
net/netfilter/nft_set_rbtree.c:470:21: warning: symbol 'nft_set_rbtree_type'
was not declared. Should it be static?
Include nf_tables_core.h rather than nf_tables.h to pick up the additional
definitions.
Signed-off-by: Valdis Kletnieks
diff --git a/net/netfilter/nft_set_bitmap.c b/net/netfilter/nft_set_bitmap.c
index b5aeccdddb22..087a056e34d1 100644
--- a/net/netfilter/nft_set_bitmap.c
+++ b/net/netfilter/nft_set_bitmap.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
struct nft_bitmap_elem {
struct list_headhead;
diff --git a/net/netfilter/nft_set_hash.c b/net/netfilter/nft_set_hash.c
index 6e8d20c03e3d..c490451fcebf 100644
--- a/net/netfilter/nft_set_hash.c
+++ b/net/netfilter/nft_set_hash.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include
+#include
/* We target a hash table size of 4, element hint is 75% of final size */
#define NFT_RHASH_ELEMENT_HINT 3
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 419d58ef802b..57123259452f 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include
struct nft_rbtree {
struct rb_root root;
Re: [PATCH] net: ethernet: et131x: Use GFP_KERNEL instead of GFP_ATOMIC when allocating tx_ring->tcb_ring
On Wed, 31 Jul 2019 09:38:42 +0200 Christophe JAILLET wrote: > There is no good reason to use GFP_ATOMIC here. Other memory allocations > are performed with GFP_KERNEL (see other 'dma_alloc_coherent()' below and > 'kzalloc()' in 'et131x_rx_dma_memory_alloc()') > > Use GFP_KERNEL which should be enough. > > Signed-off-by: Christophe JAILLET Sure, but generally I'd say GFP_ATOMIC is ok if you're in an init path and you can afford to have the allocation thread sleep while memory is being found by the kernel. Reviewed-by: Jesse Brandeburg
Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
On 08/07/2019 10:28 AM, Jia He wrote:
> Without this patch, the MAP_SYNC test case will cause a print_bad_pte
> warning on arm64 as follows:
> [ 25.542693] BUG: Bad page map in process mapdax333
> pte:2e8000448800f53 pmd:41ff5f003
> [ 25.546360] page:7e001022 refcount:1 mapcount:-1
> mapping:8003e29c7440 index:0x0
> [ 25.550281] ext4_dax_aops
> [ 25.550282] name:"__aaabbbcccddd__"
> [ 25.551553] flags: 0x3001002(referenced|reserved)
> [ 25.555802] raw: 03001002 8003dfffa908
> 8003e29c7440
> [ 25.559446] raw: 0001fffe
>
> [ 25.563075] page dumped because: bad pte
> [ 25.564938] addr:be05b000 vm_flags:208000fb
> anon_vma: mapping:8003e29c7440 index:0
> [ 25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault
> ap:ext4_file_mmap readpage:0x0
> [ 25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
> [ 25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
> 02/06/2015
> [ 25.585624] Call trace:
> [ 25.587008] dump_backtrace+0x0/0x178
> [ 25.588799] show_stack+0x24/0x30
> [ 25.590328] dump_stack+0xa8/0xcc
> [ 25.591901] print_bad_pte+0x18c/0x218
> [ 25.593628] unmap_page_range+0x778/0xc00
> [ 25.595506] unmap_single_vma+0x94/0xe8
> [ 25.597304] unmap_vmas+0x90/0x108
> [ 25.598901] unmap_region+0xc0/0x128
> [ 25.600566] __do_munmap+0x284/0x3f0
> [ 25.602245] __vm_munmap+0x78/0xe0
> [ 25.603820] __arm64_sys_munmap+0x34/0x48
> [ 25.605709] el0_svc_common.constprop.0+0x78/0x168
> [ 25.607956] el0_svc_handler+0x34/0x90
> [ 25.609698] el0_svc+0x8/0xc
> [ 25.611103] Disabling lock debugging due to kernel taint
> [ 25.613573] BUG: Bad page state in process mapdax333 pfn:448800
> [ 25.616359] page:7e001022 refcount:0 mapcount:-1
> mapping:8003e29c7440 index:0x1
> [ 25.620236] ext4_dax_aops
> [ 25.620237] name:"__aaabbbcccddd__"
> [ 25.621495] flags: 0x300()
> [ 25.624912] raw: 0300 dead0100 dead0200
> 8003e29c7440
> [ 25.628502] raw: 0001 fffe
>
> [ 25.632097] page dumped because: non-NULL mapping
> [...]
> [ 25.656567] CPU: 1 PID: 1180 Comm: mapdax333 Tainted: GB
> 5.2.0+ #21
> [ 25.660131] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
> 02/06/2015
> [ 25.663324] Call trace:
> [ 25.664466] dump_backtrace+0x0/0x178
> [ 25.666163] show_stack+0x24/0x30
> [ 25.667721] dump_stack+0xa8/0xcc
> [ 25.669270] bad_page+0xf0/0x150
> [ 25.670772] free_pages_check_bad+0x84/0xa0
> [ 25.672724] free_pcppages_bulk+0x45c/0x708
> [ 25.674675] free_unref_page_commit+0xcc/0x100
> [ 25.676751] free_unref_page_list+0x13c/0x200
> [ 25.678801] release_pages+0x350/0x420
> [ 25.680539] free_pages_and_swap_cache+0xf8/0x128
> [ 25.682738] tlb_flush_mmu+0x164/0x2b0
> [ 25.684485] unmap_page_range+0x648/0xc00
> [ 25.686349] unmap_single_vma+0x94/0xe8
> [ 25.688131] unmap_vmas+0x90/0x108
> [ 25.689739] unmap_region+0xc0/0x128
> [ 25.691392] __do_munmap+0x284/0x3f0
> [ 25.693079] __vm_munmap+0x78/0xe0
> [ 25.694658] __arm64_sys_munmap+0x34/0x48
> [ 25.696530] el0_svc_common.constprop.0+0x78/0x168
> [ 25.698772] el0_svc_handler+0x34/0x90
> [ 25.700512] el0_svc+0x8/0xc
>
> The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
> the return value will be incorrectly set to pfn_to_page(pfn) instead
> of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
> setting PTE_SPECIAL for pmd
>
> The MAP_SYNC test case is as follows(Provided by Yibo Cai)
> $#include
> $#include
> $#include
> $#include
> $#include
>
> $#ifndef MAP_SYNC
> $#define MAP_SYNC 0x8
> $#endif
>
> /* mount -o dax /dev/pmem0 /mnt */
> $#define F "/mnt/__aaabbbcccddd__"
>
> int main(void)
> {
> int fd;
> char buf[4096];
> void *addr;
>
> if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
> perror("open1");
> return 1;
> }
>
> if (write(fd, buf, 4096) != 4096) {
> perror("lseek");
> return 1;
> }
>
> addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC,
> fd, 0);
> if (addr == MAP_FAILED) {
> perror("mmap");
> printf("did you mount with '-o dax'?\n");
> return 1;
> }
>
> memset(addr, 0x55, 4096);
>
> if (munmap(addr, 4096) == -1) {
> perror("munmap");
> return 1;
> }
>
> close(fd);
>
> return 0;
> }
>
> Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
> Reported-by: Yibo Cai
> Signed-off-by: Jia He
> Acked-by: Robin Murphy
> ---
> arch/arm64/include/asm/pgtable.h | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index 5fdcfe237338..e09760
Re: [PATCH 4/5] clk: Add driver for Bitmain BM1880 SoC clock controller
Quoting Manivannan Sadhasivam (2019-07-05 08:14:39)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index fc1e0cf44995..ffc61ed85ade 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -304,6 +304,12 @@ config COMMON_CLK_FIXED_MMIO
> help
> Support for Memory Mapped IO Fixed clocks
>
> +config COMMON_CLK_BM1880
> + bool "Clock driver for Bitmain BM1880 SoC"
> + depends on ARCH_BITMAIN || COMPILE_TEST
> + help
> + This driver supports the clocks on Bitmain BM1880 SoC.
Can you add this config somewhere else besides the end? Preferably
close to alphabetically in this file.
> +
> source "drivers/clk/actions/Kconfig"
> source "drivers/clk/analogbits/Kconfig"
> source "drivers/clk/bcm/Kconfig"
> diff --git a/drivers/clk/clk-bm1880.c b/drivers/clk/clk-bm1880.c
> new file mode 100644
> index ..26cdb75bb936
> --- /dev/null
> +++ b/drivers/clk/clk-bm1880.c
> @@ -0,0 +1,947 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bitmain BM1880 SoC clock driver
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include
> +#include
Should probably add kernel.h for at least container_of()
> +
> +#include
> +
> +#define BM1880_CLK_MPLL_CTL0x00
> +#define BM1880_CLK_SPLL_CTL0x04
> +#define BM1880_CLK_FPLL_CTL0x08
> +#define BM1880_CLK_DDRPLL_CTL 0x0c
> +
> +#define BM1880_CLK_ENABLE0 0x00
> +#define BM1880_CLK_ENABLE1 0x04
> +#define BM1880_CLK_SELECT 0x20
> +#define BM1880_CLK_DIV00x40
> +#define BM1880_CLK_DIV10x44
> +#define BM1880_CLK_DIV20x48
> +#define BM1880_CLK_DIV30x4c
> +#define BM1880_CLK_DIV40x50
> +#define BM1880_CLK_DIV50x54
> +#define BM1880_CLK_DIV60x58
> +#define BM1880_CLK_DIV70x5c
> +#define BM1880_CLK_DIV80x60
> +#define BM1880_CLK_DIV90x64
> +#define BM1880_CLK_DIV10 0x68
> +#define BM1880_CLK_DIV11 0x6c
> +#define BM1880_CLK_DIV12 0x70
> +#define BM1880_CLK_DIV13 0x74
> +#define BM1880_CLK_DIV14 0x78
> +#define BM1880_CLK_DIV15 0x7c
> +#define BM1880_CLK_DIV16 0x80
> +#define BM1880_CLK_DIV17 0x84
> +#define BM1880_CLK_DIV18 0x88
> +#define BM1880_CLK_DIV19 0x8c
> +#define BM1880_CLK_DIV20 0x90
> +#define BM1880_CLK_DIV21 0x94
> +#define BM1880_CLK_DIV22 0x98
> +#define BM1880_CLK_DIV23 0x9c
> +#define BM1880_CLK_DIV24 0xa0
> +#define BM1880_CLK_DIV25 0xa4
> +#define BM1880_CLK_DIV26 0xa8
> +#define BM1880_CLK_DIV27 0xac
> +#define BM1880_CLK_DIV28 0xb0
> +
> +#define to_bm1880_pll_clk(_hw) container_of(_hw, struct bm1880_pll_hw_clock,
> hw)
> +#define to_bm1880_div_clk(_hw) container_of(_hw, struct bm1880_div_hw_clock,
> hw)
> +
> +static DEFINE_SPINLOCK(bm1880_clk_lock);
> +
> +struct bm1880_clock_data {
> + void __iomem *pll_base;
> + void __iomem *sys_base;
> + struct clk_onecell_data clk_data;
> +};
> +
> +struct bm1880_gate_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 gate_reg;
> + s8 gate_shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_mux_clock {
> + unsigned intid;
> + const char *name;
> + const char * const * parents;
> + s8 num_parents;
> + u32 reg;
> + s8 shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + u8 shift;
> + u8 width;
> + u32 initval;
> + struct clk_div_table *table;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_hw_clock {
> + struct bm1880_div_clock div;
> + void __iomem *base;
> + spinlock_t *lock;
> + struct clk_hw hw;
> +};
> +
> +struct bm1880_composite_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + const char * const * parents;
> + unsigned intnum_parents;
> + unsigned long flags;
> +
> + u32 gate_reg;
> + u32 mux_reg;
> + u32 div_reg;
> +
> + s8 gate_shift;
> + s8 mux_shift;
> + s8 div_shift;
> + s8 div_width;
> + s16 div_initval;
> + struct clk_div_table *table;
> +};
> +
> +struct bm1880_pll_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + unsigned long flags;
> +};
> +
> +struct bm1880_pll_hw_cloc
[PATCH] sound: fix a memory leak bug
In sound_insert_unit(), the controlling structure 's' is allocated through kmalloc(). Then it is added to the sound driver list by invoking __sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is removed from the list through __sound_remove_unit(). If 'index' is not less than 0, -EBUSY is returned to indicate the error. However, 's' is not deallocated on this execution path, leading to a memory leak bug. To fix the above issue, free 's' before -EBUSY is returned. Signed-off-by: Wenwen Wang --- sound/sound_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/sound_core.c b/sound/sound_core.c index b730d97..90d118c 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -275,7 +275,8 @@ static int sound_insert_unit(struct sound_unit **list, const struct file_operati goto retry; } spin_unlock(&sound_loader_lock); - return -EBUSY; + r = -EBUSY; + goto fail; } } -- 2.7.4
Re: [PATCH v1 2/2] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
On 07-08-19, 23:43, Taniya Das wrote:
> +static struct clk_alpha_pll gpll0;
> +static struct clk_alpha_pll gpll1;
> +static struct clk_alpha_pll gpll4;
> +static struct clk_alpha_pll gpll6;
> +static struct clk_alpha_pll gpll7;
> +static struct clk_alpha_pll_postdiv gpll0_out_even;
I am not sure we need these, reordering code and getting rid of them
should be easy enough (i did that for sm8150)
> +static const struct parent_map gcc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> + { P_GPLL0_OUT_MAIN, 1 },
> + { P_GPLL0_OUT_EVEN, 6 },
> + { P_CORE_BI_PLL_TEST_SE, 7 },
> +};
> +
> +static const struct clk_parent_data gcc_parent_data_0[] = {
> + { .fw_name = "bi_tcxo", .name = "bi_tcxo" },
> + { .hw = &gpll0.clkr.hw },
> + { .hw = &gpll0_out_even.clkr.hw },
> + { .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
This is legacy test, so we would want only fw_name being there
> +static struct clk_branch gcc_camera_ahb_clk = {
> + .halt_reg = 0xb008,
> + .halt_check = BRANCH_HALT,
> + .hwcg_reg = 0xb008,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0xb008,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_camera_ahb_clk",
> + .flags = CLK_IS_CRITICAL,
It would help to explain why this clk is critical
> +static struct clk_branch gcc_disp_gpll0_div_clk_src = {
> + .halt_check = BRANCH_HALT_DELAY,
And why this needs a delay
--
~Vinod
Re: linux-next: Tree for Aug 7
Stephen Rothwell writes: > Hi all, > > Changes since 20190806: > > The arm64 tree introduced a patch that stopped the powerpc ppc64_defconfig > build from completing so I reverted that commit. > > The mips tree gained a conflict against Linus' tree. > > The crypto tree still had its build failure for which I applied a patch. > > The drm-misc tree gained a conflict and a sematic conflct against the > amdgpu tree. > > The integrity tree lost its build failure. > > The akpm-current tree gained a conflict against the arm64 tree and a > build failure for which I reverted a commit. > > The akpm tree lost a patch that turned up elsewhere. > > Non-merge commits (relative to Linus' tree): 4586 > 4952 files changed, 265168 insertions(+), 120665 deletions(-) This is still popping a few implicit fallthrough warnings, from various configs: arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/include/asm/sysreg.h:808:2: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:20:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:21:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:22:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:23:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:24:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:25:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:26:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:27:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:28:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:29:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:30:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:31:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:32:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:33:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:34:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:351:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:353:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:361:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:363:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:384:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:386:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:394:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:396:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/mips/include/asm/octeon/cvmx-sli-defs.h:47:6: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/nds32/kernel/signal.c:315:7: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/nds32/kernel/signal.c:362:20: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:3: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq'; did you mean 'writel'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq' [-Werror=implicit-function-declaration] drivers/gpu/drm/sun4i/sun4i_tcon.c:318:7: warning: this statement may
Re: linux-next: build failure after merge of the crypto tree
Hi Herbert, On Thu, 8 Aug 2019 15:00:04 +1000 Herbert Xu wrote: > > On Thu, Aug 08, 2019 at 01:17:10PM +1000, Stephen Rothwell wrote: > > > > Excellent, thanks. Should I add the crypto mailing list as a contact > > for problems? Mostly the emails are just reporting conflicts and only > > very occasionally do I actually send a useful patch. If so, what is > > its address? > > Yes please. The address is > > linux-cry...@vger.kernel.org Done. -- Cheers, Stephen Rothwell pgpFj8AdDHrpN.pgp Description: OpenPGP digital signature
Re: [PATCH v1 1/2] clk: qcom: Add DT bindings for SC7180 gcc clock controller
On 07-08-19, 23:43, Taniya Das wrote: > Add compatible string and the include file for gcc clock > controller for SC7180. > > Signed-off-by: Taniya Das > --- > .../devicetree/bindings/clock/qcom,gcc.txt| 1 + > include/dt-bindings/clock/qcom,gcc-sc7180.h | 155 ++ > 2 files changed, 156 insertions(+) > create mode 100644 include/dt-bindings/clock/qcom,gcc-sc7180.h > > diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt > b/Documentation/devicetree/bindings/clock/qcom,gcc.txt > index 8661c3cd3ccf..18d95467cb36 100644 > --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt > +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt > @@ -23,6 +23,7 @@ Required properties : > "qcom,gcc-sdm630" > "qcom,gcc-sdm660" > "qcom,gcc-sdm845" > + "qcom,gcc-sc7180" I don't see parent clocks listed here please add them as well -- ~Vinod
Re: [PATCH 1/5] dt-bindings: clock: Add Bitmain BM1880 SoC clock controller binding
Quoting Manivannan Sadhasivam (2019-07-05 08:14:36)
> Add devicetree binding for Bitmain BM1880 SoC clock controller.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../bindings/clock/bitmain,bm1880-clk.txt | 47 +++
Can you convert this to YAML? It's all the rage right now.
> include/dt-bindings/clock/bm1880-clock.h | 82 +++
> 2 files changed, 129 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> create mode 100644 include/dt-bindings/clock/bm1880-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> new file mode 100644
> index ..9c967095d430
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> @@ -0,0 +1,47 @@
> +* Bitmain BM1880 Clock Controller
> +
> +The Bitmain BM1880 clock controler generates and supplies clock to
> +various peripherals within the SoC.
> +
> +Required Properties:
> +
> +- compatible: Should be "bitmain,bm1880-clk"
> +- reg :Register address and size of PLL and SYS control domains
> +- reg-names : Register domain names: "pll" and "sys"
> +- clocks : Phandle of the input reference clock.
> +- #clock-cells: Should be 1.
> +
> +Each clock is assigned an identifier, and client nodes can use this
> identifier
> +to specify the clock which they consume.
> +
> +All available clocks are defined as preprocessor macros in corresponding
> +dt-bindings/clock/bm1880-clock.h header and can be used in device tree
> sources.
> +
> +External clocks:
> +
> +The osc clock used as the input for the plls is generated outside the SoC.
> +It is expected that it is defined using standard clock bindings as "osc".
> +
> +Example:
> +
> +clk: clock-controller@800 {
> +compatible = "bitmain,bm1880-clk";
> +reg = <0xe8 0x0c>,<0x800 0xb0>;
It looks weird still. What hardware module is this actually part of?
Some larger power manager block?
> +reg-names = "pll", "sys";
> +clocks = <&osc>;
> +#clock-cells = <1>;
> +};
> +
Re: linux-next: build failure after merge of the crypto tree
On Thu, Aug 08, 2019 at 01:17:10PM +1000, Stephen Rothwell wrote: > > Excellent, thanks. Should I add the crypto mailing list as a contact > for problems? Mostly the emails are just reporting conflicts and only > very occasionally do I actually send a useful patch. If so, what is > its address? Yes please. The address is linux-cry...@vger.kernel.org Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] liquidio: Use pcie_flr() instead of reimplementing it
octeon_mbox_process_cmd() directly writes the PCI_EXP_DEVCTL_BCR_FLR bit, which bypasses timing requirements imposed by the PCIe spec. This patch fixes the function to use the pcie_flr() interface instead. Signed-off-by: Denis Efremov --- drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c index 021d99cd1665..614d07be7181 100644 --- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c +++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c @@ -260,9 +260,7 @@ static int octeon_mbox_process_cmd(struct octeon_mbox *mbox, dev_info(&oct->pci_dev->dev, "got a request for FLR from VF that owns DPI ring %u\n", mbox->q_no); - pcie_capability_set_word( - oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no], - PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR); + pcie_flr(oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no]); break; case OCTEON_PF_CHANGED_VF_MACADDR: -- 2.21.0
Re: [PATCH v2] clk: Constify struct clk_bulk_data * where possible
Quoting Andrey Smirnov (2019-07-17 07:56:51) > The following functions: > > - clk_bulk_enable() > - clk_bulk_prepare() > - clk_bulk_disable() > - clk_bulk_unprepare() > > already expect const clk_bulk_data * as a second parameter, however > their no-op version have mismatching prototypes that don't. Fix that. > > While at it, constify the second argument of clk_bulk_prepare_enable() > and clk_bulk_disable_unprepare(), since the functions they are > comprised of already accept const clk_bulk_data *. > > Signed-off-by: Andrey Smirnov > Cc: Russell King > Cc: Stephen Boyd > Cc: Chris Healy > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- Applied to clk-next
Re: [PATCH v2 0/7] Add support for Qualcomm SM8150 and SC7180 SoCs
On 07-08-19, 12:39, Sibi Sankar wrote: > This patch series adds SCM, APSS shared mailbox and QMP AOSS PD/clock > support on SM8150 and SC7180 SoCs. > > v2: > * re-arrange the compatible lists in sort order i checked these lgtm and tested on SM8150 Tested-by: Vinod Koul Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset
On 8/7/19 10:36 AM, Vijay Khemka wrote:
> Lgtm except one small comment below.
>
> On 8/6/19, 5:22 PM, "openbmc on behalf of Tao Ren"
> tao...@fb.com> wrote:
>
> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
> MAC address when CONFIG_NCSI_OEM_CMD_GET_MAC option is enabled. The logic
> doesn't work for platforms with different BMC MAC offset: for example,
> Facebook Yamp BMC's MAC address is calculated by adding 2 to NIC's base
> MAC address ("BaseMAC + 1" is reserved for Host use).
>
> This patch adds NET_NCSI_MC_MAC_OFFSET config option to customize offset
> between NIC's Base MAC address and BMC's MAC address. Its default value is
> set to 1 to avoid breaking existing users.
>
> Signed-off-by: Tao Ren
> ---
> net/ncsi/Kconfig| 8
> net/ncsi/ncsi-rsp.c | 15 +--
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/net/ncsi/Kconfig b/net/ncsi/Kconfig
> index 2f1e5756c03a..be8efe1ed99e 100644
> --- a/net/ncsi/Kconfig
> +++ b/net/ncsi/Kconfig
> @@ -17,3 +17,11 @@ config NCSI_OEM_CMD_GET_MAC
> ---help---
> This allows to get MAC address from NCSI firmware and set them back to
> controller.
> +config NET_NCSI_MC_MAC_OFFSET
> + int
> + prompt "Offset of Management Controller's MAC Address"
> + depends on NCSI_OEM_CMD_GET_MAC
> + default 1
> + help
> + This defines the offset between Network Controller's (base) MAC
> + address and Management Controller's MAC address.
> diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> index 7581bf919885..24a791f9ebf5 100644
> --- a/net/ncsi/ncsi-rsp.c
> +++ b/net/ncsi/ncsi-rsp.c
> @@ -656,6 +656,11 @@ static int ncsi_rsp_handler_oem_bcm_gma(struct
> ncsi_request *nr)
> struct ncsi_rsp_oem_pkt *rsp;
> struct sockaddr saddr;
> int ret = 0;
> +#ifdef CONFIG_NET_NCSI_MC_MAC_OFFSET
> + int mac_offset = CONFIG_NET_NCSI_MC_MAC_OFFSET;
> +#else
> + int mac_offset = 1;
> +#endif
>
> /* Get the response header */
> rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
> @@ -663,8 +668,14 @@ static int ncsi_rsp_handler_oem_bcm_gma(struct
> ncsi_request *nr)
> saddr.sa_family = ndev->type;
> ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> memcpy(saddr.sa_data, &rsp->data[BCM_MAC_ADDR_OFFSET], ETH_ALEN);
> - /* Increase mac address by 1 for BMC's address */
> - eth_addr_inc((u8 *)saddr.sa_data);
> +
> + /* Management Controller's MAC address is calculated by adding
> + * the offset to Network Controller's (base) MAC address.
> + * Note: negative offset is "ignored", and BMC will use the Base
> Just mention negative and zero offset is ignored. As you are ignoring 0 as
> well.
Thank you Vijay for the review.
Zero offset is not ignored: users get what they want when setting offset to 0
(BMC-MAC = Base-MAC).
Thanks,
Tao
Re: [PATCH] arm64/cache: silence -Woverride-init warnings
On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC (and
> Clang) with -Winitializer-overrides),
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VIPT] = "VIPT",
> ^~
> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> 'icache_policy_str[2]')
> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_PIPT] = "PIPT",
> ^~
> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> 'icache_policy_str[3]')
> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VPIPT] = "VPIPT",
> ^~~
> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> 'icache_policy_str[0]')
>
> because it initializes icache_policy_str[0 ... 3] twice. Since
> arm64 developers are keen to keep the style of initializing a static
> array with a non-zero pattern first, just disable those warnings for
> both GCC and Clang of this file.
>
> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT
> I-caches")
> Signed-off-by: Qian Cai
It's a shame we can't just use one cc-disable-warning statement but
-Woverride-init wasn't added for GCC compatibility until clang 8.0.0
and we don't have an established minimum clang version.
With that said, I applied your patch and I don't see with warning with
W=1 anymore and I see both options get added to the clang command line
with V=1.
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Cheers!
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/locking/mutex-debug.c: In function 'debug_mutex_lock_common':
kernel/locking/mutex-debug.c:32:42: error: dereferencing pointer to incomplete
type 'struct mutex_waiter'
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
^~~
Caused by commit
5f35d5a66b3e ("locking/mutex: Make __mutex_owner static to mutex.c")
I have reverted that commit for today.
BTW, there is another reference to mutex_waiter in sched.h!
--
Cheers,
Stephen Rothwell
pgpLjQCuDkmBv.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset
On 8/7/19 11:41 AM, Andrew Lunn wrote:
> On Wed, Aug 07, 2019 at 11:25:18AM -0700, Jakub Kicinski wrote:
>> On Tue, 6 Aug 2019 17:21:18 -0700, Tao Ren wrote:
>>> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
>>> MAC address when CONFIG_NCSI_OEM_CMD_GET_MAC option is enabled. The logic
>>> doesn't work for platforms with different BMC MAC offset: for example,
>>> Facebook Yamp BMC's MAC address is calculated by adding 2 to NIC's base
>>> MAC address ("BaseMAC + 1" is reserved for Host use).
>>>
>>> This patch adds NET_NCSI_MC_MAC_OFFSET config option to customize offset
>>> between NIC's Base MAC address and BMC's MAC address. Its default value is
>>> set to 1 to avoid breaking existing users.
>>>
>>> Signed-off-by: Tao Ren
>>
>> Maybe someone more knowledgeable like Andrew has an opinion here,
>> but to me it seems a bit strange to encode what seems to be platfrom
>> information in the kernel config :(
>
> Yes, this is not a good idea. It makes it impossible to have a 'BMC
> distro' kernel which you install on a number of different BMCs.
>
> A device tree property would be better. Ideally it would be the
> standard local-mac-address, or mac-address.
Thank you Andrew and Jakub for the feedback. I picked up kconfig approach
mainly because it's an OEM-only extention which is used only when
NCSI_OEM_CMD_GET_MAC is enabled.
Let me prepare patch v2 using device tree. I'm not sure if standard
"mac-address" fits this situation because all we need is an offset (integer)
and BMC MAC is calculated by adding the offset to NIC's MAC address. Anyways,
let me work out v2 patch we can discuss more then.
Thanks,
Tao
Re: [PATCH v2 1/4] clk: core: introduce clk_hw_set_parent()
Quoting Jerome Brunet (2019-08-06 01:28:19)
> On Wed 31 Jul 2019 at 10:40, Neil Armstrong wrote:
>
> > Introduce the clk_hw_set_parent() provider call to change parent of
> > a clock by using the clk_hw pointers.
> >
> > This eases the clock reparenting from clock rate notifiers and
> > implementing DVFS with simpler code avoiding the boilerplates
> > functions as __clk_lookup(clk_hw_get_name()) then clk_set_parent().
> >
> > Signed-off-by: Neil Armstrong
> > Acked-by: Martin Blumenstingl
>
> Looks ok to me but we will obviously need Stephen's ack to apply it
Acked-by: Stephen Boyd
>
> > ---
> > drivers/clk/clk.c| 6 ++
> > include/linux/clk-provider.h | 1 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index c0990703ce54..c11b1781d24a 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2487,6 +2487,12 @@ static int clk_core_set_parent_nolock(struct
> > clk_core *core,
> > return ret;
> > }
> >
> > +int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *parent)
> > +{
> > + return clk_core_set_parent_nolock(hw->core, parent->core);
I wonder if you really want to call all those things in
clk_core_set_parent_nolock(). For example, do you want notifiers to run
again and for rates to be speculated? Maybe all you want to do is
overwrite some value for the clk's parent by calling into the ops for
the clk and generically parse the value that's passed as the "parent"
here.
I ask because it may be good to avoid doing all that work and updating
bookkeeping when we're deep in a notifier. If we can clearly understand
what the driver wants to do from the notifier then it's simpler to
change in the future to use things such as the coordinated clk rate
vaporware.
Re: [RFC/RFT v3 07/14] clk: meson: g12a: add notifiers to handle cpu clock change
Quoting Martin Blumenstingl (2019-07-02 16:28:55) > Hi Stephen, Hi Neil, > > On Mon, Jul 1, 2019 at 11:13 AM Neil Armstrong > wrote: > > > > In order to implement clock switching for the CLKID_CPU_CLK and > > CLKID_CPUB_CLK, notifiers are added on specific points of the > > clock tree : > > > > cpu_clk / cpub_clk > > | \- cpu_clk_dyn > > | | \- cpu_clk_premux0 > > | ||- cpu_clk_postmux0 > > | |||- cpu_clk_dyn0_div > > | ||\- xtal/fclk_div2/fclk_div3 > > | |\- xtal/fclk_div2/fclk_div3 > > | \- cpu_clk_premux1 > > ||- cpu_clk_postmux1 > > |||- cpu_clk_dyn1_div > > ||\- xtal/fclk_div2/fclk_div3 > > |\- xtal/fclk_div2/fclk_div3 > > \ sys_pll / sys1_pll > > > > This for each cluster, a single one for G12A, two for G12B. > > > > Each cpu_clk_premux1 tree is marked as read-only and > > CLK_SET_RATE_NO_REPARENT, > > to be used as "parking" clock in a safe clock frequency. > it seems that this is one case where the "coordinated clocks" feature > would come handy: [0] > Stephen, do you know if those patches stopped in March or if there's > still some ongoing effort to get them ready? > Derek told me yesterday he wants to work on it again, but I don't know his timeline. If Derek doesn't reply here then maybe it can be picked up by someone else.
Re: [PATCH v4 2/5] clk: qcom: clk-alpha-pll: Remove post_div_table checks
Quoting Vinod Koul (2019-07-22 00:43:45) > We want users to code properly and fix the post_div_table missing and > not rely on core to check. So remove the post_div_table check. > > Signed-off-by: Vinod Koul > Reviewed-by: Bjorn Andersson > --- Applied to clk-next
Re: [PATCH v4 4/5] dt-bindings: clock: Document gcc bindings for SM8150
Quoting Vinod Koul (2019-07-22 00:43:47) > From: Deepak Katragadda > > Document the global clock controller found on SM8150. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and add external clocks > split binding to this patch]] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v4 5/5] clk: qcom: gcc: Add global clock controller driver for SM8150
Quoting Vinod Koul (2019-07-22 00:43:48) > From: Deepak Katragadda > > Add the clocks supported in global clock controller which clock the > peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks > to the clock framework for the clients to be able to request for them. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and tidy-up > port to new parent scheme > Add comments for critical clocks]] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v4 1/5] clk: qcom: clk-alpha-pll: Remove unnecessary cast
Quoting Vinod Koul (2019-07-22 00:43:44)
> Commit 8f9fab480c7a ("linux/kernel.h: fix overflow for
> DIV_ROUND_UP_ULL") fixed the overflow for DIV_ROUND_UP_ULL, so we no
> longer need the cast for DIV_ROUND_UP_ULL, so remove the unnecessary
> u64 casts.
>
> Signed-off-by: Vinod Koul
> ---
Applied to clk-next
Re: [PATCH v4 3/5] clk: qcom: clk-alpha-pll: Add support for Trion PLLs
Quoting Vinod Koul (2019-07-22 00:43:46) > From: Deepak Katragadda > > Add programming sequence support for managing the Trion > PLLs. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and tidy-up > use upstream way of specifying PLLs] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v5 03/10] powerpc: introduce kimage_vaddr to store the kernel base
On 2019/8/7 21:03, Michael Ellerman wrote: Jason Yan writes: Now the kernel base is a fixed value - KERNELBASE. To support KASLR, we need a variable to store the kernel base. Signed-off-by: Jason Yan Cc: Diana Craciun Cc: Michael Ellerman Cc: Christophe Leroy Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Nicholas Piggin Cc: Kees Cook Reviewed-by: Christophe Leroy Reviewed-by: Diana Craciun Tested-by: Diana Craciun --- arch/powerpc/include/asm/page.h | 2 ++ arch/powerpc/mm/init-common.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 0d52f57fca04..60a68d3a54b1 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -315,6 +315,8 @@ void arch_free_page(struct page *page, int order); struct vm_area_struct; +extern unsigned long kimage_vaddr; + #include #endif /* __ASSEMBLY__ */ #include diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c index 152ae0d21435..d4801ce48dc5 100644 --- a/arch/powerpc/mm/init-common.c +++ b/arch/powerpc/mm/init-common.c @@ -25,6 +25,8 @@ phys_addr_t memstart_addr = (phys_addr_t)~0ull; EXPORT_SYMBOL_GPL(memstart_addr); phys_addr_t kernstart_addr; EXPORT_SYMBOL_GPL(kernstart_addr); +unsigned long kimage_vaddr = KERNELBASE; +EXPORT_SYMBOL_GPL(kimage_vaddr); The names of the #defines and variables we use for these values are not very consistent already, but using kimage_vaddr makes it worse I think. Isn't this going to have the same value as kernstart_addr, but the virtual rather than physical address? Yes, that's true. If so kernstart_virt_addr would seem better. OK, I will take kernstart_virt_addr if no better name appears. cheers .
Re: [PATCH net-next v4 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
Hi Heiner, On 8/7/19 12:18 PM, Heiner Kallweit wrote: > On 06.08.2019 23:42, Tao Ren wrote: >> Hi Andrew / Heiner / Vladimir, >> >> On 8/6/19 2:09 PM, Tao Ren wrote: >>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for >>> example, on Facebook CMM BMC platform), mainly because genphy functions >>> are designed for copper links, and 1000Base-X (clause 37) auto negotiation >>> needs to be handled differently. >>> >>> This patch enables 1000Base-X support for BCM54616S by customizing 3 >>> driver callbacks: >>> >>> - probe: probe callback detects PHY's operation mode based on >>> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX >>> Control register. >>> >>> - config_aneg: bcm54616s_config_aneg_1000bx function is added for auto >>> negotiation in 1000Base-X mode. >>> >>> - read_status: BCM54616S and BCM5482 PHY share the same read_status >>> callback which manually set link speed and duplex mode in 1000Base-X >>> mode. >>> >>> Signed-off-by: Tao Ren >> >> I customized config_aneg function for BCM54616S 1000Base-X mode and >> link-down issue is also fixed: the patch is tested on Facebook CMM and >> Minipack BMC and everything looks normal. Please kindly review when you have >> bandwidth and let me know if you have further suggestions. >> >> BTW, I would be happy to help if we decide to add a set of genphy functions >> for clause 37, although that may mean I need more help/guidance from you :-) > > You want to have standard clause 37 aneg and this should be generic in phylib. > I hacked together a first version that is compile-tested only: > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_1143631_&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=iYElT7HC77pRZ3byVvW8ng&m=ZJArOJvHqNkqvs1x8l9HjfxjCN8e5xJpPz2YViBuKRA&s=EskpfBQtu9IBVeb96dv-sz76xIz4tJK5-lD4-qdIyWI&e= > > It supports fixed mode too. > > It doesn't support half duplex mode because phylib doesn't know 1000BaseX HD > yet. > Not sure whether half duplex mode is used at all in reality. > > You could test the new core functions in your own config_aneg and read_status > callback implementations. Thank you very much for the help! I'm planning to add these functions but I haven't started yet because I'm still going through clause 37 :-) Let me apply your patch and run some test on my platform. Will share you results tomorrow. Cheers, Tao
Re: [PATCH] clk: ingenic: Use CLK_OF_DECLARE_DRIVER macro
Quoting Paul Cercueil (2019-07-16 10:08:00) > By using CLK_OF_DECLARE_DRIVER instead of the CLK_OF_DECLARE macro, we > allow the driver to probe also as a platform driver. > > While this driver does not have code to probe as a platform driver, this > is still useful for probing children devices in the case where the > device node is compatible with "simple-mfd". > > Signed-off-by: Paul Cercueil > --- What's the baseline for this? It doesn't apply cleanly to v5.3-rc1
Re: [PATCH] clk: ingenic/jz4740: Fix "pll half" divider not read/written properly
Quoting Paul Cercueil (2019-08-07 16:28:10)
>
>
> Le mer. 7 août 2019 à 23:33, Stephen Boyd a écrit
> :
> > Quoting Paul Cercueil (2019-07-01 04:36:06)
> >> The code was setting the bit 21 of the CPCCR register to use a
> >> divider
> >> of 2 for the "pll half" clock, and clearing the bit to use a divider
> >> of 1.
> >>
> >> This is the opposite of how this register field works: a cleared bit
> >> means that the /2 divider is used, and a set bit means that the
> >> divider
> >> is 1.
> >>
> >> Restore the correct behaviour using the newly introduced .div_table
> >> field.
> >>
> >> Signed-off-by: Paul Cercueil
> >> ---
> >
> > Applied to clk-next. Does this need a fixes tag?
>
> It depends on commit a9fa2893fcc6 ("clk: ingenic: Add support for
> divider tables") which was sent without a fixes tag, so it'd be
> a bit difficult. Probably not worth the trouble.
>
Does it need to go in as a fix for this -rc series then? Or is it not
causing issues for you so it's ok to wait until next merge window?
[PATCH v3 1/1] ixgbe: sync the first fragment unconditionally
In Xen environment, if Xen-swiotlb is enabled, ixgbe driver
could possibly allocate a page, DMA memory buffer, for the first
fragment which is not suitable for Xen-swiotlb to do DMA operations.
Xen-swiotlb have to internally allocate another page for doing DMA
operations. This mechanism requires syncing the data from the internal
page to the page which ixgbe sends to upper network stack. However,
since commit f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path"), the unmap operation is performed with
DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed.
Since the sync isn't performed, the upper network stack could receive
a incomplete network packet. By incomplete, it means the linear data
on the first fragment(between skb->head and skb->end) is invalid. So
we have to copy the data from the internal xen-swiotlb page to the page
which ixgbe sends to upper network stack through the sync operation.
More details from Alexander Duyck:
Specifically since we are mapping the frame with
DMA_ATTR_SKIP_CPU_SYNC we have to unmap with that as well. As a result
a sync is not performed on an unmap and must be done manually as we
skipped it for the first frag. As such we need to always sync before
possibly performing a page unmap operation.
Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path")
Reviewed-by: Alexander Duyck
Signed-off-by: Firo Yang
---
Changes from v2:
* Added details on the problem caused by skipping the sync.
* Added more explanation from Alexander Duyck.
Changes from v1:
* Imporved the patch description.
* Added Reviewed-by: and Fixes: as suggested by Alexander Duyck.
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..200de9838096 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1825,13 +1825,7 @@ static void ixgbe_pull_tail(struct ixgbe_ring *rx_ring,
static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring,
struct sk_buff *skb)
{
- /* if the page was released unmap it, else just sync our portion */
- if (unlikely(IXGBE_CB(skb)->page_released)) {
- dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
-ixgbe_rx_pg_size(rx_ring),
-DMA_FROM_DEVICE,
-IXGBE_RX_DMA_ATTR);
- } else if (ring_uses_build_skb(rx_ring)) {
+ if (ring_uses_build_skb(rx_ring)) {
unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK;
dma_sync_single_range_for_cpu(rx_ring->dev,
@@ -1848,6 +1842,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring
*rx_ring,
skb_frag_size(frag),
DMA_FROM_DEVICE);
}
+
+ /* If the page was released, just unmap it. */
+ if (unlikely(IXGBE_CB(skb)->page_released)) {
+ dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
+ixgbe_rx_pg_size(rx_ring),
+DMA_FROM_DEVICE,
+IXGBE_RX_DMA_ATTR);
+ }
}
/**
--
2.16.4
Re: [PATCH v4 02/20] RISC-V: Add bitmap reprensenting ISA features common across CPUs
On Thu, Aug 8, 2019 at 12:18 AM Atish Patra wrote:
>
> On Wed, 2019-08-07 at 12:28 +, Anup Patel wrote:
> > This patch adds riscv_isa bitmap which represents Host ISA features
> > common across all Host CPUs. The riscv_isa is not same as elf_hwcap
> > because elf_hwcap will only have ISA features relevant for user-space
> > apps whereas riscv_isa will have ISA features relevant to both kernel
> > and user-space apps.
> >
> > One of the use-case for riscv_isa bitmap is in KVM hypervisor where
> > we will use it to do following operations:
> >
> > 1. Check whether hypervisor extension is available
> > 2. Find ISA features that need to be virtualized (e.g. floating
> >point support, vector extension, etc.)
> >
> > Signed-off-by: Anup Patel
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/include/asm/hwcap.h | 26 +++
> > arch/riscv/kernel/cpufeature.c | 79
> > --
> > 2 files changed, 102 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/hwcap.h
> > b/arch/riscv/include/asm/hwcap.h
> > index 7ecb7c6a57b1..9b657375aa51 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -8,6 +8,7 @@
> > #ifndef __ASM_HWCAP_H
> > #define __ASM_HWCAP_H
> >
> > +#include
> > #include
> >
> > #ifndef __ASSEMBLY__
> > @@ -22,5 +23,30 @@ enum {
> > };
> >
> > extern unsigned long elf_hwcap;
> > +
> > +#define RISCV_ISA_EXT_a ('a' - 'a')
> > +#define RISCV_ISA_EXT_c ('c' - 'a')
> > +#define RISCV_ISA_EXT_d ('d' - 'a')
> > +#define RISCV_ISA_EXT_f ('f' - 'a')
> > +#define RISCV_ISA_EXT_h ('h' - 'a')
> > +#define RISCV_ISA_EXT_i ('i' - 'a')
> > +#define RISCV_ISA_EXT_m ('m' - 'a')
> > +#define RISCV_ISA_EXT_s ('s' - 'a')
> > +#define RISCV_ISA_EXT_u ('u' - 'a')
>
> As per the discussion in following threads, 'S' & 'U' are not valid ISA
> extensions. So we should drop them from here as well.
>
> http://lists.infradead.org/pipermail/linux-riscv/2019-August/005771.html
>
> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg01217.html
I disagree because we are not checking or enforcing required ISA features
here.
The asm/hwcap.h should define all possible feature and extension bits
defined by the RISC-V spec.
The 's' and 'u' bits in ISA mean that S-mode and U-mode are supported.
These bits are defined in RISC-V privileged spec as well.
Regards,
Anup
>
>
> > +#define RISCV_ISA_EXT_zicsr (('z' - 'a') + 1)
> > +#define RISCV_ISA_EXT_zifencei (('z' - 'a') + 2)
> > +#define RISCV_ISA_EXT_zam(('z' - 'a') + 3)
> > +#define RISCV_ISA_EXT_ztso (('z' - 'a') + 4)
> > +
> > +#define RISCV_ISA_EXT_MAX256
> > +
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap);
> > +
> > +#define riscv_isa_extension_mask(ext) BIT_MASK(RISCV_ISA_EXT_##ext)
> > +
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit);
> > +#define riscv_isa_extension_available(isa_bitmap, ext) \
> > + __riscv_isa_extension_available(isa_bitmap,
> > RISCV_ISA_EXT_##ext)
> > +
> > #endif
> > #endif
> > diff --git a/arch/riscv/kernel/cpufeature.c
> > b/arch/riscv/kernel/cpufeature.c
> > index b1ade9a49347..4ce71ce5e290 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -6,21 +6,64 @@
> > * Copyright (C) 2017 SiFive
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > #include
> >
> > unsigned long elf_hwcap __read_mostly;
> > +
> > +/* Host ISA bitmap */
> > +static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
> > +
> > #ifdef CONFIG_FPU
> > bool has_fpu __read_mostly;
> > #endif
> >
> > +/**
> > + * riscv_isa_extension_base - Get base extension word
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @returns base extension word as unsigned long value
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap)
> > +{
> > + if (!isa_bitmap)
> > + return riscv_isa[0];
> > + return isa_bitmap[0];
> > +}
> > +EXPORT_SYMBOL_GPL(riscv_isa_extension_base);
> > +
> > +/**
> > + * __riscv_isa_extension_available - Check whether given extension
> > + * is available or not
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @bit bit position of the desired extension
> > + * @returns true or false
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit)
> > +{
> > + const unsigned long *bmap = (isa_bitmap) ? isa_bitmap :
> > riscv_isa;
> > +
> > + if (bit >= RISCV_ISA_EXT_MAX)
> > + return false;
> > +
> > + return test_bit(bit, bmap) ? true : false;
> > +}
> > +EXPORT_SYMBOL_GPL(__riscv_isa
i2c: imx: support slave mode for imx I2C driver
The patch supports slave mode for imx I2C driver
Signed-off-by: Biwen Li
---
drivers/i2c/busses/i2c-imx.c | 199 ---
1 file changed, 185 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b1b8b938d7f4..f7583a9fa56f 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -202,6 +202,9 @@ struct imx_i2c_struct {
struct pinctrl_state *pinctrl_pins_gpio;
struct imx_i2c_dma *dma;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ struct i2c_client *slave;
+#endif /* CONFIG_I2C_SLAVE */
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
@@ -583,23 +586,40 @@ static void i2c_imx_stop(struct imx_i2c_struct *i2c_imx)
imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
}
-static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
+/* Clear interrupt flag bit */
+static void i2c_imx_clr_if_bit(struct imx_i2c_struct *i2c_imx)
{
- struct imx_i2c_struct *i2c_imx = dev_id;
- unsigned int temp;
+ unsigned int status;
- temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
- if (temp & I2SR_IIF) {
- /* save status register */
- i2c_imx->i2csr = temp;
- temp &= ~I2SR_IIF;
- temp |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
- imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2SR);
- wake_up(&i2c_imx->queue);
- return IRQ_HANDLED;
- }
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IIF;
+ status |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
+
+/* Clear arbitration lost bit */
+static void i2c_imx_clr_al_bit(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IAL;
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
- return IRQ_NONE;
+static irqreturn_t i2c_imx_master_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ dev_dbg(&i2c_imx->adapter.dev, "<%s>: master interrupt\n", __func__);
+
+ /* Save status register */
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ i2c_imx->i2csr = status | I2SR_IIF;
+
+ wake_up(&i2c_imx->queue);
+
+ return IRQ_HANDLED;
}
static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
@@ -1043,11 +1063,162 @@ static u32 i2c_imx_func(struct i2c_adapter *adapter)
| I2C_FUNC_SMBUS_READ_BLOCK_DATA;
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static void i2c_imx_slave_init(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int temp;
+
+ dev_dbg(&i2c_imx->adapter.dev, "<%s>\n", __func__);
+
+ /* Set slave addr. */
+ imx_i2c_write_reg((i2c_imx->slave->addr << 1), i2c_imx, IMX_I2C_IADR);
+
+ /* Disable i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ ^ I2CR_IEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Reset status register */
+ imx_i2c_write_reg(i2c_imx->hwdata->i2sr_clr_opcode, i2c_imx,
+ IMX_I2C_I2SR);
+
+ /* Enable module and enable interrupt from i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ | I2CR_IIEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Wait controller to be stable */
+ usleep_range(50, 150);
+}
+
+static irqreturn_t i2c_imx_slave_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status, ctl;
+ u8 value;
+
+ if (!i2c_imx->slave) {
+ dev_err(&i2c_imx->adapter.dev, "cannot deal with slave
irq,i2c_imx->slave is null");
+ return IRQ_NONE;
+ }
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ ctl = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ if (status & I2SR_IAL) { /* Arbitration lost */
+ i2c_imx_clr_al_bit(i2c_imx);
+ } else if (status & I2SR_IAAS) { /* Addressed as a slave */
+ if (status & I2SR_SRW) { /* Master wants to read from us*/
+ dev_dbg(&i2c_imx->adapter.dev, "read requested");
+ i2c_slave_event(i2c_imx->slave,
I2C_SLAVE_READ_REQUESTED, &value);
+
+ /* Slave transimt */
+ ctl |= I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
+ /* Send data */
+ imx_i2c_write_reg(value, i2c_imx, IMX_I2C_I2DR);
+ } else { /* Master wants to write to us */
+ dev_dbg(&i2c_imx->adapter.dev, "write requested");
+ i2c_slave_event(i2c_imx->slave,
I2C_SLAVE_WRITE_REQUESTED, &value);
+
+ /* Slave receive */
+ ctl &= ~I2CR_MTX;
+ imx_i2c_writ
[PATCH] lib/generic-radix-tree.c - make 2 functions static inline
When building with W=1, we get some warnings:
l CC lib/generic-radix-tree.o
lib/generic-radix-tree.c:39:10: warning: no previous prototype for
'genradix_root_to_depth' [-Wmissing-prototypes]
39 | unsigned genradix_root_to_depth(struct genradix_root *r)
| ^~
lib/generic-radix-tree.c:44:23: warning: no previous prototype for
'genradix_root_to_node' [-Wmissing-prototypes]
44 | struct genradix_node *genradix_root_to_node(struct genradix_root *r)
| ^
They're not used anywhere else, so make them static inline.
Signed-off-by: Valdis Kletnieks
diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c
index a7bafc413730..ae25e2fa2187 100644
--- a/lib/generic-radix-tree.c
+++ b/lib/generic-radix-tree.c
@@ -36,12 +36,12 @@ static inline size_t genradix_depth_size(unsigned depth)
#define GENRADIX_DEPTH_MASK\
((unsigned long) (roundup_pow_of_two(GENRADIX_MAX_DEPTH + 1) - 1))
-unsigned genradix_root_to_depth(struct genradix_root *r)
+static inline unsigned genradix_root_to_depth(struct genradix_root *r)
{
return (unsigned long) r & GENRADIX_DEPTH_MASK;
}
-struct genradix_node *genradix_root_to_node(struct genradix_root *r)
+static inline struct genradix_node *genradix_root_to_node(struct genradix_root
*r)
{
return (void *) ((unsigned long) r & ~GENRADIX_DEPTH_MASK);
}
Re: [PATCH v2 1/1] ixgbe: sync the first fragment unconditionally
On Wed, Aug 7, 2019 at 6:58 PM Jacob Wen wrote: > > > On 8/7/19 4:38 PM, Firo Yang wrote: > > The 08/07/2019 15:56, Jacob Wen wrote: > >> I think the description is not correct. Consider using something like > >> below. > > Thank you for comments. > > > >> In Xen environment, due to memory fragmentation ixgbe may allocate a 'DMA' > >> buffer with pages that are not physically contiguous. > > Actually, I didn't look into the reason why ixgbe got a DMA buffer which > > was mapped to Xen-swiotlb area. > Yes. I was wrong. You don't need to tell the exact reason. > > > > But I don't think this issue relates to phsical memory contiguity because, > > in > > our case, one ixgbe_rx_buffer only associates at most one page. > > This is interesting. > > I guess the performance of the NIC in your environment is not good due > to the extra cost of bounce buffer. If I recall correctly the Rx performance for ixgbe shouldn't be too bad even with a bounce buffer. The cost for map/unmap are expensive for a bounce buffer setup but the syncs are just copies so they are pretty cheap in comparison. The driver can take advantage of that on Rx since it leaves the pages mapped and just syncs the portion of the pages that are used. Now if you are hitting the bounce buffer on the Tx side that is another matter as you have to allocate the buffer on demand and that is quite expensive.
Re: [PATCH v2 1/2] linux/bits.h: Clarify macro argument names
On Fri, Aug 2, 2019 at 8:04 AM Rikard Falkeborn wrote: > > Be a little more verbose to improve readability. > > Signed-off-by: Rikard Falkeborn BTW, I do not understand what the improvement is. I tend to regard this as a noise commit. > --- > Changes in v2: > - This patch is new in v2 > > include/linux/bits.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/include/linux/bits.h b/include/linux/bits.h > index 669d69441a62..d4466aa42a9c 100644 > --- a/include/linux/bits.h > +++ b/include/linux/bits.h > @@ -14,16 +14,16 @@ > #define BITS_PER_BYTE 8 > > /* > - * Create a contiguous bitmask starting at bit position @l and ending at > - * position @h. For example > + * Create a contiguous bitmask starting at bit position @low and ending at > + * position @high. For example > * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. > */ > -#define GENMASK(h, l) \ > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > +#define GENMASK(high, low) \ > + (((~UL(0)) - (UL(1) << (low)) + 1) & \ > +(~UL(0) >> (BITS_PER_LONG - 1 - (high > > -#define GENMASK_ULL(h, l) \ > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > +#define GENMASK_ULL(high, low) \ > + (((~ULL(0)) - (ULL(1) << (low)) + 1) & \ > +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (high > > #endif /* __LINUX_BITS_H */ > -- > 2.22.0 > -- Best Regards Masahiro Yamada
[PATCH] lib/extable.c - add missing prototypes.
When building with W=1, a number of warnings are issued: CC lib/extable.o lib/extable.c:63:6: warning: no previous prototype for 'sort_extable' [-Wmissing-prototypes] 63 | void sort_extable(struct exception_table_entry *start, | ^~~~ lib/extable.c:75:6: warning: no previous prototype for 'trim_init_extable' [-Wmissing-prototypes] 75 | void trim_init_extable(struct module *m) | ^ lib/extable.c:115:1: warning: no previous prototype for 'search_extable' [-Wmissing-prototypes] 115 | search_extable(const struct exception_table_entry *base, | ^~ Add the missing #include for the prototypes. Signed-off-by: Valdis Kletnieks diff --git a/lib/extable.c b/lib/extable.c index 25da4071122a..c3e59caf7ffa 100644 --- a/lib/extable.c +++ b/lib/extable.c @@ -10,6 +10,7 @@ #include #include #include +#include #ifndef ARCH_HAS_RELATIVE_EXTABLE #define ex_to_insn(x) ((x)->insn)
[PATCH v1 2/2] i2c: iproc: Add full name of devicetree node to adapter name
From: Lori Hikichi Add the full name of the devicetree node to the adapter name. Without this change, all adapters have the same name making it difficult to distinguish between multiple instances. The most obvious way to see this is to use the utility i2c_detect. e.g. "i2c-detect -l" Before i2c-1 i2c Broadcom iProc I2C adapter I2C adapter i2c-0 i2c Broadcom iProc I2C adapter I2C adapter After i2c-1 i2c Broadcom iProc (i2c@e) I2C adapter i2c-0 i2c Broadcom iProc (i2c@b) I2C adapter Now it is easy to figure out which adapter maps to a which DT node. Signed-off-by: Lori Hikichi Signed-off-by: Rayagonda Kokatanur --- drivers/i2c/busses/i2c-bcm-iproc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c index 19ef2b0..183b220 100644 --- a/drivers/i2c/busses/i2c-bcm-iproc.c +++ b/drivers/i2c/busses/i2c-bcm-iproc.c @@ -922,7 +922,9 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev) adap = &iproc_i2c->adapter; i2c_set_adapdata(adap, iproc_i2c); - strlcpy(adap->name, "Broadcom iProc I2C adapter", sizeof(adap->name)); + snprintf(adap->name, sizeof(adap->name), + "Broadcom iProc (%s)", + of_node_full_name(iproc_i2c->device->of_node)); adap->algo = &bcm_iproc_algo; adap->quirks = &bcm_iproc_i2c_quirks; adap->dev.parent = &pdev->dev; -- 1.9.1
