* Re: [PATCH v14 01/12] powerpc/32: Fix CONFIG_VIRT_CPU_ACCOUNTING_NATIVE for 40x/booke
From: Christophe Leroy @ 2019-01-30 8:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Nicholas Piggin, Mike Rapoport
Cc: Mark Rutland, linuxppc-dev, linux-kernel
In-Reply-To: <90ef676a0fba977259221d95dd8ffd1117f963f3.1548346225.git.christophe.leroy@c-s.fr>
Le 24/01/2019 à 17:19, Christophe Leroy a écrit :
> 40x/booke have another path to reach 3f from transfer_to_handler,
> so ACCOUNT_CPU_USER_ENTRY() have to be moved there.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Now ACCOUNT_CPU_USER_ENTRY() is also in the non-user entry path.
This change is crazy, please ignore it :-S
Christophe
> ---
> arch/powerpc/kernel/entry_32.S | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 0768dfd8a64e..0165edd03b38 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -185,12 +185,6 @@ transfer_to_handler:
> addi r12,r12,-1
> stw r12,4(r11)
> #endif
> -#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> - CURRENT_THREAD_INFO(r9, r1)
> - tophys(r9, r9)
> - ACCOUNT_CPU_USER_ENTRY(r9, r11, r12)
> -#endif
> -
> b 3f
>
> 2: /* if from kernel, check interrupted DOZE/NAP mode and
> @@ -208,9 +202,14 @@ transfer_to_handler:
> bt- 31-TLF_NAPPING,4f
> bt- 31-TLF_SLEEPING,7f
> #endif /* CONFIG_PPC_BOOK3S_32 || CONFIG_E500 */
> +3:
> +#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> + CURRENT_THREAD_INFO(r9, r1)
> + tophys(r9, r9)
> + ACCOUNT_CPU_USER_ENTRY(r9, r11, r12)
> +#endif
> .globl transfer_to_handler_cont
> transfer_to_handler_cont:
> -3:
> mflr r9
> lwz r11,0(r9) /* virtual address of handler */
> lwz r9,4(r9) /* where to go when done */
>
^ permalink raw reply
* Re: [PATCH 18/19] KVM: PPC: Book3S HV: add passthrough support
From: Cédric Le Goater @ 2019-01-30 7:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm, kvm-ppc, linuxppc-dev, David Gibson
In-Reply-To: <20190130055546.GC27109@blackberry>
On 1/30/19 6:55 AM, Paul Mackerras wrote:
> On Tue, Jan 29, 2019 at 06:44:50PM +0100, Cédric Le Goater wrote:
>> On 1/29/19 5:12 AM, Paul Mackerras wrote:
>>> On Mon, Jan 28, 2019 at 07:26:00PM +0100, Cédric Le Goater wrote:
>>>>
>>>> Is clearing the PTEs and repopulating the VMA unsafe ?
>>>
>>> Actually, now that I come to think of it, there could be any number of
>>> VMAs (well, up to almost 64k of them), since once you have a file
>>> descriptor you can call mmap on it multiple times.
>>>
>>> The more I think about it, the more I think that getting userspace to
>>> manage the mappings with mmap() and munmap() is the right idea if it
>>> can be made to work.
>>
>> We might be able to mmap() and munmap() regions of ESB pages in the RTAS
>> call "ibm,change-msi". I think that's the right spot for it.
>
> I was thinking that the ESB pages should be mmapped for device
> interrupts at VM startup or when a device is hot-plugged in, and
> munmapped when the device is hot-removed. Maybe the mmap could be
> done in conjunction with the KVM_IRQFD call?
>
> What is the reasoning behind doing it in the ibm,change-msi call?
Because when the device is plugged in, it has no interrupts. These are
allocated on demand only when the driver is loaded in the guest.
C.
^ permalink raw reply
* Re: [PATCH V5 1/5] mm: Update ptep_modify_prot_start/commit to take vm_area_struct as arg
From: Michael Ellerman @ 2019-01-30 10:33 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, akpm, x86
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20190116085035.29729-2-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Some architecture may want to call flush_tlb_range from these helpers.
That's what we want to do, but wouldn't a better description be that
some architectures may need access to the vma for some reason, one of
which might be flushing the TLB.
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/s390/include/asm/pgtable.h | 4 ++--
> arch/s390/mm/pgtable.c | 6 ++++--
> arch/x86/include/asm/paravirt.h | 11 ++++++-----
> arch/x86/include/asm/paravirt_types.h | 5 +++--
> arch/x86/xen/mmu.h | 4 ++--
> arch/x86/xen/mmu_pv.c | 8 ++++----
> fs/proc/task_mmu.c | 4 ++--
> include/asm-generic/pgtable.h | 16 ++++++++--------
> mm/memory.c | 4 ++--
> mm/mprotect.c | 4 ++--
> 10 files changed, 35 insertions(+), 31 deletions(-)
>
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 063732414dfb..5d730199e37b 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -1069,8 +1069,8 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
> }
>
> #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
> -pte_t ptep_modify_prot_start(struct mm_struct *, unsigned long, pte_t *);
> -void ptep_modify_prot_commit(struct mm_struct *, unsigned long, pte_t *, pte_t);
> +pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
> +void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, pte_t *, pte_t);
>
> #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
> static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index f2cc7da473e4..29c0a21cd34a 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -301,12 +301,13 @@ pte_t ptep_xchg_lazy(struct mm_struct *mm, unsigned long addr,
> }
> EXPORT_SYMBOL(ptep_xchg_lazy);
>
> -pte_t ptep_modify_prot_start(struct mm_struct *mm, unsigned long addr,
> +pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
> pte_t *ptep)
> {
> pgste_t pgste;
> pte_t old;
> int nodat;
> + struct mm_struct *mm = vma->vm_mm;
If this was my code I'd want the mm as the first variable, to preserve
the Reverse Christmas tree format.
> preempt_disable();
> pgste = ptep_xchg_start(mm, addr, ptep);
> @@ -320,10 +321,11 @@ pte_t ptep_modify_prot_start(struct mm_struct *mm, unsigned long addr,
> }
> EXPORT_SYMBOL(ptep_modify_prot_start);
>
> -void ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
> +void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> pte_t *ptep, pte_t pte)
> {
> pgste_t pgste;
> + struct mm_struct *mm = vma->vm_mm;
Ditto.
> if (!MACHINE_HAS_NX)
> pte_val(pte) &= ~_PAGE_NOEXEC;
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a97f28d914d5..c5a7f18cce7e 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -422,25 +422,26 @@ static inline pgdval_t pgd_val(pgd_t pgd)
> }
>
> #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
> -static inline pte_t ptep_modify_prot_start(struct mm_struct *mm, unsigned long addr,
> +static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
> pte_t *ptep)
> {
> pteval_t ret;
>
> - ret = PVOP_CALL3(pteval_t, mmu.ptep_modify_prot_start, mm, addr, ptep);
> + ret = PVOP_CALL3(pteval_t, mmu.ptep_modify_prot_start, vma, addr, ptep);
>
> return (pte_t) { .pte = ret };
> }
>
> -static inline void ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
> +static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> pte_t *ptep, pte_t pte)
> {
> +
Unnecessary blank line here.
> if (sizeof(pteval_t) > sizeof(long))
> /* 5 arg words */
> - pv_ops.mmu.ptep_modify_prot_commit(mm, addr, ptep, pte);
> + pv_ops.mmu.ptep_modify_prot_commit(vma, addr, ptep, pte);
> else
> PVOP_VCALL4(mmu.ptep_modify_prot_commit,
> - mm, addr, ptep, pte.pte);
> + vma, addr, ptep, pte.pte);
> }
>
> static inline void set_pte(pte_t *ptep, pte_t pte)
The rest looks good.
cheers
^ permalink raw reply
* Re: [PATCH V5 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg
From: Michael Ellerman @ 2019-01-30 10:46 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, akpm, x86
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20190116085035.29729-3-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Architectures like ppc64 require to do a conditional tlb flush based on the old
> and new value of pte. Enable that by passing old pte value as the arg.
It's not actually the architecture, it's to work around a specific bug
on Power9.
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index c89ce07923c8..028c724dcb1a 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -110,8 +110,8 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
> continue;
> }
>
> - ptent = ptep_modify_prot_start(vma, addr, pte);
> - ptent = pte_modify(ptent, newprot);
> + oldpte = ptep_modify_prot_start(vma, addr, pte);
> + ptent = pte_modify(oldpte, newprot);
> if (preserve_write)
> ptent = pte_mk_savedwrite(ptent);
Is it OK to reuse oldpte here?
It was set at the top of the loop with:
oldpte = *pte;
Is it guaranteed that ptep_modify_prot_start() returns the old value
unmodified, or could an implementation conceivably filter some bits out?
If so then it could be confusing for oldpte to have its value change
half way through the loop.
cheers
^ permalink raw reply
* Re: [PATCH V5 3/5] arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade.
From: Michael Ellerman @ 2019-01-30 10:52 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, akpm, x86
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20190116085035.29729-4-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> NestMMU requires us to mark the pte invalid and flush the tlb when we do a
> RW upgrade of pte. We fixed a variant of this in the fault path in commit
> Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle nest MMU hang")
You don't want the "Fixes:" there.
>
> Do the same for mprotect upgrades.
>
> Hugetlb is handled in the next patch.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 18 ++++++++++++++
> arch/powerpc/include/asm/book3s/64/radix.h | 4 ++++
> arch/powerpc/mm/pgtable-book3s64.c | 25 ++++++++++++++++++++
> arch/powerpc/mm/pgtable-radix.c | 18 ++++++++++++++
> 4 files changed, 65 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 2e6ada28da64..92eaea164700 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -1314,6 +1314,24 @@ static inline int pud_pfn(pud_t pud)
> BUILD_BUG();
> return 0;
> }
Can we get a blank line here?
> +#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
> +pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
> +void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
> + pte_t *, pte_t, pte_t);
So these are not inline ...
> +/*
> + * Returns true for a R -> RW upgrade of pte
> + */
> +static inline bool is_pte_rw_upgrade(unsigned long old_val, unsigned long new_val)
> +{
> + if (!(old_val & _PAGE_READ))
> + return false;
> +
> + if ((!(old_val & _PAGE_WRITE)) && (new_val & _PAGE_WRITE))
> + return true;
> +
> + return false;
> +}
>
> #endif /* __ASSEMBLY__ */
> #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
> diff --git a/arch/powerpc/mm/pgtable-book3s64.c b/arch/powerpc/mm/pgtable-book3s64.c
> index f3c31f5e1026..47c742f002ea 100644
> --- a/arch/powerpc/mm/pgtable-book3s64.c
> +++ b/arch/powerpc/mm/pgtable-book3s64.c
> @@ -400,3 +400,28 @@ void arch_report_meminfo(struct seq_file *m)
> atomic_long_read(&direct_pages_count[MMU_PAGE_1G]) << 20);
> }
> #endif /* CONFIG_PROC_FS */
> +
> +pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
> + pte_t *ptep)
> +{
> + unsigned long pte_val;
> +
> + /*
> + * Clear the _PAGE_PRESENT so that no hardware parallel update is
> + * possible. Also keep the pte_present true so that we don't take
> + * wrong fault.
> + */
> + pte_val = pte_update(vma->vm_mm, addr, ptep, _PAGE_PRESENT, _PAGE_INVALID, 0);
> +
> + return __pte(pte_val);
> +
> +}
> +
> +void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> + pte_t *ptep, pte_t old_pte, pte_t pte)
> +{
Which means we're going to be doing a function call to get to here ...
> + if (radix_enabled())
> + return radix__ptep_modify_prot_commit(vma, addr,
> + ptep, old_pte, pte);
And then another function call to get to the radix version ...
> + set_pte_at(vma->vm_mm, addr, ptep, pte);
> +}
> diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> index 931156069a81..dced3cd241c2 100644
> --- a/arch/powerpc/mm/pgtable-radix.c
> +++ b/arch/powerpc/mm/pgtable-radix.c
> @@ -1063,3 +1063,21 @@ void radix__ptep_set_access_flags(struct vm_area_struct *vma, pte_t *ptep,
> }
> /* See ptesync comment in radix__set_pte_at */
> }
> +
> +void radix__ptep_modify_prot_commit(struct vm_area_struct *vma,
> + unsigned long addr, pte_t *ptep,
> + pte_t old_pte, pte_t pte)
> +{
> + struct mm_struct *mm = vma->vm_mm;
> +
> + /*
> + * To avoid NMMU hang while relaxing access we need to flush the tlb before
> + * we set the new value. We need to do this only for radix, because hash
> + * translation does flush when updating the linux pte.
> + */
> + if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
> + (atomic_read(&mm->context.copros) > 0))
> + radix__flush_tlb_page(vma, addr);
To finally get here, where we'll realise that 99.99% of processes don't
use copros and so we have nothing to do except set the PTE.
> +
> + set_pte_at(mm, addr, ptep, pte);
> +}
So can we just make it all inline in the header? Or do we think it's not
a hot enough path to worry about it?
cheers
^ permalink raw reply
* Re: [PATCH V5 4/5] mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update
From: Michael Ellerman @ 2019-01-30 10:54 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, akpm, x86
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20190116085035.29729-5-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Architectures like ppc64 require to do a conditional tlb flush based on the old
> and new value of pte. Follow the regular pte change protection sequence for
> hugetlb too. This allows the architectures to override the update sequence.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> include/linux/hugetlb.h | 20 ++++++++++++++++++++
> mm/hugetlb.c | 8 +++++---
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 087fd5f48c91..39e78b80375c 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -543,6 +543,26 @@ static inline void set_huge_swap_pte_at(struct mm_struct *mm, unsigned long addr
> set_huge_pte_at(mm, addr, ptep, pte);
> }
> #endif
> +
> +#ifndef huge_ptep_modify_prot_start
> +#define huge_ptep_modify_prot_start huge_ptep_modify_prot_start
> +static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
> + unsigned long addr, pte_t *ptep)
> +{
> + return huge_ptep_get_and_clear(vma->vm_mm, addr, ptep);
> +}
> +#endif
> +
> +#ifndef huge_ptep_modify_prot_commit
> +#define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
> +static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
> + unsigned long addr, pte_t *ptep,
> + pte_t old_pte, pte_t pte)
> +{
> + set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
> +}
> +#endif
> +
> #else /* CONFIG_HUGETLB_PAGE */
> struct hstate {};
> #define alloc_huge_page(v, a, r) NULL
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index df2e7dd5ff17..f824d2200ca9 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4387,10 +4387,12 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
> continue;
> }
> if (!huge_pte_none(pte)) {
> - pte = huge_ptep_get_and_clear(mm, address, ptep);
> - pte = pte_mkhuge(huge_pte_modify(pte, newprot));
> + pte_t old_pte;
> +
> + old_pte = huge_ptep_modify_prot_start(vma, address, ptep);
> + pte = pte_mkhuge(huge_pte_modify(old_pte, newprot));
> pte = arch_make_huge_pte(pte, vma, NULL, 0);
> - set_huge_pte_at(mm, address, ptep, pte);
> + huge_ptep_modify_prot_commit(vma, address, ptep, old_pte, pte);
> pages++;
> }
> spin_unlock(ptl);
Looks like a faithful conversion.
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: [PATCH V5 5/5] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade
From: Michael Ellerman @ 2019-01-30 11:01 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, akpm, x86
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20190116085035.29729-6-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> NestMMU requires us to mark the pte invalid and flush the tlb when we do a
> RW upgrade of pte. We fixed a variant of this in the fault path in commit
> Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle nest MMU hang")
Odd "Fixes:" again.
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 ++++++++++
> arch/powerpc/mm/hugetlbpage-hash64.c | 25 ++++++++++++++++++++
> arch/powerpc/mm/hugetlbpage-radix.c | 17 +++++++++++++
> 3 files changed, 54 insertions(+)
Same comment about inlining.
But otherwise looks good.
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* [PATCH v2 0/2] add i2c controlled qixis driver
From: Pankaj Bansal @ 2019-01-30 11:34 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org, Varun Sethi,
linux-arm-kernel@lists.infradead.org
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
driver which is basically an i2c client driver to control FPGA.
This driver is essential to control MDIO mux multiplexing.
This driver is dependent on below patches:
https://www.mail-archive.com/netdev@vger.kernel.org/msg281274.html
V1 of this series:
https://patchwork.kernel.org/cover/10627297/
Cc: Varun Sethi <V.Sethi@nxp.com>
Pankaj Bansal (2):
dt-bindings: soc: fsl: Document Qixis FPGA usage
fsl: add i2c controlled qixis driver
.../bindings/soc/fsl/qixis_ctrl.txt | 33 +++++
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/qixis_ctrl.c | 121 ++++++++++++++++++
4 files changed, 163 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
create mode 100644 drivers/soc/fsl/qixis_ctrl.c
--
2.17.1
^ permalink raw reply
* [PATCH v2 2/2] fsl: add i2c controlled qixis driver
From: Pankaj Bansal @ 2019-01-30 11:34 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org, Wang Dongsheng,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190130165916.8628-1-pankaj.bansal@nxp.com>
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
driver which is basically an i2c client driver to control FPGA.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V2:
- Modify the driver to not create platform devices corresponding to subnodes.
because the subnodes are not actual devices.
- Use mdio_mux_regmap_init/mdio_mux_regmap_uninit
- Remove header file from include folder, as no qixis api is called from outside
- Add regmap_exit in driver's remove function
Dendencies:
- https://www.mail-archive.com/netdev@vger.kernel.org/msg281274.html
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/qixis_ctrl.c | 121 +++++++++++++++++++++++++++++++++
3 files changed, 130 insertions(+)
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 8a0ba6da6f8a..e787d3e637a4 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -36,6 +36,14 @@ config FSL_SLEEP_FSM
The FSM is used to finish clean-ups at the last stage of system entering deep
sleep, and also wakes up system when a wake up event happens.
+config FSL_QIXIS
+ tristate "QIXIS system controller driver"
+ depends on REGMAP_I2C
+ default n
+ help
+ Say y here to enable QIXIS system controller api. The qixis driver
+ provides FPGA functions to control system.
+
if ARM || ARM64
source "drivers/soc/fsl/Kconfig.arm"
endif
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index ffdf93b34501..db7b09bfbd91 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_QIXIS) += qixis_ctrl.o
obj-$(CONFIG_FSL_GUTS) += guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
obj-$(CONFIG_FSL_LS2_CONSOLE) += ls2-console/
diff --git a/drivers/soc/fsl/qixis_ctrl.c b/drivers/soc/fsl/qixis_ctrl.c
new file mode 100644
index 000000000000..336f366e228e
--- /dev/null
+++ b/drivers/soc/fsl/qixis_ctrl.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Freescale QIXIS system controller driver.
+ *
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2018 NXP
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mdio-mux.h>
+
+/* QIXIS MAP */
+struct fsl_qixis_regs {
+ u8 id; /* Identification Registers */
+ u8 version; /* Version Register */
+ u8 qixis_ver; /* QIXIS Version Register */
+ u8 reserved1[0x1f];
+};
+
+struct mdio_mux_data {
+ void *data;
+ struct list_head link;
+};
+
+struct qixis_priv {
+ struct regmap *regmap;
+ struct list_head mdio_mux_list;
+};
+
+static struct regmap_config qixis_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int fsl_qixis_i2c_probe(struct i2c_client *client)
+{
+ struct device_node *child;
+ struct qixis_priv *priv;
+ int ret;
+ u32 qver;
+ struct mdio_mux_data *mux_data;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EOPNOTSUPP;
+
+ priv = devm_kzalloc(&client->dev, sizeof(struct qixis_priv),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->regmap = regmap_init_i2c(client, &qixis_regmap_config);
+ INIT_LIST_HEAD(&priv->mdio_mux_list);
+
+ regmap_read(priv->regmap, offsetof(struct fsl_qixis_regs, qixis_ver),
+ &qver);
+ pr_info("Freescale QIXIS Version: 0x%08x\n", qver);
+
+ for_each_child_of_node(client->dev.of_node, child) {
+ if (of_node_name_prefix(child, "mdio-mux")) {
+ mux_data = devm_kzalloc(&client->dev,
+ sizeof(struct mdio_mux_data),
+ GFP_KERNEL);
+ if (!mux_data)
+ return -ENOMEM;
+ ret = mdio_mux_regmap_init(&client->dev, child,
+ &mux_data->data);
+ if (ret)
+ return ret;
+ list_add(&mux_data->link, &priv->mdio_mux_list);
+ }
+ };
+
+ i2c_set_clientdata(client, priv);
+
+ return 0;
+}
+
+static int fsl_qixis_i2c_remove(struct i2c_client *client)
+{
+ struct qixis_priv *priv;
+ struct list_head *pos;
+ struct mdio_mux_data *mux_data;
+
+ priv = i2c_get_clientdata(client);
+ list_for_each(pos, &priv->mdio_mux_list) {
+ mux_data = list_entry(pos, struct mdio_mux_data, link);
+ mdio_mux_regmap_uninit(mux_data->data);
+ }
+ regmap_exit(priv->regmap);
+
+ return 0;
+}
+
+static const struct of_device_id fsl_qixis_of_match[] = {
+ { .compatible = "fsl,fpga-qixis-i2c" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, fsl_qixis_of_match);
+
+static struct i2c_driver fsl_qixis_i2c_driver = {
+ .driver = {
+ .name = "qixis_ctrl",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(fsl_qixis_of_match),
+ },
+ .probe_new = fsl_qixis_i2c_probe,
+ .remove = fsl_qixis_i2c_remove,
+};
+module_i2c_driver(fsl_qixis_i2c_driver);
+
+MODULE_AUTHOR("Wang Dongsheng <dongsheng.wang@freescale.com>");
+MODULE_DESCRIPTION("Freescale QIXIS system controller driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: soc: fsl: Document Qixis FPGA usage
From: Pankaj Bansal @ 2019-01-30 11:34 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190130165916.8628-1-pankaj.bansal@nxp.com>
an FPGA-based system controller, called “Qixis”, which
manages several critical system features, including:
• Reset sequencing
• Power supply configuration
• Board configuration
• hardware configuration
The qixis registers are accessible over one or more system-specific
interfaces, typically I2C, JTAG or an embedded processor.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V2:
- No change
.../bindings/soc/fsl/qixis_ctrl.txt | 33 ++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
new file mode 100644
index 000000000000..bc2950cab71d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
@@ -0,0 +1,33 @@
+* QIXIS FPGA block
+
+an FPGA-based system controller, called “Qixis”, which
+manages several critical system features, including:
+• Configuration switch monitoring
+• Power on/off sequencing
+• Reset sequencing
+• Power supply configuration
+• Board configuration
+• hardware configuration
+• Background power data collection (DCM)
+• Fault monitoring
+• RCW bypass SRAM (replace flash RCW with internal RCW) (NOR only)
+• Dedicated functional validation blocks (POSt/IRS, triggered event, and so on)
+• I2C master for remote board control even with no DUT available
+
+The qixis registers are accessible over one or more system-specific interfaces,
+typically I2C, JTAG or an embedded processor.
+
+Required properties:
+
+ - compatible : string, must contain "fsl,fpga-qixis-i2c"
+ - reg : i2c address of the qixis device.
+
+Examples:
+ /* The FPGA node */
+ fpga@66 {
+ compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ }
+
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V7 3/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_do_alloc
From: Michael Ellerman @ 2019-01-30 11:34 UTC (permalink / raw)
To: Aneesh Kumar K.V, akpm, Michal Hocko, Alexey Kardashevskiy,
David Gibson, Andrea Arcangeli
Cc: linux-mm, linuxppc-dev, linux-kernel, Aneesh Kumar K.V
In-Reply-To: <20190114095438.32470-5-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> The current code doesn't do page migration if the page allocated is a compound page.
> With HugeTLB migration support, we can end up allocating hugetlb pages from
> CMA region. Also, THP pages can be allocated from CMA region. This patch updates
> the code to handle compound pages correctly. The patch also switches to a single
> get_user_pages with the right count, instead of doing one get_user_pages per page.
> That avoids reading page table multiple times.
It's not very obvious from the above description that the migration
logic is now being done by get_user_pages_longterm(), it just looks like
it's all being deleted in this patch. Would be good to mention that.
> Since these page reference updates are long term pin, switch to
> get_user_pages_longterm. That makes sure we fail correctly if the guest RAM
> is backed by DAX pages.
Can you explain that in more detail?
> The patch also converts the hpas member of mm_iommu_table_group_mem_t to a union.
> We use the same storage location to store pointers to struct page. We cannot
> update all the code path use struct page *, because we access hpas in real mode
> and we can't do that struct page * to pfn conversion in real mode.
That's a pain, it's asking for bugs mixing two different values in the
same array. But I guess it's the least worst option.
It sounds like that's a separate change you could do in a separate
patch. But it's not, because it's tied to the fact that we're doing a
single GUP call.
> diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
> index a712a650a8b6..f11a2f15071f 100644
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@ -21,6 +21,7 @@
> #include <linux/sizes.h>
> #include <asm/mmu_context.h>
> #include <asm/pte-walk.h>
> +#include <linux/mm_inline.h>
>
> static DEFINE_MUTEX(mem_list_mutex);
>
> @@ -34,8 +35,18 @@ struct mm_iommu_table_group_mem_t {
> atomic64_t mapped;
> unsigned int pageshift;
> u64 ua; /* userspace address */
> - u64 entries; /* number of entries in hpas[] */
> - u64 *hpas; /* vmalloc'ed */
> + u64 entries; /* number of entries in hpas/hpages[] */
> + /*
> + * in mm_iommu_get we temporarily use this to store
> + * struct page address.
> + *
> + * We need to convert ua to hpa in real mode. Make it
> + * simpler by storing physical address.
> + */
> + union {
> + struct page **hpages; /* vmalloc'ed */
> + phys_addr_t *hpas;
> + };
> #define MM_IOMMU_TABLE_INVALID_HPA ((uint64_t)-1)
> u64 dev_hpa; /* Device memory base address */
> };
> @@ -80,64 +91,15 @@ bool mm_iommu_preregistered(struct mm_struct *mm)
> }
> EXPORT_SYMBOL_GPL(mm_iommu_preregistered);
>
> -/*
> - * Taken from alloc_migrate_target with changes to remove CMA allocations
> - */
> -struct page *new_iommu_non_cma_page(struct page *page, unsigned long private)
> -{
> - gfp_t gfp_mask = GFP_USER;
> - struct page *new_page;
> -
> - if (PageCompound(page))
> - return NULL;
> -
> - if (PageHighMem(page))
> - gfp_mask |= __GFP_HIGHMEM;
> -
> - /*
> - * We don't want the allocation to force an OOM if possibe
> - */
> - new_page = alloc_page(gfp_mask | __GFP_NORETRY | __GFP_NOWARN);
> - return new_page;
> -}
> -
> -static int mm_iommu_move_page_from_cma(struct page *page)
> -{
> - int ret = 0;
> - LIST_HEAD(cma_migrate_pages);
> -
> - /* Ignore huge pages for now */
> - if (PageCompound(page))
> - return -EBUSY;
> -
> - lru_add_drain();
> - ret = isolate_lru_page(page);
> - if (ret)
> - return ret;
> -
> - list_add(&page->lru, &cma_migrate_pages);
> - put_page(page); /* Drop the gup reference */
> -
> - ret = migrate_pages(&cma_migrate_pages, new_iommu_non_cma_page,
> - NULL, 0, MIGRATE_SYNC, MR_CONTIG_RANGE);
> - if (ret) {
> - if (!list_empty(&cma_migrate_pages))
> - putback_movable_pages(&cma_migrate_pages);
> - }
> -
> - return 0;
> -}
> -
> static long mm_iommu_do_alloc(struct mm_struct *mm, unsigned long ua,
> - unsigned long entries, unsigned long dev_hpa,
> - struct mm_iommu_table_group_mem_t **pmem)
> + unsigned long entries, unsigned long dev_hpa,
> + struct mm_iommu_table_group_mem_t **pmem)
> {
> struct mm_iommu_table_group_mem_t *mem;
> - long i, j, ret = 0, locked_entries = 0;
> + long i, ret = 0, locked_entries = 0;
I'd prefer we didn't initialise ret here.
> unsigned int pageshift;
> unsigned long flags;
> unsigned long cur_ua;
> - struct page *page = NULL;
>
> mutex_lock(&mem_list_mutex);
>
> @@ -187,41 +149,27 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, unsigned long ua,
> goto unlock_exit;
> }
>
> + down_read(&mm->mmap_sem);
> + ret = get_user_pages_longterm(ua, entries, FOLL_WRITE, mem->hpages, NULL);
> + up_read(&mm->mmap_sem);
> + if (ret != entries) {
> + /* free the reference taken */
> + for (i = 0; i < ret; i++)
> + put_page(mem->hpages[i]);
> +
> + vfree(mem->hpas);
> + kfree(mem);
> + ret = -EFAULT;
> + goto unlock_exit;
> + } else {
> + ret = 0;
Or here.
Instead it should be set to 0 at good_exit.
> + }
> +
> + pageshift = PAGE_SHIFT;
> for (i = 0; i < entries; ++i) {
> + struct page *page = mem->hpages[i];
> +
> cur_ua = ua + (i << PAGE_SHIFT);
> - if (1 != get_user_pages_fast(cur_ua,
> - 1/* pages */, 1/* iswrite */, &page)) {
> - ret = -EFAULT;
> - for (j = 0; j < i; ++j)
> - put_page(pfn_to_page(mem->hpas[j] >>
> - PAGE_SHIFT));
> - vfree(mem->hpas);
> - kfree(mem);
> - goto unlock_exit;
> - }
> - /*
> - * If we get a page from the CMA zone, since we are going to
> - * be pinning these entries, we might as well move them out
> - * of the CMA zone if possible. NOTE: faulting in + migration
> - * can be expensive. Batching can be considered later
> - */
> - if (is_migrate_cma_page(page)) {
> - if (mm_iommu_move_page_from_cma(page))
> - goto populate;
> - if (1 != get_user_pages_fast(cur_ua,
> - 1/* pages */, 1/* iswrite */,
> - &page)) {
> - ret = -EFAULT;
> - for (j = 0; j < i; ++j)
> - put_page(pfn_to_page(mem->hpas[j] >>
> - PAGE_SHIFT));
> - vfree(mem->hpas);
> - kfree(mem);
> - goto unlock_exit;
> - }
> - }
> -populate:
> - pageshift = PAGE_SHIFT;
> if (mem->pageshift > PAGE_SHIFT && PageCompound(page)) {
> pte_t *pte;
> struct page *head = compound_head(page);
> @@ -239,6 +187,10 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, unsigned long ua,
> local_irq_restore(flags);
> }
> mem->pageshift = min(mem->pageshift, pageshift);
> + /*
> + * We don't need struct page reference any more, switch
> + * to physical address.
> + */
> mem->hpas[i] = page_to_pfn(page) << PAGE_SHIFT;
> }
I'm not any sort of expert on this code, but I don't see anything wrong.
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: Does SMP work at all on 40x ?
From: Michael Ellerman @ 2019-01-30 11:43 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5c170dab-4f0b-8be2-e99a-9afd0fa02394@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> In transfer_to_handler() (entry_32.S), we have:
>
> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> ...
> #ifdef CONFIG_SMP
> CURRENT_THREAD_INFO(r9, r1)
> lwz r9,TI_CPU(r9)
> slwi r9,r9,3
> add r11,r11,r9
> #endif
> #endif
>
> When running this piece of code, MMU translation is off. But r9 contains
> the virtual addr of current_thread_info, so unless I miss something,
> this cannot work on the 40x, can it ?
>
> On CONFIG_BOOKE it works because phys addr = virt addr
AFAIK 40x can't be SMP:
config SMP
depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x
But this stuff is all before my time.
The commit that added the SMP block was clearly only meant for BookE:
4eaddb4d7ec3 ("[POWERPC] Make Book-E debug handling SMP safe")
cheers
^ permalink raw reply
* Re: [PATCH 0/4] powerpc/livepatch: reliable stack unwinder fixes
From: Michael Ellerman @ 2019-01-30 12:22 UTC (permalink / raw)
To: Jiri Kosina, Joe Lawrence
Cc: Nicolai Stange, linux-kernel, Torsten Duwe, Josh Poimboeuf,
live-patching, linuxppc-dev
In-Reply-To: <nycvar.YFH.7.76.1901300049470.6626@cbobk.fhfr.pm>
Jiri Kosina <jikos@kernel.org> writes:
> On Tue, 22 Jan 2019, Joe Lawrence wrote:
>
>> This patchset fixes a false negative report (ie, unreliable) from the
>> ppc64 reliable stack unwinder, discussed here [1] when it may
>> inadvertently trip over a stale exception marker left on the stack.
>>
>> The first two patches fix this bug. Nicolai's change clears the marker
>> from the stack when an exception is finished. The next patch modifies
>> the unwinder to only look for such on stack elements when the ABI
>> guarantees that they will actually be initialized.
>>
>> The final two patches consist of code cleanups that Nicolai and I
>> spotted during the development of the fixes.
>>
>> Testing included re-running the original test scenario (loading a
>> livepatch module on ppc64le) on a 5.0.0-rc2 kernel as well as a RHEL-7
>> backport. I ran internal tests on the RHEL-7 backport and no new test
>> failures were introduced. I believe that Nicolai has done the same
>> with respect to the first patch.
>>
>> [1] https://lore.kernel.org/lkml/7f468285-b149-37e2-e782-c9e538b997a9@redhat.com/
>>
>> Joe Lawrence (3):
>> powerpc/livepatch: relax reliable stack tracer checks for first-frame
>> powerpc/livepatch: small cleanups in save_stack_trace_tsk_reliable()
>> powerpc/livepatch: return -ERRNO values in
>> save_stack_trace_tsk_reliable()
>>
>> Nicolai Stange (1):
>> powerpc/64s: Clear on-stack exception marker upon exception return
>
> Michael, are you fine with this going through LP tree, or do you plan to
> take it through yours?
I'm happy to take it, unless there's some reason you'd rather it go via
the LP tree?
I don't have any automated live patch tests, but I assume if it's in
linux-next someone can test it? :)
cheers
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return
From: Michael Ellerman @ 2019-01-30 12:27 UTC (permalink / raw)
To: Joe Lawrence, linux-kernel, linuxppc-dev, live-patching
Cc: Jiri Kosina, Torsten Duwe, Nicolai Stange, Josh Poimboeuf
In-Reply-To: <20190122155724.27557-2-joe.lawrence@redhat.com>
Joe Lawrence <joe.lawrence@redhat.com> writes:
> From: Nicolai Stange <nstange@suse.de>
>
> The ppc64 specific implementation of the reliable stacktracer,
> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
> trace" whenever it finds an exception frame on the stack. Stack frames
> are classified as exception frames if the STACK_FRAME_REGS_MARKER magic,
> as written by exception prologues, is found at a particular location.
>
> However, as observed by Joe Lawrence, it is possible in practice that
> non-exception stack frames can alias with prior exception frames and thus,
> that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on
> the stack. It in turn falsely reports an unreliable stacktrace and blocks
> any live patching transition to finish. Said condition lasts until the
> stack frame is overwritten/initialized by function call or other means.
>
> In principle, we could mitigate this by making the exception frame
> classification condition in save_stack_trace_tsk_reliable() stronger:
> in addition to testing for STACK_FRAME_REGS_MARKER, we could also take into
> account that for all exceptions executing on the kernel stack
> - their stack frames's backlink pointers always match what is saved
> in their pt_regs instance's ->gpr[1] slot and that
> - their exception frame size equals STACK_INT_FRAME_SIZE, a value
> uncommonly large for non-exception frames.
>
> However, while these are currently true, relying on them would make the
> reliable stacktrace implementation more sensitive towards future changes in
> the exception entry code. Note that false negatives, i.e. not detecting
> exception frames, would silently break the live patching consistency model.
>
> Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
> rely on STACK_FRAME_REGS_MARKER as well.
>
> Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER
> for those exceptions running on the "normal" kernel stack and returning
> to kernelspace: because the topmost frame is ignored by the reliable stack
> tracer anyway, returns to userspace don't need to take care of clearing
> the marker.
>
> Furthermore, as I don't have the ability to test this on Book 3E or
> 32 bits, limit the change to Book 3S and 64 bits.
>
> Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on
> PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended
> on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies
> PPC_BOOK3S_64, there's no functional change here.
That has nothing to do with the fix and should really be in a separate
patch.
I can split it when applying.
cheers
> Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model")
> Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
> Signed-off-by: Nicolai Stange <nstange@suse.de>
> Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/entry_64.S | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2890d36eb531..73bf87b1d274 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -220,7 +220,7 @@ config PPC
> select HAVE_PERF_USER_STACK_DUMP
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_REGS_AND_STACK_ACCESS_API
> - select HAVE_RELIABLE_STACKTRACE if PPC64 && CPU_LITTLE_ENDIAN
> + select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_VIRT_CPU_ACCOUNTING
> select HAVE_IRQ_TIME_ACCOUNTING
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 435927f549c4..a2c168b395d2 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -1002,6 +1002,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> ld r2,_NIP(r1)
> mtspr SPRN_SRR0,r2
>
> + /*
> + * Leaving a stale exception_marker on the stack can confuse
> + * the reliable stack unwinder later on. Clear it.
> + */
> + li r2,0
> + std r2,STACK_FRAME_OVERHEAD-16(r1)
> +
> ld r0,GPR0(r1)
> ld r2,GPR2(r1)
> ld r3,GPR3(r1)
> --
> 2.20.1
^ permalink raw reply
* [PATCH] scsi: cxlflash: Prevent deadlock when adapter probe fails
From: Vaibhav Jain @ 2019-01-30 12:26 UTC (permalink / raw)
To: Manoj N . Kumar, Matthew R . Ochs, Uma Krishnan
Cc: Frederic Barrat, Vaibhav Jain, linuxppc-dev, stable, linux-scsi
Presently when an error is encountered during probe of the cxlflash
adapter, a deadlock is seen with cpu thread stuck inside
cxlflash_remove(). Below is the trace of the deadlock as logged by
khungtaskd:
cxlflash 0006:00:00.0: cxlflash_probe: init_afu failed rc=-16
INFO: task kworker/80:1:890 blocked for more than 120 seconds.
Not tainted 5.0.0-rc4-capi2-kexec+ #2
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/80:1 D 0 890 2 0x00000808
Workqueue: events work_for_cpu_fn
Call Trace:
0x4d72136320 (unreliable)
__switch_to+0x2cc/0x460
__schedule+0x2bc/0xac0
schedule+0x40/0xb0
cxlflash_remove+0xec/0x640 [cxlflash]
cxlflash_probe+0x370/0x8f0 [cxlflash]
local_pci_probe+0x6c/0x140
work_for_cpu_fn+0x38/0x60
process_one_work+0x260/0x530
worker_thread+0x280/0x5d0
kthread+0x1a8/0x1b0
ret_from_kernel_thread+0x5c/0x80
INFO: task systemd-udevd:5160 blocked for more than 120 seconds.
The deadlock occurs as cxlflash_remove() is called from
cxlflash_probe() without setting 'cxlflash_cfg->state' to STATE_PROBED
and the probe thread starts to wait on
'cxlflash_cfg->reset_waitq'. Since the device was never successfully
probed the 'cxlflash_cfg->state' never changes from STATE_PROBING
hence the deadlock occurs.
We fix this deadlock by setting the variable 'cxlflash_cfg->state' to
STATE_PROBED in case an error occurs during cxlflash_probe() and just
before calling cxlflash_remove().
Cc: stable@vger.kernel.org
Fixes: c21e0bbfc485("cxlflash: Base support for IBM CXL Flash Adapter")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
drivers/scsi/cxlflash/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index bfa13e3b191c..c8bad2c093b8 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -3687,6 +3687,7 @@ static int cxlflash_probe(struct pci_dev *pdev,
host->max_cmd_len = CXLFLASH_MAX_CDB_LEN;
cfg = shost_priv(host);
+ cfg->state = STATE_PROBING;
cfg->host = host;
rc = alloc_mem(cfg);
if (rc) {
@@ -3775,6 +3776,7 @@ static int cxlflash_probe(struct pci_dev *pdev,
return rc;
out_remove:
+ cfg->state = STATE_PROBED;
cxlflash_remove(pdev);
goto out;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
From: Michael Ellerman @ 2019-01-30 12:28 UTC (permalink / raw)
To: Michael Bringmann, Nathan Fontenot, linuxppc-dev; +Cc: ldufour
In-Reply-To: <719fbfbf-795b-05c8-c181-96dd9c63b448@linux.vnet.ibm.com>
Michael Bringmann <mwb@linux.vnet.ibm.com> writes:
> On 1/29/19 3:37 AM, Michael Ellerman wrote:
>> Michael Bringmann <mwb@linux.vnet.ibm.com> writes:
>>
>>> On 10/29/18 1:43 PM, Nathan Fontenot wrote:
>>>> On pseries systems, performing a partition migration can result in
>>>> altering the nodes a CPU is assigned to on the destination system. For
>>>> exampl, pre-migration on the source system CPUs are in node 1 and 3,
>>>> post-migration on the destination system CPUs are in nodes 2 and 3.
>>>>
>>>> Handling the node change for a CPU can cause corruption in the slab
>>>> cache if we hit a timing where a CPUs node is changed while cache_reap()
>>>> is invoked. The corruption occurs because the slab cache code appears
>>>> to rely on the CPU and slab cache pages being on the same node.
>>>>
>>>> The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
>>>> does not prevent us from hitting this scenario.
>>>>
>>>> Changing the device tree property update notification handler that
>>>> recognizes an affinity change for a CPU to do a full DLPAR remove and
>>>> add of the CPU instead of dynamically changing its node resolves this
>>>> issue.
>>>>
>>>> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com
>>> Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
>
> Tested-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/traps: fix the message printed when stack overflows
From: Michael Ellerman @ 2019-01-30 12:32 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5aa3c84a675405ac99382a5893406ef7e8dfd455.1548779831.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Today's message is useless:
>
> [ 42.253267] Kernel stack overflow in process (ptrval), r1=c65500b0
>
> This patch fixes it:
>
> [ 66.905235] Kernel stack overflow in process sh[356], r1=c65560b0
>
> Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> v2: make checkpatch happy :)
>
> arch/powerpc/kernel/traps.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 5e917a84f949..a3dc6872d5aa 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1535,8 +1535,8 @@ void alignment_exception(struct pt_regs *regs)
>
> void StackOverflow(struct pt_regs *regs)
> {
> - printk(KERN_CRIT "Kernel stack overflow in process %p, r1=%lx\n",
> - current, regs->gpr[1]);
> + pr_crit("Kernel stack overflow in process %s[%d], r1=%lx\n",
> + current->comm, current->pid, regs->gpr[1]);
I think you're meant to use task_pid_nr(current) these days.
I fixed it up when applying.
cheers
^ permalink raw reply
* Re: [RESEND PATCH v3] cxl: Wrap iterations over afu slices inside 'afu_list_lock'
From: Michael Ellerman @ 2019-01-30 12:41 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Christophe Lombard, stable,
Alastair D'Silva, Andrew Donnellan, Vaibhav Jain,
Christophe Lombard
In-Reply-To: <20190129110618.13481-1-vaibhav@linux.ibm.com>
Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> Within cxl module, iteration over array 'adapter->afu' may be racy
> at few points as it might be simultaneously read during an EEH and its
> contents being set to NULL while driver is being unloaded or unbound
> from the adapter. This might result in a NULL pointer to 'struct afu'
> being de-referenced during an EEH thereby causing a kernel oops.
>
> This patch fixes this by making sure that all access to the array
> 'adapter->afu' is wrapped within the context of spin-lock
> 'adapter->afu_list_lock'.
>
> Cc: stable@vger.kernel.org
> Fixes: 9e8df8a2196("cxl: EEH support")
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
> Acked-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Changelog:
>
> Resend:
> * Fixed the reference to 'adapter->afu' in patch description. [Andrew]
> * Added the 'Fixes' tag and marked the patch to stable
FYI RESEND means you didn't change anything, but you sent the patch
again for some other reason, like the Cc list was wrong or you thought
it had been ignored.
In this case you should have just sent a v4, updating the change log is
a perfectly valid reason for a new version of the patch.
I've applied it, no need to RESEND ;)
cheers
^ permalink raw reply
* [PATCH V2] powerpc/ptrace: Mitigate potential Spectre v1
From: Breno Leitao @ 2019-01-30 12:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Breno Leitao, gustavo
'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number that would be read or written. This register number is
called 'regno' which is part of the 'addr' syscall parameter.
This 'regno' value is checked against the maximum pt_regs structure size,
and then used to dereference it, which matches the initial part of a
Spectre v1 (and Spectre v1.1) attack. The dereferenced value, then,
is returned to userspace in the GETREGS case.
This patch sanitizes 'regno' before using it to dereference pt_reg.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/ptrace.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index cdd5d1d3ae41..7535f89e08cd 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -33,6 +33,7 @@
#include <linux/hw_breakpoint.h>
#include <linux/perf_event.h>
#include <linux/context_tracking.h>
+#include <linux/nospec.h>
#include <linux/uaccess.h>
#include <linux/pkeys.h>
@@ -274,6 +275,8 @@ static int set_user_trap(struct task_struct *task, unsigned long trap)
*/
int ptrace_get_reg(struct task_struct *task, int regno, unsigned long *data)
{
+ unsigned int regs_max;
+
if ((task->thread.regs == NULL) || !data)
return -EIO;
@@ -297,7 +300,9 @@ int ptrace_get_reg(struct task_struct *task, int regno, unsigned long *data)
}
#endif
- if (regno < (sizeof(struct user_pt_regs) / sizeof(unsigned long))) {
+ regs_max = sizeof(struct user_pt_regs) / sizeof(unsigned long);
+ if (regno < regs_max) {
+ regno = array_index_nospec(regno, regs_max);
*data = ((unsigned long *)task->thread.regs)[regno];
return 0;
}
@@ -321,6 +326,7 @@ int ptrace_put_reg(struct task_struct *task, int regno, unsigned long data)
return set_user_dscr(task, data);
if (regno <= PT_MAX_PUT_REG) {
+ regno = array_index_nospec(regno, PT_MAX_PUT_REG + 1);
((unsigned long *)task->thread.regs)[regno] = data;
return 0;
}
--
2.19.0
^ permalink raw reply related
* Re: [RFC PATCH] powerpc: fix get_arch_dma_ops() for NTB devices
From: Michael Ellerman @ 2019-01-30 12:58 UTC (permalink / raw)
To: Alexander Fomichev, linuxppc-dev; +Cc: Christoph Hellwig, linux
In-Reply-To: <20190128133203.mon4a3nkrzijn43g@alfbook-pro.local>
Alexander Fomichev <fomichev.ru@gmail.com> writes:
> get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> This affects Switchtec (and probably other) NTB devices, that they fail
> to initialize.
What's an NTB device?
drivers/ntb I assume?
So it's a PCI device of some sort, but presumably the device you're
calling dma_set_mask() on is an NTB device not a PCI device?
But then it works if you tell it to use the PCI DMA ops?
At the very least the code should be checking for the NTB bus type and
only returning the PCI ops in that specific case, not for all devices.
cheers
^ permalink raw reply
* Re: [RESEND PATCH v3] cxl: Wrap iterations over afu slices inside 'afu_list_lock'
From: Vaibhav Jain @ 2019-01-30 13:25 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Christophe Lombard, stable,
Alastair D'Silva, Andrew Donnellan, Christophe Lombard
In-Reply-To: <87lg32pbas.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> FYI RESEND means you didn't change anything, but you sent the patch
> again for some other reason, like the Cc list was wrong or you thought
> it had been ignored.
>
> In this case you should have just sent a v4, updating the change log is
> a perfectly valid reason for a new version of the patch.
Thanks for pointing this out. Will take care of this in future.
>
> I've applied it, no need to RESEND ;)
Thanks.
--
Vaibhav Jain <vaibhav@linux.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH 0/4] powerpc/livepatch: reliable stack unwinder fixes
From: Jiri Kosina @ 2019-01-30 13:28 UTC (permalink / raw)
To: Michael Ellerman
Cc: Joe Lawrence, Nicolai Stange, linux-kernel, Torsten Duwe,
Josh Poimboeuf, live-patching, linuxppc-dev
In-Reply-To: <87y372pc75.fsf@concordia.ellerman.id.au>
On Wed, 30 Jan 2019, Michael Ellerman wrote:
> I'm happy to take it, unless there's some reason you'd rather it go via
> the LP tree?
As this is more about reliable stack unwinding than live patching per se
(which is only a user of that facility), I'd actually slightly prefer if
it goes via your tree.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Add _PAGE_SAO to _PAGE_CACHE_CTL mask
From: Michael Ellerman @ 2019-01-30 13:35 UTC (permalink / raw)
To: Reza Arbab, Aneesh Kumar K.V
Cc: Alexey Kardashevskiy, Charles Johns, linuxppc-dev, Paul Mackerras
In-Reply-To: <20190129170347.igcb4yufilshjgri@arbab-laptop.localdomain>
Reza Arbab <arbab@linux.ibm.com> writes:
> On Tue, Jan 29, 2019 at 08:37:28PM +0530, Aneesh Kumar K.V wrote:
>>Not sure what the fix is about. We set the related hash pte flags via
>>
>> if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_TOLERANT)
>> rflags |= HPTE_R_I;
>> else if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_NON_IDEMPOTENT)
>> rflags |= (HPTE_R_I | HPTE_R_G);
>> else if ((pteflags & _PAGE_CACHE_CTL) == _PAGE_SAO)
>> rflags |= (HPTE_R_W | HPTE_R_I | HPTE_R_M);
>
> Again, nothing broken here, just a code readability thing. As Alexey
> (and Charlie) noted, given the above it is a little confusing to define
> _PAGE_CACHE_CTL this way:
>
> #define _PAGE_CACHE_CTL (_PAGE_NON_IDEMPOTENT | _PAGE_TOLERANT)
Yeah that's confusing I agree.
It's not really a maintainability thing, because those bits are in the
architecture, so they can't change.
> I like Alexey's idea, maybe just use a literal?
>
> #define _PAGE_CACHE_CTL 0x30
I prefer your original patch. It serves as documentation on what values
we expect to see in that field.
cheers
^ permalink raw reply
* Re: [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants
From: Petr Mladek @ 2019-01-30 13:38 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, linux-sh, Catalin Marinas,
Heiko Carstens, linux-mips, Max Filippov, Guo Ren, sparclinux,
Christoph Hellwig, linux-s390, linux-c6x-dev, Yoshinori Sato,
Richard Weinberger, x86, Russell King, kasan-dev,
Geert Uytterhoeven, Mark Salter, Dennis Zhou, Matt Turner,
linux-snps-arc, uclinux-h8-devel, devicetree, linux-xtensa,
linux-alpha, linux-um, linux-m68k, Rob Herring, Greentime Hu,
xen-devel, Stafford Horne, Guan Xuetao, linux-arm-kernel,
Michal Simek, Tony Luck, linux-mm, Greg Kroah-Hartman, linux-usb,
linux-kernel, Paul Burton, Vineet Gupta, Andrew Morton,
linuxppc-dev, David S. Miller, openrisc
In-Reply-To: <1548057848-15136-22-git-send-email-rppt@linux.ibm.com>
On Mon 2019-01-21 10:04:08, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> arch/arc/kernel/unwind.c | 3 +--
> arch/sh/mm/init.c | 2 +-
> arch/x86/kernel/setup_percpu.c | 10 +++++-----
> arch/x86/mm/kasan_init_64.c | 14 ++++++++------
> drivers/firmware/memmap.c | 2 +-
> drivers/usb/early/xhci-dbc.c | 2 +-
> include/linux/memblock.h | 35 -----------------------------------
> kernel/dma/swiotlb.c | 2 +-
> kernel/printk/printk.c | 9 +--------
For printk:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
> mm/memblock.c | 35 -----------------------------------
> mm/page_alloc.c | 10 +++++-----
> mm/page_ext.c | 2 +-
> mm/percpu.c | 11 ++++-------
> mm/sparse.c | 6 ++----
> 14 files changed, 31 insertions(+), 112 deletions(-)
>
^ permalink raw reply
* Re: [RESEND PATCH v3] cxl: Wrap iterations over afu slices inside 'afu_list_lock'
From: Sasha Levin @ 2019-01-30 14:46 UTC (permalink / raw)
To: Sasha Levin, Vaibhav Jain, linuxppc-dev; +Cc: Vaibhav Jain, stable
In-Reply-To: <20190129110618.13481-1-vaibhav@linux.ibm.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: .
The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153, v4.4.172, v3.18.133.
v4.20.5: Build OK!
v4.19.18: Build OK!
v4.14.96: Build OK!
v4.9.153: Failed to apply! Possible dependencies:
bb81733de28c ("cxl: Fix error handling in _cxl_pci_associate_default_context()")
v4.4.172: Failed to apply! Possible dependencies:
14baf4d9c739 ("cxl: Add guest-specific code")
2b04cf310ba8 ("cxl: Rename some bare-metal specific functions")
5be587b11101 ("cxl: Introduce implementation-specific API")
73d55c3b59f7 ("cxl: IRQ allocation for guests")
8633186209e3 ("cxl: Move common code away from bare-metal-specific files")
cbffa3a5146a ("cxl: Separate bare-metal fields in adapter and AFU data structures")
d56d301b5174 ("cxl: Move bare-metal specific code to specialized files")
ea2d1f95efd7 ("cxl: Isolate a few bare-metal-specific calls")
v3.18.133: Failed to apply! Possible dependencies:
0520336afe5d ("cxl: Export file ops for use by API")
0b3f9c757cab ("cxl: Drop commands if the PCI channel is not in normal state")
14baf4d9c739 ("cxl: Add guest-specific code")
27d4dc7116ee ("cxl: Implement an ioctl to fetch afu card-id, offset-id and mode")
3d6b040e7338 ("cxl: sparse: Make declarations static")
406e12ec0b64 ("cxl: Cleanup Makefile")
456295e284be ("cxl: Fix leaking interrupts if attach process fails")
588b34be20bc ("cxl: Convert MMIO read/write macros to inline functions")
5be587b11101 ("cxl: Introduce implementation-specific API")
62fa19d4b4fd ("cxl: Add ability to reset the card")
6428832a7bfa ("cxl: Add cookie parameter to afu_release_irqs()")
6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
73d55c3b59f7 ("cxl: IRQ allocation for guests")
7bb5d91a4dda ("cxl: Rework context lifetimes")
80c394fab896 ("cxl: Add explicit precision specifiers")
80fa93fce37d ("cxl: Name interrupts in /proc/interrupt")
8dde152ea348 ("cxl: fix leak of IRQ names in cxl_free_afu_irqs()")
95bc11bcd142 ("cxl: Add image control to sysfs")
9bcf28cdb28e ("cxl: Add tracepoints")
b087e6190ddc ("cxl: Export optional AFU configuration record in sysfs")
b12994fbfe93 ("cxl: cxl_afu_reset() -> __cxl_afu_reset()")
bc78b05bb412 ("cxl: Return error to PSL if IRQ demultiplexing fails & print clearer warning")
c358d84b4e57 ("cxl: Split afu_register_irqs() function")
cbffa3a5146a ("cxl: Separate bare-metal fields in adapter and AFU data structures")
de369538436a ("cxl: use more common format specifier")
e36f6fe1f7aa ("cxl: Export AFU error buffer via sysfs")
ea2d1f95efd7 ("cxl: Isolate a few bare-metal-specific calls")
eda3693c842e ("cxl: Rework detach context functions")
How should we proceed with this patch?
--
Thanks,
Sasha
^ 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