* Re: [PATCH v2 18/30] KVM: PPC: Book3S PR: always fail transaction in guest privilege state
From: Simon Guo @ 2018-05-16 1:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20180515060755.GD28451@fergus.ozlabs.ibm.com>
Hi Paul,
On Tue, May 15, 2018 at 04:07:55PM +1000, Paul Mackerras wrote:
> On Wed, Feb 28, 2018 at 01:52:26AM +0800, wei.guo.simon@gmail.com wrote:
> > From: Simon Guo <wei.guo.simon@gmail.com>
> >
> > Currently kernel doesn't use transaction memory.
> > And there is an issue for privilege guest that:
> > tbegin/tsuspend/tresume/tabort TM instructions can impact MSR TM bits
> > without trap into PR host. So following code will lead to a false mfmsr
> > result:
> > tbegin <- MSR bits update to Transaction active.
> > beq <- failover handler branch
> > mfmsr <- still read MSR bits from magic page with
> > transaction inactive.
> >
> > It is not an issue for non-privilege guest since its mfmsr is not patched
> > with magic page and will always trap into PR host.
> >
> > This patch will always fail tbegin attempt for privilege guest, so that
> > the above issue is prevented. It is benign since currently (guest) kernel
> > doesn't initiate a transaction.
> >
> > Test case:
> > https://github.com/justdoitqd/publicFiles/blob/master/test_tbegin_pr.c
> >
> > Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
> > ---
> > arch/powerpc/include/asm/kvm_book3s.h | 2 ++
> > arch/powerpc/kvm/book3s_emulate.c | 43 +++++++++++++++++++++++++++++++++++
> > arch/powerpc/kvm/book3s_pr.c | 11 ++++++++-
> > 3 files changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
> > index 2ecb6a3..9690280 100644
> > --- a/arch/powerpc/include/asm/kvm_book3s.h
> > +++ b/arch/powerpc/include/asm/kvm_book3s.h
> > @@ -258,9 +258,11 @@ extern void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
> > #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > void kvmppc_save_tm_pr(struct kvm_vcpu *vcpu);
> > void kvmppc_restore_tm_pr(struct kvm_vcpu *vcpu);
> > +void kvmppc_restore_tm_sprs(struct kvm_vcpu *vcpu);
> > #else
> > static inline void kvmppc_save_tm_pr(struct kvm_vcpu *vcpu) {}
> > static inline void kvmppc_restore_tm_pr(struct kvm_vcpu *vcpu) {}
> > +static inline void kvmppc_restore_tm_sprs(struct kvm_vcpu *vcpu) {}
> > #endif
> >
> > extern int kvm_irq_bypass;
> > diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
> > index a03533d..90b5f59 100644
> > --- a/arch/powerpc/kvm/book3s_emulate.c
> > +++ b/arch/powerpc/kvm/book3s_emulate.c
> > @@ -23,6 +23,7 @@
> > #include <asm/reg.h>
> > #include <asm/switch_to.h>
> > #include <asm/time.h>
> > +#include <asm/tm.h>
> > #include "book3s.h"
> >
> > #define OP_19_XOP_RFID 18
> > @@ -47,6 +48,8 @@
> > #define OP_31_XOP_EIOIO 854
> > #define OP_31_XOP_SLBMFEE 915
> >
> > +#define OP_31_XOP_TBEGIN 654
> > +
> > /* DCBZ is actually 1014, but we patch it to 1010 so we get a trap */
> > #define OP_31_XOP_DCBZ 1010
> >
> > @@ -362,6 +365,46 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
> >
> > break;
> > }
> > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > + case OP_31_XOP_TBEGIN:
> > + {
> > + if (!cpu_has_feature(CPU_FTR_TM))
> > + break;
> > +
> > + if (!(kvmppc_get_msr(vcpu) & MSR_TM)) {
> > + kvmppc_trigger_fac_interrupt(vcpu, FSCR_TM_LG);
> > + emulated = EMULATE_AGAIN;
> > + break;
> > + }
> > +
> > + if (!(kvmppc_get_msr(vcpu) & MSR_PR)) {
> > + preempt_disable();
> > + vcpu->arch.cr = (CR0_TBEGIN_FAILURE |
> > + (vcpu->arch.cr & ~(CR0_MASK << CR0_SHIFT)));
> > +
> > + vcpu->arch.texasr = (TEXASR_FS | TEXASR_EX |
> > + (((u64)(TM_CAUSE_EMULATE | TM_CAUSE_PERSISTENT))
> > + << TEXASR_FC_LG));
> > +
> > + if ((inst >> 21) & 0x1)
> > + vcpu->arch.texasr |= TEXASR_ROT;
> > +
> > + if (kvmppc_get_msr(vcpu) & MSR_PR)
> > + vcpu->arch.texasr |= TEXASR_PR;
>
> This if statement seems unnecessary, since we only get here when
> MSR_PR is clear.
Yes. I will remove that.
Thanks,
- Simon
^ permalink raw reply
* Re: [PATCH v2 29/30] KVM: PPC: add KVM_SET_ONE_REG/KVM_GET_ONE_REG to async ioctl
From: Simon Guo @ 2018-05-16 2:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20180515061526.GE28451@fergus.ozlabs.ibm.com>
Hi Paul,
On Tue, May 15, 2018 at 04:15:26PM +1000, Paul Mackerras wrote:
> On Wed, Feb 28, 2018 at 01:52:37AM +0800, wei.guo.simon@gmail.com wrote:
> > From: Simon Guo <wei.guo.simon@gmail.com>
> >
> > In both HV/PR KVM, the KVM_SET_ONE_REG/KVM_GET_ONE_REG ioctl should
> > be able to perform without load vcpu. This patch adds
> > KVM_SET_ONE_REG/KVM_GET_ONE_REG implementation to async ioctl
> > function.
> >
> > Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
> > ---
> > arch/powerpc/kvm/powerpc.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 7987fa3..6afd004 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -1619,6 +1619,19 @@ long kvm_arch_vcpu_async_ioctl(struct file *filp,
> > return -EFAULT;
> > return kvm_vcpu_ioctl_interrupt(vcpu, &irq);
> > }
> > +
> > + if ((ioctl == KVM_SET_ONE_REG) || (ioctl == KVM_GET_ONE_REG)) {
> > + struct kvm_one_reg reg;
> > +
> > + if (copy_from_user(®, argp, sizeof(reg)))
> > + return -EFAULT;
> > +
> > + if (ioctl == KVM_SET_ONE_REG)
> > + return kvm_vcpu_ioctl_set_one_reg(vcpu, ®);
> > + else
> > + return kvm_vcpu_ioctl_get_one_reg(vcpu, ®);
> > + }
> > +
> > return -ENOIOCTLCMD;
> > }
>
> This seems dangerous to me, since now we can have set/get one_reg
> running in parallel with vcpu execution. Is there a really compelling
> reason to do this? If not I'd rather not make this change.
I will remove this patch.
Thanks,
- Simon
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
From: Michael Ellerman @ 2018-05-16 2:37 UTC (permalink / raw)
To: Steven Rostedt
Cc: Nicholas Piggin, Masahiro Yamada, linuxppc-dev, linux-kbuild
In-Reply-To: <20180515104324.5230d827@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Tue, 15 May 2018 15:24:21 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> > Have you tried building all current archs with function tracing enabled
>> > to make sure this doesn't break any of them? I can do it if you want.
>>
>> We shouldn't need to should we? This is only touching powerpc specific
>> code (if I understand perl that is).
>>
>> eg:
>>
>> $ git diff -U9 scripts/recordmcount.pl
>
> Thanks for the added context!
>
> Yeah, I don't look at that code much anymore since I mainly deal with
> recordmcount.c now-a-days. I wonder if someone should port ppc to that.
Ah right. I didn't realise they were mutually exclusive. I'll add a TODO
for us to port over to the C version.
> It is also no my todo list to merge that with objtool.
>
> Anyway,
>
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH v10 23/25] mm: add speculative page fault vmstats
From: Ganesh Mahendran @ 2018-05-16 2:50 UTC (permalink / raw)
To: Laurent Dufour
Cc: Andrew Morton, Michal Hocko, Peter Zijlstra, kirill, ak, dave,
jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
Sergey Senozhatsky, Daniel Jordan, David Rientjes, Jerome Glisse,
linux-kernel, Linux-MM, haren, khandual, npiggin, Balbir Singh,
Paul McKenney, Tim Chen, linuxppc-dev, x86
In-Reply-To: <1523975611-15978-24-git-send-email-ldufour@linux.vnet.ibm.com>
2018-04-17 22:33 GMT+08:00 Laurent Dufour <ldufour@linux.vnet.ibm.com>:
> Add speculative_pgfault vmstat counter to count successful speculative page
> fault handling.
>
> Also fixing a minor typo in include/linux/vm_event_item.h.
>
> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> ---
> include/linux/vm_event_item.h | 3 +++
> mm/memory.c | 1 +
> mm/vmstat.c | 5 ++++-
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> index 5c7f010676a7..a240acc09684 100644
> --- a/include/linux/vm_event_item.h
> +++ b/include/linux/vm_event_item.h
> @@ -111,6 +111,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> SWAP_RA,
> SWAP_RA_HIT,
> #endif
> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> + SPECULATIVE_PGFAULT,
> +#endif
> NR_VM_EVENT_ITEMS
> };
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 425f07e0bf38..1cd5bc000643 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4508,6 +4508,7 @@ int __handle_speculative_fault(struct mm_struct *mm, unsigned long address,
> * If there is no need to retry, don't return the vma to the caller.
> */
> if (ret != VM_FAULT_RETRY) {
> + count_vm_event(SPECULATIVE_PGFAULT);
> put_vma(vmf.vma);
> *vma = NULL;
> }
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 536332e988b8..c6b49bfa8139 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1289,7 +1289,10 @@ const char * const vmstat_text[] = {
> "swap_ra",
> "swap_ra_hit",
> #endif
> -#endif /* CONFIG_VM_EVENTS_COUNTERS */
> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> + "speculative_pgfault"
"speculative_pgfault",
will be better. :)
> +#endif
> +#endif /* CONFIG_VM_EVENT_COUNTERS */
> };
> #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA */
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Detect the presence of big-core with interleaved threads
From: Gautham R Shenoy @ 2018-05-16 4:35 UTC (permalink / raw)
To: Michael Neuling
Cc: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Vaidyanathan Srinivasan, Akshay Adiga, Shilpasri G Bhat,
Balbir Singh, Oliver O'Halloran, Nicholas Piggin,
linuxppc-dev, linux-kernel
In-Reply-To: <1526268071.30369.20.camel@neuling.org>
Hi Mikey,
On Mon, May 14, 2018 at 01:21:11PM +1000, Michael Neuling wrote:
> Thanks for posting this... A couple of comments below.
Thanks for the review. Replies below.
> > +/*
> > + * check_for_interleaved_big_core - Checks if the core represented by
> > + * dn is a big-core whose threads are interleavings of the
> > + * threads of the component small cores.
> > + *
> > + * @dn: device node corresponding to the core.
> > + *
> > + * Returns true if the core is a interleaved big-core.
> > + * Returns false otherwise.
> > + */
> > +static inline bool check_for_interleaved_big_core(struct device_node *dn)
> > +{
> > + int len, nr_groups, threads_per_group;
> > + const __be32 *thread_groups;
> > + __be32 *thread_list, *first_cpu_idx;
> > + int cur_cpu, next_cpu, i, j;
> > +
> > + thread_groups = of_get_property(dn, "ibm,thread-groups", &len);
> > + if (!thread_groups)
> > + return false;
>
> Can you document what this property looks like? Seems to be nr_groups,
> threads_per_group, thread_list. Can you explain what each of these
> > mean?
Sure. I will document this in the next version of the patch.
ibm,thread-groups[0..N-1] array defines which group of threads in the
CPU-device node can be grouped together based on the property.
ibm,thread-groups[0] tells us the property based on which the threads
are being grouped together. If this value is 1, it implies that
the threads in the same group share L1, translation cache.
ibm,thread-groups[1] tells us how many such thread groups exist.
ibm,thread-groups[2] tells us the number of threads in each such group.
ibm,thread-groups[3..N-1] is the list of threads identified by
"ibm,ppc-interrupt-server#s" arranged as per their membership in the
grouping.
Example: If ibm,thread-groups[ ] = {1,2,4,5,6,7,8,9,10,11,12}
it implies that there are 2 groups of 4 threads each, where each group
of threads share L1, translation cache.
The "ibm,ppc-interrupt-server#s" of the first group is {5,6,7,8} and
the "ibm,ppc-interrupt-server#s" of the second group is {9, 10, 11, 12}
>
> If we get configured with an SMT2 big-core (ie. two interleaved SMT1 normal
> cores), will this code also work there?
No, this code won't work there. I hadn't considered the case where
each group consists of only one thread. Thanks for pointing this out.
>
> > +
> > + nr_groups = be32_to_cpu(*(thread_groups + 1));
> > + if (nr_groups <= 1)
> > + return false;
> > +
> > + threads_per_group = be32_to_cpu(*(thread_groups + 2));
> > + thread_list = (__be32 *)thread_groups + 3;
> > +
> > + /*
> > + * In case of an interleaved big-core, the thread-ids of the
> > + * big-core can be obtained by interleaving the the thread-ids
> > + * of the component small
> > + *
> > + * Eg: On a 8-thread big-core with two SMT4 small cores, the
> > + * threads of the two component small cores will be
> > + * {0, 2, 4, 6} and {1, 3, 5, 7}.
> > + */
> > + for (i = 0; i < nr_groups; i++) {
> > + first_cpu_idx = thread_list + i * threads_per_group;
> > +
> > + for (j = 0; j < threads_per_group - 1; j++) {
> > + cur_cpu = be32_to_cpu(*(first_cpu_idx + j));
> > + next_cpu = be32_to_cpu(*(first_cpu_idx + j + 1));
> > + if (next_cpu != cur_cpu + nr_groups)
> > + return false;
> > + }
> > + }
> > + return true;
> > +}
> >
> > /**
> > * setup_cpu_maps - initialize the following cpu maps:
> > @@ -565,7 +615,16 @@ void __init smp_setup_cpu_maps(void)
> > vdso_data->processorCount = num_present_cpus();
> > #endif /* CONFIG_PPC64 */
> >
> > - /* Initialize CPU <=> thread mapping/
> > + dn = of_find_node_by_type(NULL, "cpu");
> > + if (dn) {
> > + if (check_for_interleaved_big_core(dn)) {
> > + has_interleaved_big_core = true;
> > + pr_info("Detected interleaved big-cores\n");
>
> Is there a runtime way to check this also? If the dmesg buffer overflows, we
> lose this.
Where do you suggest we put this ? Should it be a part of
/proc/cpuinfo ?
>
> Mikey
--
Thanks and Regards
gautham.
^ permalink raw reply
* Re: [PATCH v2] powerpc: platform: cell: spufs: Change return type to vm_fault_t
From: Souptick Joarder @ 2018-05-16 4:36 UTC (permalink / raw)
To: Matthew Wilcox, Arnd Bergmann
Cc: Jeremy Kerr, benh, paulus, mpe, linuxppc-dev
In-Reply-To: <CAFqt6zY_X9obyM-ebLCWh7dL0bTMfXLP2U9QnkszbeJ2UZt8ww@mail.gmail.com>
On Thu, May 10, 2018 at 8:35 PM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> On Sat, Apr 21, 2018 at 3:04 AM, Matthew Wilcox <willy@infradead.org> wrote:
>> On Fri, Apr 20, 2018 at 11:02:39PM +0530, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler. For
>>> now, this is just documenting that the function returns
>>> a VM_FAULT value rather than an errno. Once all instances
>>> are converted, vm_fault_t will become a distinct type.
>>>
>>> Reference id -> 1c8f422059ae ("mm: change return type to
>>> vm_fault_t")
>>>
>>> We are fixing a minor bug, that the error from vm_insert_
>>> pfn() was being ignored and the effect of this is likely
>>> to be only felt in OOM situations.
>>>
>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>>
>> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
>
> Any further comment on this patch ?
If no further comment, we would like to get this patch in queue
for 4.18.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kvm: Change return type to vm_fault_t
From: Souptick Joarder @ 2018-05-16 4:41 UTC (permalink / raw)
To: paulus, benh, mpe, Matthew Wilcox; +Cc: kvm-ppc, linuxppc-dev, linux-kernel
In-Reply-To: <20180510182719.GA22217@jordon-HP-15-Notebook-PC>
On Thu, May 10, 2018 at 11:57 PM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct. For now, this is
> just documenting that the function returns a
> VM_FAULT value rather than an errno. Once all
> instances are converted, vm_fault_t will become
> a distinct type.
>
> commit 1c8f422059ae ("mm: change return type to
> vm_fault_t")
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> ---
> v2: Updated the change log
>
> arch/powerpc/kvm/book3s_64_vio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 4dffa61..346ac0d 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -237,7 +237,7 @@ static void release_spapr_tce_table(struct rcu_head *head)
> kfree(stt);
> }
>
> -static int kvm_spapr_tce_fault(struct vm_fault *vmf)
> +static vm_fault_t kvm_spapr_tce_fault(struct vm_fault *vmf)
> {
> struct kvmppc_spapr_tce_table *stt = vmf->vma->vm_file->private_data;
> struct page *page;
> --
> 1.9.1
>
If no comment, we would like to get this patch in queue
for 4.18.
^ permalink raw reply
* administrivia: mails containing HTML attachments
From: Stephen Rothwell @ 2018-05-16 4:48 UTC (permalink / raw)
To: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Hi all,
I have decided that any email sent to the linuxppc-dev mailing list
that contains an HTML attachment (or is just an HTML email) will be
rejected. The vast majority of such mail are spam (and I have to spend
time dropping them manually at the moment) and, I presume, anyone on
this list is capable of sending no HTML email.
Feel free to discuss ;-)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Enable ASYM_SMT on interleaved big-core systems
From: Gautham R Shenoy @ 2018-05-16 5:05 UTC (permalink / raw)
To: Michael Neuling
Cc: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Vaidyanathan Srinivasan, Akshay Adiga, Shilpasri G Bhat,
Balbir Singh, Oliver O'Halloran, Nicholas Piggin,
linuxppc-dev, linux-kernel
In-Reply-To: <1526268127.30369.21.camel@neuling.org>
On Mon, May 14, 2018 at 01:22:07PM +1000, Michael Neuling wrote:
> On Fri, 2018-05-11 at 16:47 +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > Each of the SMT4 cores forming a fused-core are more or less
> > independent units. Thus when multiple tasks are scheduled to run on
> > the fused core, we get the best performance when the tasks are spread
> > across the pair of SMT4 cores.
> >
> > Since the threads in the pair of SMT4 cores of an interleaved big-core
> > are numbered {0,2,4,6} and {1,3,5,7} respectively, enable ASYM_SMT on
> > such interleaved big-cores that will bias the load-balancing of tasks
> > on smaller numbered threads, which will automatically result in
> > spreading the tasks uniformly across the associated pair of SMT4
> > cores.
> >
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/kernel/smp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 9ca7148..0153f01 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1082,7 +1082,7 @@ static int powerpc_smt_flags(void)
> > {
> > int flags = SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES;
> >
> > - if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
> > + if (cpu_has_feature(CPU_FTR_ASYM_SMT) || has_interleaved_big_core) {
>
> Shouldn't we just set CPU_FTR_ASYM_SMT and leave this code
unchanged?
Yes, that would have the same effect. I refrained from doing that
since I thought CPU_FTR_ASYM_SMT has the "lower numbered threads
expedite thread-folding" connotation from the POWER7 generation.
If it is ok to overload CPU_FTR_ASYM_SMT, we can do what you suggest
and have all the changes in setup-common.c
--
Thanks and Regards
gautham.
^ permalink raw reply
* [RFC] powerpc/emulate_step: Fix kernel crash when VSX is not present
From: Ravi Bangoria @ 2018-05-16 5:40 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, naveen.n.rao, anton, cyrilbur, matthew.brown.dev,
sandipan, linuxppc-dev, linux-kernel, Ravi Bangoria
emulate_step() is not checking runtime VSX feature flag before
emulating an instruction. This can cause kernel oops when kernel
is compiled with CONFIG_VSX=y but running on machine where VSX is
not supported or disabled. Ex, while running emulate_step tests on
P6 machine:
...
emulate_step_test: lvx : PASS
emulate_step_test: stvx : PASS
Oops: Exception in kernel mode, sig: 4 [#1]
NIP [c000000000095c24] .load_vsrn+0x28/0x54
LR [c000000000094bdc] .emulate_loadstore+0x167c/0x17b0
Call Trace:
[c0000000494c3770] [40fe240c7ae147ae] 0x40fe240c7ae147ae (unreliable)
[c0000000494c37f0] [c000000000094bdc] .emulate_loadstore+0x167c/0x17b0
[c0000000494c3900] [c000000000094f6c] .emulate_step+0x25c/0x5bc
[c0000000494c39b0] [c000000000ec90dc] .test_lxvd2x_stxvd2x+0x64/0x154
[c0000000494c3b90] [c000000000ec9204] .test_emulate_step+0x38/0x4c
[c0000000494c3c00] [c00000000000de2c] .do_one_initcall+0x5c/0x2c0
[c0000000494c3cd0] [c000000000eb4bf8] .kernel_init_freeable+0x314/0x4cc
[c0000000494c3db0] [c00000000000e1e4] .kernel_init+0x24/0x160
[c0000000494c3e30] [c00000000000bc24] .ret_from_kernel_thread+0x58/0xb4
With fix:
...
emulate_step_test: stvx : PASS
emulate_step_test: lxvd2x : FAIL
emulate_step_test: stxvd2x : FAIL
Fixes: https://github.com/linuxppc/linux/issues/148
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
Note: VSX was first introduced on P6. But there are many VSX instructions
which were introduced in later versions. So ideally, analyse_instr()
should check for ISA version along with opcode.
arch/powerpc/lib/sstep.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 34d68f1b1b40..470942f9c567 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1173,6 +1173,7 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
unsigned long int val, val2;
unsigned int mb, me, sh;
long ival;
+ int type;
op->type = COMPUTE;
@@ -2544,6 +2545,15 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
#endif /* __powerpc64__ */
}
+
+#ifdef CONFIG_VSX
+ type = op->type & INSTR_TYPE_MASK;
+ if ((type == LOAD_VSX || type == STORE_VSX) &&
+ !cpu_has_feature(CPU_FTR_VSX)) {
+ return -1;
+ }
+#endif /* CONFIG_VSX */
+
return 0;
logical_done:
--
2.16.2
^ permalink raw reply related
* [PATCH v2] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Anju T Sudhakar @ 2018-05-16 6:35 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, maddy, anju, ppaidipe, bsingharora
Currently memory is allocated for core-imc based on cpu_present_mask,
which has bit 'cpu' set iff cpu is populated. We use (cpu number / threads
per core) as the array index to access the memory.
Under some circumstances firmware marks a CPU as GUARDed CPU and boot the
system, until cleared of errors, these CPU's are unavailable for all
subsequent boots. GUARDed CPUs are possible but not present from linux
view, so it blows a hole when we assume the max length of our allocation
is driven by our max present cpus, where as one of the cpus might be online
and be beyond the max present cpus, due to the hole.
So (cpu number / threads per core) value bounds the array index and leads
to memory overflow.
Call trace observed during a guard test:
Faulting instruction address: 0xc000000000149f1c
cpu 0x69: Vector: 380 (Data Access Out of Range) at [c000003fea303420]
pc:c000000000149f1c: prefetch_freepointer+0x14/0x30
lr:c00000000014e0f8: __kmalloc+0x1a8/0x1ac
sp:c000003fea3036a0
msr:9000000000009033
dar:c9c54b2c91dbf6b7
current = 0xc000003fea2c0000
paca = 0xc00000000fddd880 softe: 3 irq_happened: 0x01
pid = 1, comm = swapper/104
Linux version 4.16.7-openpower1 (smc@smc-desktop) (gcc version 6.4.0
(Buildroot 2018.02.1-00006-ga8d1126)) #2 SMP Fri May 4 16:44:54 PDT 2018
enter ? for help
call trace:
__kmalloc+0x1a8/0x1ac
(unreliable)
init_imc_pmu+0x7f4/0xbf0
opal_imc_counters_probe+0x3fc/0x43c
platform_drv_probe+0x48/0x80
driver_probe_device+0x22c/0x308
__driver_attach+0xa0/0xd8
bus_for_each_dev+0x88/0xb4
driver_attach+0x2c/0x40
bus_add_driver+0x1e8/0x228
driver_register+0xd0/0x114
__platform_driver_register+0x50/0x64
opal_imc_driver_init+0x24/0x38
do_one_initcall+0x150/0x15c
kernel_init_freeable+0x250/0x254
kernel_init+0x1c/0x150
ret_from_kernel_thread+0x5c/0xc8
Allocating memory for core-imc based on cpu_possible_mask, which has
bit 'cpu' set iff cpu is populatable, will fix this issue.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
---
arch/powerpc/perf/imc-pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index d7532e7..75fb23c 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
static void cleanup_all_core_imc_memory(void)
{
- int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
+ int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
struct imc_mem_info *ptr = core_imc_pmu->mem_info;
int size = core_imc_pmu->counter_mem_size;
@@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct device_node *parent,
if (!pmu_ptr->pmu.name)
return -ENOMEM;
- nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
+ nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info),
GFP_KERNEL);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v10 23/25] mm: add speculative page fault vmstats
From: Laurent Dufour @ 2018-05-16 6:42 UTC (permalink / raw)
To: Ganesh Mahendran
Cc: Andrew Morton, Michal Hocko, Peter Zijlstra, kirill, ak, dave,
jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
Sergey Senozhatsky, Daniel Jordan, David Rientjes, Jerome Glisse,
linux-kernel, Linux-MM, haren, khandual, npiggin, Balbir Singh,
Paul McKenney, Tim Chen, linuxppc-dev, x86
In-Reply-To: <CADAEsF-DbqdOWcbzjvOTbrounCQP5pLmAZBKByfG165bu82_pA@mail.gmail.com>
On 16/05/2018 04:50, Ganesh Mahendran wrote:
> 2018-04-17 22:33 GMT+08:00 Laurent Dufour <ldufour@linux.vnet.ibm.com>:
>> Add speculative_pgfault vmstat counter to count successful speculative page
>> fault handling.
>>
>> Also fixing a minor typo in include/linux/vm_event_item.h.
>>
>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> ---
>> include/linux/vm_event_item.h | 3 +++
>> mm/memory.c | 1 +
>> mm/vmstat.c | 5 ++++-
>> 3 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
>> index 5c7f010676a7..a240acc09684 100644
>> --- a/include/linux/vm_event_item.h
>> +++ b/include/linux/vm_event_item.h
>> @@ -111,6 +111,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
>> SWAP_RA,
>> SWAP_RA_HIT,
>> #endif
>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> + SPECULATIVE_PGFAULT,
>> +#endif
>> NR_VM_EVENT_ITEMS
>> };
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 425f07e0bf38..1cd5bc000643 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4508,6 +4508,7 @@ int __handle_speculative_fault(struct mm_struct *mm, unsigned long address,
>> * If there is no need to retry, don't return the vma to the caller.
>> */
>> if (ret != VM_FAULT_RETRY) {
>> + count_vm_event(SPECULATIVE_PGFAULT);
>> put_vma(vmf.vma);
>> *vma = NULL;
>> }
>> diff --git a/mm/vmstat.c b/mm/vmstat.c
>> index 536332e988b8..c6b49bfa8139 100644
>> --- a/mm/vmstat.c
>> +++ b/mm/vmstat.c
>> @@ -1289,7 +1289,10 @@ const char * const vmstat_text[] = {
>> "swap_ra",
>> "swap_ra_hit",
>> #endif
>> -#endif /* CONFIG_VM_EVENTS_COUNTERS */
>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> + "speculative_pgfault"
>
> "speculative_pgfault",
> will be better. :)
Sure !
Thanks.
>
>> +#endif
>> +#endif /* CONFIG_VM_EVENT_COUNTERS */
>> };
>> #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA */
>>
>> --
>> 2.7.4
>>
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: ppaidipe @ 2018-05-16 6:48 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: mpe, linuxppc-dev, maddy, bsingharora
In-Reply-To: <1526452518-12611-1-git-send-email-anju@linux.vnet.ibm.com>
On 2018-05-16 12:05, Anju T Sudhakar wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask,
> which has bit 'cpu' set iff cpu is populated. We use (cpu number /
> threads
> per core) as the array index to access the memory.
>
> Under some circumstances firmware marks a CPU as GUARDed CPU and boot
> the
> system, until cleared of errors, these CPU's are unavailable for all
> subsequent boots. GUARDed CPUs are possible but not present from linux
> view, so it blows a hole when we assume the max length of our
> allocation
> is driven by our max present cpus, where as one of the cpus might be
> online
> and be beyond the max present cpus, due to the hole.
> So (cpu number / threads per core) value bounds the array index and
> leads
> to memory overflow.
>
> Call trace observed during a guard test:
>
> Faulting instruction address: 0xc000000000149f1c
> cpu 0x69: Vector: 380 (Data Access Out of Range) at [c000003fea303420]
> pc:c000000000149f1c: prefetch_freepointer+0x14/0x30
> lr:c00000000014e0f8: __kmalloc+0x1a8/0x1ac
> sp:c000003fea3036a0
> msr:9000000000009033
> dar:c9c54b2c91dbf6b7
> current = 0xc000003fea2c0000
> paca = 0xc00000000fddd880 softe: 3 irq_happened: 0x01
> pid = 1, comm = swapper/104
> Linux version 4.16.7-openpower1 (smc@smc-desktop) (gcc version 6.4.0
> (Buildroot 2018.02.1-00006-ga8d1126)) #2 SMP Fri May 4 16:44:54 PDT
> 2018
> enter ? for help
> call trace:
> __kmalloc+0x1a8/0x1ac
> (unreliable)
> init_imc_pmu+0x7f4/0xbf0
> opal_imc_counters_probe+0x3fc/0x43c
> platform_drv_probe+0x48/0x80
> driver_probe_device+0x22c/0x308
> __driver_attach+0xa0/0xd8
> bus_for_each_dev+0x88/0xb4
> driver_attach+0x2c/0x40
> bus_add_driver+0x1e8/0x228
> driver_register+0xd0/0x114
> __platform_driver_register+0x50/0x64
> opal_imc_driver_init+0x24/0x38
> do_one_initcall+0x150/0x15c
> kernel_init_freeable+0x250/0x254
> kernel_init+0x1c/0x150
> ret_from_kernel_thread+0x5c/0xc8
>
> Allocating memory for core-imc based on cpu_possible_mask, which has
> bit 'cpu' set iff cpu is populatable, will fix this issue.
>
> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
I have verified this fix with both normal and kexec boot multiple times
when
system is having GARDed cores. Not seen any crash/memory corruption
issues with
this.
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index d7532e7..75fb23c 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
>
> static void cleanup_all_core_imc_memory(void)
> {
> - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
> + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(),
> threads_per_core);
> struct imc_mem_info *ptr = core_imc_pmu->mem_info;
> int size = core_imc_pmu->counter_mem_size;
>
> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr,
> struct device_node *parent,
> if (!pmu_ptr->pmu.name)
> return -ENOMEM;
>
> - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
> + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
> pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info),
> GFP_KERNEL);
^ permalink raw reply
* [PATCH] powerpc: get rid of PMD_PAGE_SIZE()
From: Christophe Leroy @ 2018-05-16 6:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
PMD_PAGE_SIZE() is nowhere used, this patch removes it
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/nohash/32/pte-40x.h | 2 --
arch/powerpc/include/asm/pte-common.h | 5 -----
2 files changed, 7 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/32/pte-40x.h b/arch/powerpc/include/asm/nohash/32/pte-40x.h
index 124f9ac23a1e..1918fba42433 100644
--- a/arch/powerpc/include/asm/nohash/32/pte-40x.h
+++ b/arch/powerpc/include/asm/nohash/32/pte-40x.h
@@ -56,8 +56,6 @@
#define _PMD_SIZE_4M 0x0c0
#define _PMD_SIZE_16M 0x0e0
-#define PMD_PAGE_SIZE(pmdval) (1024 << (((pmdval) & _PMD_SIZE) >> 4))
-
/* Until my rework is finished, 40x still needs atomic PTE updates */
#define PTE_ATOMIC_UPDATES 1
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index c4a72c7a8c83..0c070107825c 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -62,7 +62,6 @@
#endif
#ifndef _PMD_SIZE
#define _PMD_SIZE 0
-#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
#endif
#ifndef _PMD_USER
#define _PMD_USER 0
@@ -88,11 +87,7 @@
#define _PTE_NONE_MASK _PAGE_HPTEFLAGS
#endif
-/* Make sure we get a link error if PMD_PAGE_SIZE is ever called on a
- * kernel without large page PMD support
- */
#ifndef __ASSEMBLY__
-extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
/*
* Don't just check for any non zero bits in __PAGE_USER, since for book3e
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v2] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Anju T Sudhakar @ 2018-05-16 6:46 UTC (permalink / raw)
To: ppaidipe; +Cc: mpe, linuxppc-dev, maddy, bsingharora
In-Reply-To: <0df1478ff69b9e2f2c70897a472ada39@linux.vnet.ibm.com>
On Wednesday 16 May 2018 12:18 PM, ppaidipe wrote:
> On 2018-05-16 12:05, Anju T Sudhakar wrote:
>> Currently memory is allocated for core-imc based on cpu_present_mask,
>> which has bit 'cpu' set iff cpu is populated. We use (cpu number /
>> threads
>> per core) as the array index to access the memory.
>>
>> Under some circumstances firmware marks a CPU as GUARDed CPU and boot
>> the
>> system, until cleared of errors, these CPU's are unavailable for all
>> subsequent boots. GUARDed CPUs are possible but not present from linux
>> view, so it blows a hole when we assume the max length of our allocation
>> is driven by our max present cpus, where as one of the cpus might be
>> online
>> and be beyond the max present cpus, due to the hole.
>> So (cpu number / threads per core) value bounds the array index and
>> leads
>> to memory overflow.
>>
>> Call trace observed during a guard test:
>>
>> Faulting instruction address: 0xc000000000149f1c
>> cpu 0x69: Vector: 380 (Data Access Out of Range) at [c000003fea303420]
>> pc:c000000000149f1c: prefetch_freepointer+0x14/0x30
>> lr:c00000000014e0f8: __kmalloc+0x1a8/0x1ac
>> sp:c000003fea3036a0
>> msr:9000000000009033
>> dar:c9c54b2c91dbf6b7
>> current = 0xc000003fea2c0000
>> paca = 0xc00000000fddd880 softe: 3 irq_happened: 0x01
>> pid = 1, comm = swapper/104
>> Linux version 4.16.7-openpower1 (smc@smc-desktop) (gcc version 6.4.0
>> (Buildroot 2018.02.1-00006-ga8d1126)) #2 SMP Fri May 4 16:44:54 PDT 2018
>> enter ? for help
>> call trace:
>> __kmalloc+0x1a8/0x1ac
>> (unreliable)
>> init_imc_pmu+0x7f4/0xbf0
>> opal_imc_counters_probe+0x3fc/0x43c
>> platform_drv_probe+0x48/0x80
>> driver_probe_device+0x22c/0x308
>> __driver_attach+0xa0/0xd8
>> bus_for_each_dev+0x88/0xb4
>> driver_attach+0x2c/0x40
>> bus_add_driver+0x1e8/0x228
>> driver_register+0xd0/0x114
>> __platform_driver_register+0x50/0x64
>> opal_imc_driver_init+0x24/0x38
>> do_one_initcall+0x150/0x15c
>> kernel_init_freeable+0x250/0x254
>> kernel_init+0x1c/0x150
>> ret_from_kernel_thread+0x5c/0xc8
>>
>> Allocating memory for core-imc based on cpu_possible_mask, which has
>> bit 'cpu' set iff cpu is populatable, will fix this issue.
>>
>> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
>> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
>
> I have verified this fix with both normal and kexec boot multiple
> times when
> system is having GARDed cores. Not seen any crash/memory corruption
> issues with
> this.
>
> Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>
>
Thanks.
-Anju
>> ---
>> arch/powerpc/perf/imc-pmu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
>> index d7532e7..75fb23c 100644
>> --- a/arch/powerpc/perf/imc-pmu.c
>> +++ b/arch/powerpc/perf/imc-pmu.c
>> @@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
>>
>> static void cleanup_all_core_imc_memory(void)
>> {
>> - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(),
>> threads_per_core);
>> + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(),
>> threads_per_core);
>> struct imc_mem_info *ptr = core_imc_pmu->mem_info;
>> int size = core_imc_pmu->counter_mem_size;
>>
>> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr,
>> struct device_node *parent,
>> if (!pmu_ptr->pmu.name)
>> return -ENOMEM;
>>
>> - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
>> + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
>> pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct
>> imc_mem_info),
>> GFP_KERNEL);
^ permalink raw reply
* [PATCH] powerpc: get rid of PMD_PAGE_SIZE() and _PMD_SIZE
From: Christophe Leroy @ 2018-05-16 6:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
PMD_PAGE_SIZE() is nowhere used and _PMD_SIZE is only
used by PMD_PAGE_SIZE().
This patch removes them.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
Superseeds "powerpc: get rid of PMD_PAGE_SIZE()" sent a few minutes ago.
arch/powerpc/include/asm/nohash/32/pte-40x.h | 3 ---
arch/powerpc/include/asm/pte-common.h | 8 --------
2 files changed, 11 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/32/pte-40x.h b/arch/powerpc/include/asm/nohash/32/pte-40x.h
index 124f9ac23a1e..bb4b3a4b92a0 100644
--- a/arch/powerpc/include/asm/nohash/32/pte-40x.h
+++ b/arch/powerpc/include/asm/nohash/32/pte-40x.h
@@ -52,12 +52,9 @@
#define _PMD_PRESENT 0x400 /* PMD points to page of PTEs */
#define _PMD_BAD 0x802
-#define _PMD_SIZE 0x0e0 /* size field, != 0 for large-page PMD entry */
#define _PMD_SIZE_4M 0x0c0
#define _PMD_SIZE_16M 0x0e0
-#define PMD_PAGE_SIZE(pmdval) (1024 << (((pmdval) & _PMD_SIZE) >> 4))
-
/* Until my rework is finished, 40x still needs atomic PTE updates */
#define PTE_ATOMIC_UPDATES 1
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index c4a72c7a8c83..050b0d775324 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -60,10 +60,6 @@
#ifndef _PMD_PRESENT_MASK
#define _PMD_PRESENT_MASK _PMD_PRESENT
#endif
-#ifndef _PMD_SIZE
-#define _PMD_SIZE 0
-#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
-#endif
#ifndef _PMD_USER
#define _PMD_USER 0
#endif
@@ -88,11 +84,7 @@
#define _PTE_NONE_MASK _PAGE_HPTEFLAGS
#endif
-/* Make sure we get a link error if PMD_PAGE_SIZE is ever called on a
- * kernel without large page PMD support
- */
#ifndef __ASSEMBLY__
-extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
/*
* Don't just check for any non zero bits in __PAGE_USER, since for book3e
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v2] powerpc: kvm: Change return type to vm_fault_t
From: Paul Mackerras @ 2018-05-16 7:08 UTC (permalink / raw)
To: Souptick Joarder
Cc: benh, mpe, Matthew Wilcox, kvm-ppc, linuxppc-dev, linux-kernel
In-Reply-To: <CAFqt6zbxWkOQXtKZXyDae=ZEQR+d0xf42fvnvUoBSHQZcHRCBg@mail.gmail.com>
On Wed, May 16, 2018 at 10:11:11AM +0530, Souptick Joarder wrote:
> On Thu, May 10, 2018 at 11:57 PM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> > Use new return type vm_fault_t for fault handler
> > in struct vm_operations_struct. For now, this is
> > just documenting that the function returns a
> > VM_FAULT value rather than an errno. Once all
> > instances are converted, vm_fault_t will become
> > a distinct type.
> >
> > commit 1c8f422059ae ("mm: change return type to
> > vm_fault_t")
> >
> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> > ---
> > v2: Updated the change log
> >
> > arch/powerpc/kvm/book3s_64_vio.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> > index 4dffa61..346ac0d 100644
> > --- a/arch/powerpc/kvm/book3s_64_vio.c
> > +++ b/arch/powerpc/kvm/book3s_64_vio.c
> > @@ -237,7 +237,7 @@ static void release_spapr_tce_table(struct rcu_head *head)
> > kfree(stt);
> > }
> >
> > -static int kvm_spapr_tce_fault(struct vm_fault *vmf)
> > +static vm_fault_t kvm_spapr_tce_fault(struct vm_fault *vmf)
> > {
> > struct kvmppc_spapr_tce_table *stt = vmf->vma->vm_file->private_data;
> > struct page *page;
> > --
> > 1.9.1
> >
>
> If no comment, we would like to get this patch in queue
> for 4.18.
It looks fine - I'll queue it up.
Paul.
^ permalink raw reply
* Re: [RFC] powerpc/emulate_step: Fix kernel crash when VSX is not present
From: Naveen N. Rao @ 2018-05-16 7:08 UTC (permalink / raw)
To: mpe, Ravi Bangoria, Michael Neuling
Cc: anton, cyrilbur, linux-kernel, linuxppc-dev, matthew.brown.dev,
paulus, sandipan
In-Reply-To: <20180516054021.5328-1-ravi.bangoria@linux.ibm.com>
[Adding Mikey]
Ravi Bangoria wrote:
> emulate_step() is not checking runtime VSX feature flag before
> emulating an instruction. This can cause kernel oops when kernel
> is compiled with CONFIG_VSX=3Dy but running on machine where VSX is
> not supported or disabled. Ex, while running emulate_step tests on
> P6 machine:
>=20
> ...
> emulate_step_test: lvx : PASS
> emulate_step_test: stvx : PASS
> Oops: Exception in kernel mode, sig: 4 [#1]
> NIP [c000000000095c24] .load_vsrn+0x28/0x54
> LR [c000000000094bdc] .emulate_loadstore+0x167c/0x17b0
> Call Trace:
> [c0000000494c3770] [40fe240c7ae147ae] 0x40fe240c7ae147ae (unreliable)
> [c0000000494c37f0] [c000000000094bdc] .emulate_loadstore+0x167c/0x17b0
> [c0000000494c3900] [c000000000094f6c] .emulate_step+0x25c/0x5bc
> [c0000000494c39b0] [c000000000ec90dc] .test_lxvd2x_stxvd2x+0x64/0x154
> [c0000000494c3b90] [c000000000ec9204] .test_emulate_step+0x38/0x4c
> [c0000000494c3c00] [c00000000000de2c] .do_one_initcall+0x5c/0x2c0
> [c0000000494c3cd0] [c000000000eb4bf8] .kernel_init_freeable+0x314/0x4cc
> [c0000000494c3db0] [c00000000000e1e4] .kernel_init+0x24/0x160
> [c0000000494c3e30] [c00000000000bc24] .ret_from_kernel_thread+0x58/0xb4
>=20
> With fix:
> ...
> emulate_step_test: stvx : PASS
> emulate_step_test: lxvd2x : FAIL
> emulate_step_test: stxvd2x : FAIL
Those tests should also be updated to skip testing these instructions if=20
!CPU_FTR_VSX.
>=20
> Fixes: https://github.com/linuxppc/linux/issues/148
>=20
> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> Note: VSX was first introduced on P6. But there are many VSX instructions
> which were introduced in later versions. So ideally, analyse_instr(=
)
> should check for ISA version along with opcode.
Yes, this patch should be useful for when VSX is not present. For=20
specific instructions, we should add a cpu feature check.
- Naveen
=
^ permalink raw reply
* [PATCH v2 0/2] i2c: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-16 7:16 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Andrew Jeffery, Guenter Roeck,
Uwe Kleine-König, Pengutronix Kernel Team, Wolfram Sang,
Peter Korsgaard, Andy Gross, David Brown, Linus Walleij,
linux-i2c, openbmc, linux-arm-kernel, linux-aspeed, linuxppc-dev,
linux-arm-msm, linux-soc
Hi!
The nice little inline i2c_8bit_addr_from_msg is not getting
enough use. This series improves the situation and drops a
bunch of lines in the process.
I have only compile-tested (that part fine, at least over here).
Changes since v1 https://lkml.org/lkml/2018/5/14/919
- Squashed patches 1-3 (algos) and patches 4-21 (busses) making
the series consist of just two patches instead of 21.
- Added ack-bys and reviewed-bys from Guenter, Uwe and LinusW.
- Eliminated the flags variable in algos/i2c-algo-pcf.c
Cheers,
Peter
Peter Rosin (2):
i2c: algos: make use of i2c_8bit_addr_from_msg
i2c: busses: make use of i2c_8bit_addr_from_msg
drivers/i2c/algos/i2c-algo-bit.c | 4 +---
drivers/i2c/algos/i2c-algo-pca.c | 5 +----
drivers/i2c/algos/i2c-algo-pcf.c | 8 ++------
drivers/i2c/busses/i2c-aspeed.c | 3 +--
drivers/i2c/busses/i2c-axxia.c | 5 +++--
drivers/i2c/busses/i2c-diolan-u2c.c | 11 ++++-------
drivers/i2c/busses/i2c-efm32.c | 3 +--
drivers/i2c/busses/i2c-eg20t.c | 5 ++---
drivers/i2c/busses/i2c-emev2.c | 2 +-
drivers/i2c/busses/i2c-hix5hd2.c | 9 ++-------
drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +---
drivers/i2c/busses/i2c-imx.c | 10 +++++-----
drivers/i2c/busses/i2c-kempld.c | 7 +++----
drivers/i2c/busses/i2c-mxs.c | 9 +++------
drivers/i2c/busses/i2c-ocores.c | 5 +----
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-qup.c | 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-riic.c | 5 ++---
drivers/i2c/busses/i2c-stu300.c | 22 +++++++++++++---------
drivers/i2c/busses/i2c-xiic.c | 11 ++---------
21 files changed, 51 insertions(+), 83 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v2 1/2] i2c: algos: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-16 7:16 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Andrew Jeffery, Guenter Roeck,
Uwe Kleine-König, Pengutronix Kernel Team, Wolfram Sang,
Peter Korsgaard, Andy Gross, David Brown, Linus Walleij,
linux-i2c, openbmc, linux-arm-kernel, linux-aspeed, linuxppc-dev,
linux-arm-msm, linux-soc
In-Reply-To: <20180516071647.29277-1-peda@axentia.se>
Because it looks neater.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/algos/i2c-algo-bit.c | 4 +---
drivers/i2c/algos/i2c-algo-pca.c | 5 +----
drivers/i2c/algos/i2c-algo-pcf.c | 8 ++------
3 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 3df0efd69ae3..4a34f311e1ff 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -519,9 +519,7 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, struct i2c_msg *msg)
}
}
} else { /* normal 7bit address */
- addr = msg->addr << 1;
- if (flags & I2C_M_RD)
- addr |= 1;
+ addr = i2c_8bit_addr_from_msg(msg);
if (flags & I2C_M_REV_DIR_ADDR)
addr ^= 1;
ret = try_address(i2c_adap, addr, retries);
diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c
index e370804ec8bc..883a290f6a4d 100644
--- a/drivers/i2c/algos/i2c-algo-pca.c
+++ b/drivers/i2c/algos/i2c-algo-pca.c
@@ -112,11 +112,8 @@ static int pca_address(struct i2c_algo_pca_data *adap,
struct i2c_msg *msg)
{
int sta = pca_get_con(adap);
- int addr;
+ int addr = i2c_8bit_addr_from_msg(msg);
- addr = ((0x7f & msg->addr) << 1);
- if (msg->flags & I2C_M_RD)
- addr |= 1;
DEB2("=== SLAVE ADDRESS %#04x+%c=%#04x\n",
msg->addr, msg->flags & I2C_M_RD ? 'R' : 'W', addr);
diff --git a/drivers/i2c/algos/i2c-algo-pcf.c b/drivers/i2c/algos/i2c-algo-pcf.c
index 270d84bfc2c6..5c29a4d397cf 100644
--- a/drivers/i2c/algos/i2c-algo-pcf.c
+++ b/drivers/i2c/algos/i2c-algo-pcf.c
@@ -291,13 +291,9 @@ static int pcf_readbytes(struct i2c_adapter *i2c_adap, char *buf,
static int pcf_doAddress(struct i2c_algo_pcf_data *adap,
struct i2c_msg *msg)
{
- unsigned short flags = msg->flags;
- unsigned char addr;
+ unsigned char addr = i2c_8bit_addr_from_msg(msg);
- addr = msg->addr << 1;
- if (flags & I2C_M_RD)
- addr |= 1;
- if (flags & I2C_M_REV_DIR_ADDR)
+ if (msg->flags & I2C_M_REV_DIR_ADDR)
addr ^= 1;
i2c_outb(adap, addr);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] i2c: busses: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-16 7:16 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Andrew Jeffery, Guenter Roeck,
Uwe Kleine-König, Pengutronix Kernel Team, Wolfram Sang,
Peter Korsgaard, Andy Gross, David Brown, Linus Walleij,
linux-i2c, openbmc, linux-arm-kernel, linux-aspeed, linuxppc-dev,
linux-arm-msm, linux-soc
In-Reply-To: <20180516071647.29277-1-peda@axentia.se>
Because it looks neater.
For diolan, this allows factoring out some code that is now common
between if and else.
For eg20t, pch_i2c_writebytes is always called with a write in
msgs->flags, and pch_i2c_readbytes with a read.
For imx, i2c_imx_dma_write and i2c_imx_write are always called with a
write in msgs->flags, and i2c_imx_read with a read.
For qup, qup_i2c_write_tx_fifo_v1 is always called with a write in
qup->msg->flags.
For stu300, also restructure debug output for resends, since that
code as a result is only handling debug output.
Reviewed-by: Guenter Roeck <linux@roeck-us.net> [diolan]
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [emf32 and imx]
Acked-by: Linus Walleij <linus.walleij@linaro.org> [stu300]
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/busses/i2c-aspeed.c | 3 +--
drivers/i2c/busses/i2c-axxia.c | 5 +++--
drivers/i2c/busses/i2c-diolan-u2c.c | 11 ++++-------
drivers/i2c/busses/i2c-efm32.c | 3 +--
drivers/i2c/busses/i2c-eg20t.c | 5 ++---
drivers/i2c/busses/i2c-emev2.c | 2 +-
drivers/i2c/busses/i2c-hix5hd2.c | 9 ++-------
drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +---
drivers/i2c/busses/i2c-imx.c | 10 +++++-----
drivers/i2c/busses/i2c-kempld.c | 7 +++----
drivers/i2c/busses/i2c-mxs.c | 9 +++------
drivers/i2c/busses/i2c-ocores.c | 5 +----
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-qup.c | 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-riic.c | 5 ++---
drivers/i2c/busses/i2c-stu300.c | 22 +++++++++++++---------
drivers/i2c/busses/i2c-xiic.c | 11 ++---------
18 files changed, 47 insertions(+), 70 deletions(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 7d4aeb4465b3..60e4d0e939a3 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -335,13 +335,12 @@ static void aspeed_i2c_do_start(struct aspeed_i2c_bus *bus)
{
u32 command = ASPEED_I2CD_M_START_CMD | ASPEED_I2CD_M_TX_CMD;
struct i2c_msg *msg = &bus->msgs[bus->msgs_index];
- u8 slave_addr = msg->addr << 1;
+ u8 slave_addr = i2c_8bit_addr_from_msg(msg);
bus->master_state = ASPEED_I2C_MASTER_START;
bus->buf_index = 0;
if (msg->flags & I2C_M_RD) {
- slave_addr |= 1;
command |= ASPEED_I2CD_M_RX_CMD;
/* Need to let the hardware know to NACK after RX. */
if (msg->len == 1 && !(msg->flags & I2C_M_RECV_LEN))
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index 13f07482ec68..f70b097fd567 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -351,13 +351,15 @@ static int axxia_i2c_xfer_msg(struct axxia_i2c_dev *idev, struct i2c_msg *msg)
* addr_2: addr[7:0]
*/
addr_1 = 0xF0 | ((msg->addr >> 7) & 0x06);
+ if (i2c_m_rd(msg))
+ addr_1 |= 1; /* Set the R/nW bit of the address */
addr_2 = msg->addr & 0xFF;
} else {
/* 7-bit address
* addr_1: addr[6:0] | (R/nW)
* addr_2: dont care
*/
- addr_1 = (msg->addr << 1) & 0xFF;
+ addr_1 = i2c_8bit_addr_from_msg(msg);
addr_2 = 0;
}
@@ -365,7 +367,6 @@ static int axxia_i2c_xfer_msg(struct axxia_i2c_dev *idev, struct i2c_msg *msg)
/* I2C read transfer */
rx_xfer = i2c_m_recv_len(msg) ? I2C_SMBUS_BLOCK_MAX : msg->len;
tx_xfer = 0;
- addr_1 |= 1; /* Set the R/nW bit of the address */
} else {
/* I2C write transfer */
rx_xfer = 0;
diff --git a/drivers/i2c/busses/i2c-diolan-u2c.c b/drivers/i2c/busses/i2c-diolan-u2c.c
index f718ee4e3332..3f28317cde39 100644
--- a/drivers/i2c/busses/i2c-diolan-u2c.c
+++ b/drivers/i2c/busses/i2c-diolan-u2c.c
@@ -360,11 +360,11 @@ static int diolan_usb_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs,
if (ret < 0)
goto abort;
}
+ ret = diolan_i2c_put_byte_ack(dev,
+ i2c_8bit_addr_from_msg(pmsg));
+ if (ret < 0)
+ goto abort;
if (pmsg->flags & I2C_M_RD) {
- ret =
- diolan_i2c_put_byte_ack(dev, (pmsg->addr << 1) | 1);
- if (ret < 0)
- goto abort;
for (j = 0; j < pmsg->len; j++) {
u8 byte;
bool ack = j < pmsg->len - 1;
@@ -393,9 +393,6 @@ static int diolan_usb_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs,
pmsg->buf[j] = byte;
}
} else {
- ret = diolan_i2c_put_byte_ack(dev, pmsg->addr << 1);
- if (ret < 0)
- goto abort;
for (j = 0; j < pmsg->len; j++) {
ret = diolan_i2c_put_byte_ack(dev,
pmsg->buf[j]);
diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
index aa336ba89aa3..5f2bab878b2c 100644
--- a/drivers/i2c/busses/i2c-efm32.c
+++ b/drivers/i2c/busses/i2c-efm32.c
@@ -144,8 +144,7 @@ static void efm32_i2c_send_next_msg(struct efm32_i2c_ddata *ddata)
struct i2c_msg *cur_msg = &ddata->msgs[ddata->current_msg];
efm32_i2c_write32(ddata, REG_CMD, REG_CMD_START);
- efm32_i2c_write32(ddata, REG_TXDATA, cur_msg->addr << 1 |
- (cur_msg->flags & I2C_M_RD ? 1 : 0));
+ efm32_i2c_write32(ddata, REG_TXDATA, i2c_8bit_addr_from_msg(cur_msg));
}
static void efm32_i2c_send_next_byte(struct efm32_i2c_ddata *ddata)
diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
index bdeab0174fec..835d54ac2971 100644
--- a/drivers/i2c/busses/i2c-eg20t.c
+++ b/drivers/i2c/busses/i2c-eg20t.c
@@ -414,7 +414,7 @@ static s32 pch_i2c_writebytes(struct i2c_adapter *i2c_adap,
iowrite32(addr_8_lsb, p + PCH_I2CDR);
} else {
/* set 7 bit slave address and R/W bit as 0 */
- iowrite32(addr << 1, p + PCH_I2CDR);
+ iowrite32(i2c_8bit_addr_from_msg(msgs), p + PCH_I2CDR);
if (first)
pch_i2c_start(adap);
}
@@ -538,8 +538,7 @@ static s32 pch_i2c_readbytes(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
iowrite32(addr_2_msb | TEN_BIT_ADDR_MASK, p + PCH_I2CDR);
} else {
/* 7 address bits + R/W bit */
- addr = (((addr) << 1) | (I2C_RD));
- iowrite32(addr, p + PCH_I2CDR);
+ iowrite32(i2c_8bit_addr_from_msg(msgs), p + PCH_I2CDR);
}
/* check if it is the first message */
diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index d2e84480fbe9..ba9b6ea48a31 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -149,7 +149,7 @@ static int __em_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,
em_clear_set_bit(priv, 0, I2C_BIT_STT0, I2C_OFS_IICC0);
/* Send slave address and R/W type */
- writeb((msg->addr << 1) | read, priv->base + I2C_OFS_IIC0);
+ writeb(i2c_8bit_addr_from_msg(msg), priv->base + I2C_OFS_IIC0);
/* Wait for transaction */
status = em_i2c_wait_for_event(priv);
diff --git a/drivers/i2c/busses/i2c-hix5hd2.c b/drivers/i2c/busses/i2c-hix5hd2.c
index bb68957d3da5..399b64c4c620 100644
--- a/drivers/i2c/busses/i2c-hix5hd2.c
+++ b/drivers/i2c/busses/i2c-hix5hd2.c
@@ -73,7 +73,6 @@
#define I2C_OVER_INTR BIT(0)
#define HIX5I2C_MAX_FREQ 400000 /* 400k */
-#define HIX5I2C_READ_OPERATION 0x01
enum hix5hd2_i2c_state {
HIX5I2C_STAT_RW_ERR = -1,
@@ -311,12 +310,8 @@ static void hix5hd2_i2c_message_start(struct hix5hd2_i2c_priv *priv, int stop)
hix5hd2_i2c_clr_all_irq(priv);
hix5hd2_i2c_enable_irq(priv);
- if (priv->msg->flags & I2C_M_RD)
- writel_relaxed((priv->msg->addr << 1) | HIX5I2C_READ_OPERATION,
- priv->regs + HIX5I2C_TXR);
- else
- writel_relaxed(priv->msg->addr << 1,
- priv->regs + HIX5I2C_TXR);
+ writel_relaxed(i2c_8bit_addr_from_msg(priv->msg),
+ priv->regs + HIX5I2C_TXR);
writel_relaxed(I2C_WRITE | I2C_START, priv->regs + HIX5I2C_COM);
spin_unlock_irqrestore(&priv->lock, flags);
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6da2c7a9a3e..159d23211600 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -180,15 +180,13 @@ static int lpi2c_imx_start(struct lpi2c_imx_struct *lpi2c_imx,
struct i2c_msg *msgs)
{
unsigned int temp;
- u8 read;
temp = readl(lpi2c_imx->base + LPI2C_MCR);
temp |= MCR_RRF | MCR_RTF;
writel(temp, lpi2c_imx->base + LPI2C_MCR);
writel(0x7f00, lpi2c_imx->base + LPI2C_MSR);
- read = msgs->flags & I2C_M_RD;
- temp = (msgs->addr << 1 | read) | (GEN_START << 8);
+ temp = i2c_8bit_addr_from_msg(msgs) | (GEN_START << 8);
writel(temp, lpi2c_imx->base + LPI2C_MTDR);
return lpi2c_imx_bus_busy(lpi2c_imx);
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index d7267dd9c7bf..bcb41fc75043 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -630,7 +630,7 @@ static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
* Write slave address.
* The first byte must be transmitted by the CPU.
*/
- imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
+ imx_i2c_write_reg(i2c_8bit_addr_from_msg(msgs), i2c_imx, IMX_I2C_I2DR);
reinit_completion(&i2c_imx->dma->cmd_complete);
time_left = wait_for_completion_timeout(
&i2c_imx->dma->cmd_complete,
@@ -760,10 +760,10 @@ static int i2c_imx_write(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs)
int i, result;
dev_dbg(&i2c_imx->adapter.dev, "<%s> write slave address: addr=0x%x\n",
- __func__, msgs->addr << 1);
+ __func__, i2c_8bit_addr_from_msg(msgs));
/* write slave address */
- imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
+ imx_i2c_write_reg(i2c_8bit_addr_from_msg(msgs), i2c_imx, IMX_I2C_I2DR);
result = i2c_imx_trx_complete(i2c_imx);
if (result)
return result;
@@ -796,10 +796,10 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs, bo
dev_dbg(&i2c_imx->adapter.dev,
"<%s> write slave address: addr=0x%x\n",
- __func__, (msgs->addr << 1) | 0x01);
+ __func__, i2c_8bit_addr_from_msg(msgs));
/* write slave address */
- imx_i2c_write_reg((msgs->addr << 1) | 0x01, i2c_imx, IMX_I2C_I2DR);
+ imx_i2c_write_reg(i2c_8bit_addr_from_msg(msgs), i2c_imx, IMX_I2C_I2DR);
result = i2c_imx_trx_complete(i2c_imx);
if (result)
return result;
diff --git a/drivers/i2c/busses/i2c-kempld.c b/drivers/i2c/busses/i2c-kempld.c
index e879190b5d1d..1c874aaa0447 100644
--- a/drivers/i2c/busses/i2c-kempld.c
+++ b/drivers/i2c/busses/i2c-kempld.c
@@ -124,15 +124,14 @@ static int kempld_i2c_process(struct kempld_i2c_data *i2c)
/* 10 bit address? */
if (i2c->msg->flags & I2C_M_TEN) {
addr = 0xf0 | ((i2c->msg->addr >> 7) & 0x6);
+ /* Set read bit if necessary */
+ addr |= (i2c->msg->flags & I2C_M_RD) ? 1 : 0;
i2c->state = STATE_ADDR10;
} else {
- addr = (i2c->msg->addr << 1);
+ addr = i2c_8bit_addr_from_msg(i2c->msg);
i2c->state = STATE_START;
}
- /* Set read bit if necessary */
- addr |= (i2c->msg->flags & I2C_M_RD) ? 1 : 0;
-
kempld_write8(pld, KEMPLD_I2C_DATA, addr);
kempld_write8(pld, KEMPLD_I2C_CMD, I2C_CMD_START);
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index e617bd600794..f62ae3d42232 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -180,9 +180,10 @@ static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
struct dma_async_tx_descriptor *desc;
struct mxs_i2c_dev *i2c = i2c_get_adapdata(adap);
+ i2c->addr_data = i2c_8bit_addr_from_msg(msg);
+
if (msg->flags & I2C_M_RD) {
i2c->dma_read = true;
- i2c->addr_data = (msg->addr << 1) | I2C_SMBUS_READ;
/*
* SELECT command.
@@ -240,7 +241,6 @@ static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
}
} else {
i2c->dma_read = false;
- i2c->addr_data = (msg->addr << 1) | I2C_SMBUS_WRITE;
/*
* WRITE command.
@@ -371,7 +371,7 @@ static int mxs_i2c_pio_setup_xfer(struct i2c_adapter *adap,
struct i2c_msg *msg, uint32_t flags)
{
struct mxs_i2c_dev *i2c = i2c_get_adapdata(adap);
- uint32_t addr_data = msg->addr << 1;
+ uint32_t addr_data = i2c_8bit_addr_from_msg(msg);
uint32_t data = 0;
int i, ret, xlen = 0, xmit = 0;
uint32_t start;
@@ -411,8 +411,6 @@ static int mxs_i2c_pio_setup_xfer(struct i2c_adapter *adap,
*/
BUG_ON(msg->len > 4);
- addr_data |= I2C_SMBUS_READ;
-
/* SELECT command. */
mxs_i2c_pio_trigger_write_cmd(i2c, MXS_CMD_I2C_SELECT,
addr_data);
@@ -450,7 +448,6 @@ static int mxs_i2c_pio_setup_xfer(struct i2c_adapter *adap,
* fast enough. It is possible to transfer arbitrary amount
* of data using PIO write.
*/
- addr_data |= I2C_SMBUS_WRITE;
/*
* The LSB of data buffer is the first byte blasted across
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 8c42ca7107b2..a540916689b2 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -222,10 +222,7 @@ static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
i2c->nmsgs = num;
i2c->state = STATE_START;
- oc_setreg(i2c, OCI2C_DATA,
- (i2c->msg->addr << 1) |
- ((i2c->msg->flags & I2C_M_RD) ? 1:0));
-
+ oc_setreg(i2c, OCI2C_DATA, i2c_8bit_addr_from_msg(i2c->msg));
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_START);
if (wait_event_timeout(i2c->wait, (i2c->state == STATE_ERROR) ||
diff --git a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
index df1dbc92a024..55fd5c6f3cca 100644
--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -121,7 +121,7 @@ static int pasemi_i2c_xfer_msg(struct i2c_adapter *adapter,
read = msg->flags & I2C_M_RD ? 1 : 0;
- TXFIFO_WR(smbus, MTXFIFO_START | (msg->addr << 1) | read);
+ TXFIFO_WR(smbus, MTXFIFO_START | i2c_8bit_addr_from_msg(msg));
if (read) {
TXFIFO_WR(smbus, msg->len | MTXFIFO_READ |
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 904dfec7ab96..025232207aeb 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -453,7 +453,7 @@ static void qup_i2c_write_tx_fifo_v1(struct qup_i2c_dev *qup)
{
struct qup_i2c_block *blk = &qup->blk;
struct i2c_msg *msg = qup->msg;
- u32 addr = msg->addr << 1;
+ u32 addr = i2c_8bit_addr_from_msg(msg);
u32 qup_tag;
int idx;
u32 val;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index c6915b835396..17b91ddbe013 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -329,7 +329,7 @@ static void rcar_i2c_prepare_msg(struct rcar_i2c_priv *priv)
if (priv->msgs_left == 1)
priv->flags |= ID_LAST_MSG;
- rcar_i2c_write(priv, ICMAR, (priv->msg->addr << 1) | read);
+ rcar_i2c_write(priv, ICMAR, i2c_8bit_addr_from_msg(priv->msg));
/*
* We don't have a test case but the HW engineers say that the write order
* of ICMSR and ICMCR depends on whether we issue START or REP_START. Since
diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c
index 95c2f1ce3cad..5f1fca7880b1 100644
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -167,15 +167,14 @@ static irqreturn_t riic_tdre_isr(int irq, void *data)
return IRQ_NONE;
if (riic->bytes_left == RIIC_INIT_MSG) {
- val = !!(riic->msg->flags & I2C_M_RD);
- if (val)
+ if (riic->msg->flags & I2C_M_RD)
/* On read, switch over to receive interrupt */
riic_clear_set_bit(riic, ICIER_TIE, ICIER_RIE, RIIC_ICIER);
else
/* On write, initialize length */
riic->bytes_left = riic->msg->len;
- val |= (riic->msg->addr << 1);
+ val = i2c_8bit_addr_from_msg(riic->msg);
} else {
val = *riic->buf;
riic->buf++;
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index dc63236b45b2..e866c481bfc3 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -602,20 +602,24 @@ static int stu300_send_address(struct stu300_dev *dev,
u32 val;
int ret;
- if (msg->flags & I2C_M_TEN)
+ if (msg->flags & I2C_M_TEN) {
/* This is probably how 10 bit addresses look */
val = (0xf0 | (((u32) msg->addr & 0x300) >> 7)) &
I2C_DR_D_MASK;
- else
- val = ((msg->addr << 1) & I2C_DR_D_MASK);
+ if (msg->flags & I2C_M_RD)
+ /* This is the direction bit */
+ val |= 0x01;
+ } else {
+ val = i2c_8bit_addr_from_msg(msg);
+ }
- if (msg->flags & I2C_M_RD) {
- /* This is the direction bit */
- val |= 0x01;
- if (resend)
+ if (resend) {
+ if (msg->flags & I2C_M_RD)
dev_dbg(&dev->pdev->dev, "read resend\n");
- } else if (resend)
- dev_dbg(&dev->pdev->dev, "write resend\n");
+ else
+ dev_dbg(&dev->pdev->dev, "write resend\n");
+ }
+
stu300_wr8(val, dev->virtbase + I2C_DR);
/* For 10bit addressing, await 10bit request (EVENT 9) */
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index c80527816ad0..1818c3b5c8d7 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -143,12 +143,6 @@ struct xiic_i2c {
#define XIIC_TX_RX_INTERRUPTS (XIIC_INTR_RX_FULL_MASK | XIIC_TX_INTERRUPTS)
-/* The following constants are used with the following macros to specify the
- * operation, a read or write operation.
- */
-#define XIIC_READ_OPERATION 1
-#define XIIC_WRITE_OPERATION 0
-
/*
* Tx Fifo upper bit masks.
*/
@@ -556,8 +550,7 @@ static void xiic_start_recv(struct xiic_i2c *i2c)
if (!(msg->flags & I2C_M_NOSTART))
/* write the address */
xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET,
- (msg->addr << 1) | XIIC_READ_OPERATION |
- XIIC_TX_DYN_START_MASK);
+ i2c_8bit_addr_from_msg(msg) | XIIC_TX_DYN_START_MASK);
xiic_irq_clr_en(i2c, XIIC_INTR_BNB_MASK);
@@ -585,7 +578,7 @@ static void xiic_start_send(struct xiic_i2c *i2c)
if (!(msg->flags & I2C_M_NOSTART)) {
/* write the address */
- u16 data = ((msg->addr << 1) & 0xfe) | XIIC_WRITE_OPERATION |
+ u16 data = i2c_8bit_addr_from_msg(msg) |
XIIC_TX_DYN_START_MASK;
if ((i2c->nmsgs == 1) && msg->len == 0)
/* no data and last message -> add STOP */
--
2.11.0
^ permalink raw reply related
* Re: administrivia: mails containing HTML attachments
From: Gabriel Paubert @ 2018-05-16 7:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20180516144829.2dbefb0b@canb.auug.org.au>
On Wed, May 16, 2018 at 02:48:29PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> I have decided that any email sent to the linuxppc-dev mailing list
> that contains an HTML attachment (or is just an HTML email) will be
> rejected. The vast majority of such mail are spam (and I have to spend
> time dropping them manually at the moment) and, I presume, anyone on
> this list is capable of sending no HTML email.
Go ahead, I couldn't agree more.
The correlation between spam and "HTeMaiL" is indeed extremely large.
Cheers,
Gabriel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: busses: make use of i2c_8bit_addr_from_msg
From: Uwe Kleine-König @ 2018-05-16 7:33 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, linux-soc,
linux-aspeed, David Brown, Andrew Jeffery, Benjamin Herrenschmidt,
Linus Walleij, Brendan Higgins, openbmc, Wolfram Sang,
Joel Stanley, Pengutronix Kernel Team, Andy Gross,
Peter Korsgaard, linuxppc-dev, Guenter Roeck, linux-i2c
In-Reply-To: <20180516071647.29277-3-peda@axentia.se>
Hello Peter,
On Wed, May 16, 2018 at 09:16:47AM +0200, Peter Rosin wrote:
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [emf32 and imx]
s/emf/efm/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v2] powerpc: kvm: Change return type to vm_fault_t
From: Souptick Joarder @ 2018-05-16 7:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: benh, mpe, Matthew Wilcox, kvm-ppc, linuxppc-dev, linux-kernel
In-Reply-To: <20180516070814.GA20588@fergus.ozlabs.ibm.com>
On Wed, May 16, 2018 at 12:38 PM, Paul Mackerras <paulus@ozlabs.org> wrote:
> On Wed, May 16, 2018 at 10:11:11AM +0530, Souptick Joarder wrote:
>> On Thu, May 10, 2018 at 11:57 PM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
>> > Use new return type vm_fault_t for fault handler
>> > in struct vm_operations_struct. For now, this is
>> > just documenting that the function returns a
>> > VM_FAULT value rather than an errno. Once all
>> > instances are converted, vm_fault_t will become
>> > a distinct type.
>> >
>> > commit 1c8f422059ae ("mm: change return type to
>> > vm_fault_t")
>> >
>> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>> > ---
>> > v2: Updated the change log
>> >
>> > arch/powerpc/kvm/book3s_64_vio.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
>> > index 4dffa61..346ac0d 100644
>> > --- a/arch/powerpc/kvm/book3s_64_vio.c
>> > +++ b/arch/powerpc/kvm/book3s_64_vio.c
>> > @@ -237,7 +237,7 @@ static void release_spapr_tce_table(struct rcu_head *head)
>> > kfree(stt);
>> > }
>> >
>> > -static int kvm_spapr_tce_fault(struct vm_fault *vmf)
>> > +static vm_fault_t kvm_spapr_tce_fault(struct vm_fault *vmf)
>> > {
>> > struct kvmppc_spapr_tce_table *stt = vmf->vma->vm_file->private_data;
>> > struct page *page;
>> > --
>> > 1.9.1
>> >
>>
>> If no comment, we would like to get this patch in queue
>> for 4.18.
>
> It looks fine - I'll queue it up.
>
> Paul.
Thanks Paul :)
^ permalink raw reply
* [PATCH v4 0/4] powerpc/64: memcmp() optimization
From: wei.guo.simon @ 2018-05-16 8:34 UTC (permalink / raw)
To: linuxppc-dev
Cc: Paul Mackerras, Michael Ellerman, Naveen N. Rao, Cyril Bur,
Simon Guo
From: Simon Guo <wei.guo.simon@gmail.com>
There is some room to optimize memcmp() in powerpc 64 bits version for
following 2 cases:
(1) Even src/dst addresses are not aligned with 8 bytes at the beginning,
memcmp() can align them and go with .Llong comparision mode without
fallback to .Lshort comparision mode do compare buffer byte by byte.
(2) VMX instructions can be used to speed up for large size comparision,
currently the threshold is set for 4K bytes. Notes the VMX instructions
will lead to VMX regs save/load penalty. This patch set includes a
patch to add a 32 bytes pre-checking to minimize the penalty.
It did the similar with glibc commit dec4a7105e (powerpc: Improve memcmp
performance for POWER8). Thanks Cyril Bur's information.
This patch set also updates memcmp selftest case to make it compiled and
incorporate large size comparison case.
v3 -> v4:
- Add 32 bytes pre-checking before using VMX instructions.
v2 -> v3:
- add optimization for src/dst with different offset against 8 bytes
boundary.
- renamed some label names.
- reworked some comments from Cyril Bur, such as fill the pipeline,
and use VMX when size == 4K.
- fix a bug of enter/exit_vmx_ops pairness issue. And revised test
case to test whether enter/exit_vmx_ops are paired.
v1 -> v2:
- update 8bytes unaligned bytes comparison method.
- fix a VMX comparision bug.
- enhanced the original memcmp() selftest.
- add powerpc/64 to subject/commit message.
Simon Guo (4):
powerpc/64: Align bytes before fall back to .Lshort in powerpc64
memcmp()
powerpc/64: enhance memcmp() with VMX instruction for long bytes
comparision
powerpc/64: add 32 bytes prechecking before using VMX optimization on
memcmp()
powerpc:selftest update memcmp_64 selftest for VMX implementation
arch/powerpc/include/asm/asm-prototypes.h | 4 +-
arch/powerpc/lib/copypage_power7.S | 4 +-
arch/powerpc/lib/memcmp_64.S | 403 ++++++++++++++++++++-
arch/powerpc/lib/memcpy_power7.S | 6 +-
arch/powerpc/lib/vmx-helper.c | 4 +-
.../selftests/powerpc/copyloops/asm/ppc_asm.h | 4 +-
.../testing/selftests/powerpc/stringloops/Makefile | 2 +-
.../selftests/powerpc/stringloops/asm/ppc_asm.h | 22 ++
.../testing/selftests/powerpc/stringloops/memcmp.c | 98 +++--
9 files changed, 506 insertions(+), 41 deletions(-)
--
1.8.3.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox