* [PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
From: xiakaixu1987 @ 2020-11-10 11:19 UTC (permalink / raw)
To: fbarrat, ajd, mpe, benh, paulus; +Cc: Kaixu Xia, linuxppc-dev, linux-kernel
From: Kaixu Xia <kaixuxia@tencent.com>
Fix coccicheck warning:
./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned expression compared with zero: win < 0
./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned expression compared with zero: win < 0
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
---
arch/powerpc/platforms/powernv/pci-sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
index c4434f20f42f..92fc861c528f 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -422,7 +422,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev, u16 num_vfs)
{
struct pnv_iov_data *iov;
struct pnv_phb *phb;
- unsigned int win;
+ int win;
struct resource *res;
int i, j;
int64_t rc;
--
2.20.0
^ permalink raw reply related
* Re: [PATCH 03/18] powerpc: bad_page_fault, do_break get registers from regs
From: Christophe Leroy @ 2020-11-10 11:19 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1604996998.52nfki5192.astroid@bobo.none>
Le 10/11/2020 à 09:34, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of November 6, 2020 6:14 pm:
>>
>>
>> Le 05/11/2020 à 15:34, Nicholas Piggin a écrit :
>>> This also moves the 32s DABR match to C.
>>
>> Is there a real benefit doing this ?
>
> Oh I missed doing it, but yes I think bad_page_fault and do_break should
> probably be implemented with the DEFINE_INTERRUT_HANDLER wrappers.
>
Yes, anyway, do we need to do that change ? Can't the dispatch between do_break() and page fault
handling remain in handle_page_fault() ? What's the benefit of going into do_page_fault() and coming
back ?
Christophe
^ permalink raw reply
* Re: [PATCH 02/18] powerpc: remove arguments from fault handler functions
From: Christophe Leroy @ 2020-11-10 11:15 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1604996406.ltcjkqarcr.astroid@bobo.none>
Le 10/11/2020 à 09:29, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of November 6, 2020 5:59 pm:
>>
>>
>> Le 05/11/2020 à 15:34, Nicholas Piggin a écrit :
>>> Make mm fault handlers all just take the pt_regs * argument and load
>>> DAR/DSISR from that. Make those that return a value return long.
>>>
>>> This is done to make the function signatures match other handlers, which
>>> will help with a future patch to add wrappers. Explicit arguments could
>>> be added for performance but that would require more wrapper macro
>>> variants.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
[...]
>
>>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>>> index e65a49f246ef..390a296b16a3 100644
>>> --- a/arch/powerpc/mm/fault.c
>>> +++ b/arch/powerpc/mm/fault.c
>>> @@ -549,11 +549,12 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,
>>> }
>>> NOKPROBE_SYMBOL(__do_page_fault);
>>>
>>> -int do_page_fault(struct pt_regs *regs, unsigned long address,
>>> - unsigned long error_code)
>>> +long do_page_fault(struct pt_regs *regs)
>>> {
>>> enum ctx_state prev_state = exception_enter();
>>> - int err;
>>> + unsigned long address = regs->dar;
>>> + unsigned long error_code = regs->dsisr;
>>> + long err;
>>
>> By doing something more or less like this (need to be tuned for bookE as well):
>>
>> + int is_exec = TRAP(regs) == 0x400;
>> + unsigned long address = is_exec ? regs->ssr0 : regs->dar;
>> + unsigned long error_code = is_exec ? (regs->ssr1 & DSISR_SRR1_MATCH_32S) : regs->dsisr;
>
> Ah, I didn't see that you saved these in srr0/1 already. Hmm, not in
> pt_regs though. thread_struct (VMAP_STACK only)? exception_regs (booke
> only)? Doesn't seem so easy.
Oops yes you are right, SRR0/SRR1 are not in pt_regs. And their validity in thread struct is rather
short ... So forget my comment.
Christophe
^ permalink raw reply
* Re: [PATCH V3] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Christophe Leroy @ 2020-11-10 10:57 UTC (permalink / raw)
To: Wang Qing, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Nicholas Piggin, Jordan Niethe, Alistair Popple,
Aneesh Kumar K.V, Peter Zijlstra, Greg Kroah-Hartman,
linuxppc-dev, linux-kernel
In-Reply-To: <1604998411-16116-1-git-send-email-wangqing@vivo.com>
Le 10/11/2020 à 09:53, Wang Qing a écrit :
> PREEMPT_RT is a separate preemption model, CONFIG_PREEMPT will
> be disabled when CONFIG_PREEMPT_RT is enabled, so we need
> to add CONFIG_PREEMPT_RT output to __die().
>
> Signed-off-by: Wang Qing <wangqing@vivo.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> Changes in v3:
> - Fix typo issue.
>
> Changes in v2:
> - Modify as Christophe suggested.
> ---
> arch/powerpc/kernel/traps.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 5006dcb..dec7b81
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs, long err)
> {
> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>
> - printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
> + printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> PAGE_SIZE / 1024, get_mmu_str(),
> IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
> + IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
>
^ permalink raw reply
* Re: [PATCH v7 4/4] arch, mm: make kernel_page_present() always available
From: David Hildenbrand @ 2020-11-10 10:02 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
Pavel Machek, H. Peter Anvin, sparclinux, Christoph Lameter,
Will Deacon, linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, linux-arm-kernel,
Catalin Marinas, Len Brown, Albert Ou, Vasily Gorbik, linux-pm,
Heiko Carstens, David Rientjes, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Kirill A. Shutemov, Thomas Gleixner,
Vlastimil Babka, Rafael J. Wysocki, linux-kernel, Pekka Enberg,
Palmer Dabbelt, Joonsoo Kim, Edgecombe, Rick P, linuxppc-dev,
David S. Miller, Kirill A . Shutemov
In-Reply-To: <20201109192128.960-5-rppt@kernel.org>
On 09.11.20 20:21, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
> verify that a page is mapped in the kernel direct map can be useful
> regardless of hibernation.
>
> Add RISC-V implementation of kernel_page_present(), update its forward
> declarations and stubs to be a part of set_memory API and remove ugly
> ifdefery in inlcude/linux/mm.h around current declarations of
> kernel_page_present().
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH V3] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Wang Qing @ 2020-11-10 8:53 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Christophe Leroy, Nicholas Piggin, Jordan Niethe, Alistair Popple,
Wang Qing, Aneesh Kumar K.V, Peter Zijlstra, Greg Kroah-Hartman,
linuxppc-dev, linux-kernel
PREEMPT_RT is a separate preemption model, CONFIG_PREEMPT will
be disabled when CONFIG_PREEMPT_RT is enabled, so we need
to add CONFIG_PREEMPT_RT output to __die().
Signed-off-by: Wang Qing <wangqing@vivo.com>
Changes in v3:
- Fix typo issue.
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs, long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 0/9] powerpc/64s: fast interrupt exit
From: Nicholas Piggin @ 2020-11-10 8:49 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <fdde16b8-2bb4-f6a2-3c29-61d0169453cf@csgroup.eu>
Excerpts from Christophe Leroy's message of November 7, 2020 8:35 pm:
>
>
> Le 06/11/2020 à 16:59, Nicholas Piggin a écrit :
>> This series attempts to improve the speed of interrupts and system calls
>> in two major ways.
>>
>> Firstly, the SRR/HSRR registers do not need to be reloaded if they were
>> not used or clobbered fur the duration of the interrupt.
>>
>> Secondly, an alternate return location facility is added for soft-masked
>> asynchronous interrupts and then that's used to set everything up for
>> return without having to disable MSR RI or EE.
>>
>> After this series, the entire system call / interrupt handler fast path
>> executes no mtsprs and one mtmsrd to enable interrupts initially, and
>> the system call vectored path doesn't even need to do that.
>
> Interesting series.
>
> Unfortunately, can't be done on PPC32 (at least on non bookE), because it would mean mapping kernel
> at 0 instead of 0xC0000000. Not sure libc would like it, and anyway it would be an issue for
> catching NULL pointer dereferencing, unless we use page tables instead of BATs to map kernel mem,
> which would be serious performance cut.
Hmm, why would you have to map at 0?
PPC32 doesn't have soft mask interrupts, but you could still test all
MSR[PR]=0 interrupts to see if they land inside some region to see if
they hit in the restart table I think?
Could PPC32 skip the SRR reload at least? That's simpler.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
From: Thomas Gleixner @ 2020-11-10 8:48 UTC (permalink / raw)
To: Ira Weiny
Cc: linux-aio, linux-efi, kvm, linux-doc, Peter Zijlstra, linux-mmc,
Dave Hansen, dri-devel, linux-mm, target-devel, linux-mtd,
linux-kselftest, samba-technical, ceph-devel, drbd-dev, devel,
linux-cifs, linux-nilfs, linux-scsi, linux-nvdimm, linux-rdma,
x86, amd-gfx, io-uring, cluster-devel, Ingo Molnar,
intel-wired-lan, xen-devel, linux-ext4, Fenghua Yu, linux-afs,
linux-um, intel-gfx, ecryptfs, linux-erofs, reiserfs-devel,
linux-block, linux-bcache, Borislav Petkov, Andy Lutomirski,
Dan Williams, Andrew Morton, linux-cachefs, linux-nfs,
linux-ntfs-dev, netdev, Randy Dunlap, kexec, linux-kernel,
linux-f2fs-devel, linux-fsdevel, bpf, linuxppc-dev, linux-btrfs
In-Reply-To: <20201110045954.GL3976735@iweiny-DESK2.sc.intel.com>
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the patches in your latest version. Have you
> included converting any of the kmap() call sites? I thought you were more
> focused on converting the kmap_atomic() to kmap_local()?
I did not touch any of those yet, but it's a logical consequence to
convert all kmap() instances which are _not_ creating a global mapping
over to it.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI
From: Nicholas Piggin @ 2020-11-10 8:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7719261b0a0d2787772339484c33eb809723bca7.1604854583.git.christophe.leroy@csgroup.eu>
Excerpts from Christophe Leroy's message of November 9, 2020 2:57 am:
> In head_64.S, we have two places using RFI to return to
> kernel. Use RFI_TO_KERNEL instead.
>
> They are the two only places using RFI on book3s/64, so
> the RFI macro can go away.
Looks good to me.
Acked-by: Nicholas Piggin <npiggin@gmail.com>
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/include/asm/ppc_asm.h | 1 -
> arch/powerpc/kernel/head_64.S | 9 +++++++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
> index 511786f0e40d..bedf3eb52ebc 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -495,7 +495,6 @@ END_FTR_SECTION_NESTED(CPU_FTR_CELL_TB_BUG, CPU_FTR_CELL_TB_BUG, 96)
> #endif
>
> #ifdef CONFIG_PPC_BOOK3S_64
> -#define RFI rfid
> #define MTMSRD(r) mtmsrd r
> #define MTMSR_EERI(reg) mtmsrd reg,1
> #else
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 1510b2a56669..ecf9a88988ff 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -41,6 +41,11 @@
> #include <asm/ppc-opcode.h>
> #include <asm/export.h>
> #include <asm/feature-fixups.h>
> +#ifdef CONFIG_PPC_BOOK3S
> +#include <asm/exception-64s.h>
> +#else
> +#include <asm/exception-64e.h>
> +#endif
>
> /* The physical memory is laid out such that the secondary processor
> * spin code sits at 0x0000...0x00ff. On server, the vectors follow
> @@ -829,7 +834,7 @@ __secondary_start:
>
> mtspr SPRN_SRR0,r3
> mtspr SPRN_SRR1,r4
> - RFI
> + RFI_TO_KERNEL
> b . /* prevent speculative execution */
>
> /*
> @@ -966,7 +971,7 @@ start_here_multiplatform:
> ld r4,PACAKMSR(r13)
> mtspr SPRN_SRR0,r3
> mtspr SPRN_SRR1,r4
> - RFI
> + RFI_TO_KERNEL
> b . /* prevent speculative execution */
>
> /* This is where all platforms converge execution */
> --
> 2.25.0
>
>
^ permalink raw reply
* Re: [PATCH 18/18] powerpc/64s: move power4 idle entirely to C
From: Nicholas Piggin @ 2020-11-10 8:43 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <7de6fd21-da79-fe8f-5db4-f99ee0dd7d23@csgroup.eu>
Excerpts from Christophe Leroy's message of November 7, 2020 7:43 pm:
>
>
> Le 05/11/2020 à 15:34, Nicholas Piggin a écrit :
>> Christophe asked about doing this, most of the code is still in
>> asm but maybe it's slightly nicer? I don't know if it's worthwhile.
>
> Heu... I don't think I was asking for that, but why not, see later comments.
>
> At first I was just asking to write the following in C:
>
> +
> + .globl power4_idle_nap_return
> +power4_idle_nap_return:
> + blr
>
>
> In extenso, instead of the above do somewhere something like:
>
> void power4_idle_nap_return(void)
> {
> }
Ah! Well either was a good question. I don't mind attempting it :)
>> ---
>> arch/powerpc/kernel/idle.c | 25 ++++++++++++++++++++-----
>> arch/powerpc/kernel/idle_book3s.S | 22 ----------------------
>> 2 files changed, 20 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
>> index ae0e2632393d..849e77a45915 100644
>> --- a/arch/powerpc/kernel/idle.c
>> +++ b/arch/powerpc/kernel/idle.c
>> @@ -72,6 +72,9 @@ int powersave_nap;
>> #ifdef CONFIG_PPC_970_NAP
>> void power4_idle(void)
>> {
>> + unsigned long msr_idle = MSR_KERNEL|MSR_EE|MSR_POW;
>> + unsigned long tmp1, tmp2;
>> +
>> if (!cpu_has_feature(CPU_FTR_CAN_NAP))
>> return;
>>
>> @@ -84,13 +87,25 @@ void power4_idle(void)
>> if (cpu_has_feature(CPU_FTR_ALTIVEC))
>> asm volatile("DSSALL ; sync" ::: "memory");
>>
>> - power4_idle_nap();
>> -
>> + asm volatile(
>> +" ld %0,PACA_THREAD_INFO(r13) \n"
>> +" ld %1,TI_LOCAL_FLAGS(%0) \n"
>> +" ori %1,%1,_TLF_NAPPING \n"
>> +" std %1,TI_LOCAL_FLAGS(%0) \n"
>
> Can't this just be:
>
> current_thread_info()->local_flags |= _TLF_NAPPING;
>
>> /*
>> - * power4_idle_nap returns with interrupts enabled (soft and hard).
>> - * to our caller with interrupts enabled (soft and hard). Our caller
>> - * can cope with either interrupts disabled or enabled upon return.
>> + * NAPPING bit is set, from this point onward nap_adjust_return()
>> + * will cause interrupts to return to power4_idle_nap_return.
>> */
>> +"1: sync \n"
>> +" isync \n"
>> +" mtmsrd %2 \n"
>> +" isync \n"
>> +" b 1b \n"
>
> And this:
>
> for (;;) {
> mb();
> isync();
> mtmsr(MSR_KERNEL|MSR_EE|MSR_POW);
> isync();
> }
I was hoping something nicer like this but I think not because as soon
as we set _TLF_NAPPING, we might take an interrupt which returns
somewhere else, and you aren't allowed to do that in C code (mainly
because the stack and register state would be unknown). Even going
immediately to blr or end of function might miss restoring NVGPRs etc.
There might be some tricks we could play with soft-masking interrupts,
using MSR[EE]=0, and then doing all this and returning to right after
the mtmsr POW with a flag set... But it's a bit of tricky churn for an
old CPU that works okay.
Thanks,
Nick
>
>
>> +" .globl power4_idle_nap_return \n"
>> +"power4_idle_nap_return: \n"
>> + : "=r"(tmp1), "=r"(tmp2)
>> + : "r"(msr_idle)
>> + );
>> }
>> #endif
>>
>
> Christophe
>
^ permalink raw reply
* Re: [PATCH 03/18] powerpc: bad_page_fault, do_break get registers from regs
From: Nicholas Piggin @ 2020-11-10 8:34 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <8b325832-b843-7d01-8b0f-fc278c444ce5@csgroup.eu>
Excerpts from Christophe Leroy's message of November 6, 2020 6:14 pm:
>
>
> Le 05/11/2020 à 15:34, Nicholas Piggin a écrit :
>> This also moves the 32s DABR match to C.
>
> Is there a real benefit doing this ?
Oh I missed doing it, but yes I think bad_page_fault and do_break should
probably be implemented with the DEFINE_INTERRUT_HANDLER wrappers.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 02/18] powerpc: remove arguments from fault handler functions
From: Nicholas Piggin @ 2020-11-10 8:29 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <6af9a488-3816-9744-db4b-5a3bceb1f0f0@csgroup.eu>
Excerpts from Christophe Leroy's message of November 6, 2020 5:59 pm:
>
>
> Le 05/11/2020 à 15:34, Nicholas Piggin a écrit :
>> Make mm fault handlers all just take the pt_regs * argument and load
>> DAR/DSISR from that. Make those that return a value return long.
>>
>> This is done to make the function signatures match other handlers, which
>> will help with a future patch to add wrappers. Explicit arguments could
>> be added for performance but that would require more wrapper macro
>> variants.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/asm-prototypes.h | 4 ++--
>> arch/powerpc/include/asm/bug.h | 4 ++--
>> arch/powerpc/kernel/exceptions-64e.S | 2 --
>> arch/powerpc/kernel/exceptions-64s.S | 14 ++------------
>> arch/powerpc/kernel/head_40x.S | 10 +++++-----
>> arch/powerpc/kernel/head_8xx.S | 6 +++---
>> arch/powerpc/kernel/head_book3s_32.S | 6 ++----
>> arch/powerpc/kernel/head_booke.h | 4 +---
>> arch/powerpc/mm/book3s64/hash_utils.c | 8 +++++---
>> arch/powerpc/mm/book3s64/slb.c | 11 +++++++----
>> arch/powerpc/mm/fault.c | 16 +++++++++-------
>> 11 files changed, 38 insertions(+), 47 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
>> index d0b832cbbec8..22c9d08fa3a4 100644
>> --- a/arch/powerpc/include/asm/asm-prototypes.h
>> +++ b/arch/powerpc/include/asm/asm-prototypes.h
>> @@ -82,8 +82,8 @@ void kernel_bad_stack(struct pt_regs *regs);
>> void system_reset_exception(struct pt_regs *regs);
>> void machine_check_exception(struct pt_regs *regs);
>> void emulation_assist_interrupt(struct pt_regs *regs);
>> -long do_slb_fault(struct pt_regs *regs, unsigned long ea);
>> -void do_bad_slb_fault(struct pt_regs *regs, unsigned long ea, long err);
>> +long do_slb_fault(struct pt_regs *regs);
>> +void do_bad_slb_fault(struct pt_regs *regs);
>>
>> /* signals, syscalls and interrupts */
>> long sys_swapcontext(struct ucontext __user *old_ctx,
>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>> index d714d83bbc7c..2fa0cf6c6011 100644
>> --- a/arch/powerpc/include/asm/bug.h
>> +++ b/arch/powerpc/include/asm/bug.h
>> @@ -111,8 +111,8 @@
>> #ifndef __ASSEMBLY__
>>
>> struct pt_regs;
>> -extern int do_page_fault(struct pt_regs *, unsigned long, unsigned long);
>> -extern int hash__do_page_fault(struct pt_regs *, unsigned long, unsigned long);
>> +extern long do_page_fault(struct pt_regs *);
>> +extern long hash__do_page_fault(struct pt_regs *);
>
> extern is pointless
Thanks. Sorry I'll get it right one day.
>> @@ -191,9 +191,9 @@ _ENTRY(saved_ksp_limit)
>> */
>> START_EXCEPTION(0x0400, InstructionAccess)
>> EXCEPTION_PROLOG
>> - mr r4,r12 /* Pass SRR0 as arg2 */
>> - stw r4, _DEAR(r11)
>> - li r5,0 /* Pass zero as arg3 */
>> + li r5,0
>> + stw r5, _ESR(r11) /* Zero ESR */
>> + stw r12, _DEAR(r11) /* SRR0 as DEAR */
>
> I think we should avoid this, see below
>
>> @@ -356,14 +356,14 @@ DataStoreTLBMiss:
>> . = 0x1300
>> InstructionTLBError:
>> EXCEPTION_PROLOG
>> - mr r4,r12
>> andis. r5,r9,DSISR_SRR1_MATCH_32S@h /* Filter relevant SRR1 bits */
>
> Could avoid this, see below
>
>> andis. r10,r9,SRR1_ISI_NOPT@h
>> beq+ .Litlbie
>> - tlbie r4
>> + tlbie r12
>> /* 0x400 is InstructionAccess exception, needed by bad_page_fault() */
>> .Litlbie:
>> - stw r4, _DAR(r11)
>> + stw r12, _DAR(r11)
>> + stw r5, _DSISR(r11)
>
> And this
>> @@ -369,9 +369,9 @@ BEGIN_MMU_FTR_SECTION
>> bl hash_page
>> END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
>> #endif /* CONFIG_VMAP_STACK */
>> -1: mr r4,r12
>> andis. r5,r9,DSISR_SRR1_MATCH_32S@h /* Filter relevant SRR1 bits */
>> - stw r4, _DAR(r11)
>> + stw r5, _DSISR(r11)
>> + stw r12, _DAR(r11)
>
> And this including the andis.
>
>> @@ -477,9 +477,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_EMB_HV)
>> NORMAL_EXCEPTION_PROLOG(INST_STORAGE); \
>> mfspr r5,SPRN_ESR; /* Grab the ESR and save it */ \
>> stw r5,_ESR(r11); \
>> - mr r4,r12; /* Pass SRR0 as arg2 */ \
>> - stw r4, _DEAR(r11); \
>> - li r5,0; /* Pass zero as arg3 */ \
>> + stw r12, _DEAR(r11); /* Pass SRR0 as arg2 */ \
>
> And this
>
[...]
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index e65a49f246ef..390a296b16a3 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -549,11 +549,12 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,
>> }
>> NOKPROBE_SYMBOL(__do_page_fault);
>>
>> -int do_page_fault(struct pt_regs *regs, unsigned long address,
>> - unsigned long error_code)
>> +long do_page_fault(struct pt_regs *regs)
>> {
>> enum ctx_state prev_state = exception_enter();
>> - int err;
>> + unsigned long address = regs->dar;
>> + unsigned long error_code = regs->dsisr;
>> + long err;
>
> By doing something more or less like this (need to be tuned for bookE as well):
>
> + int is_exec = TRAP(regs) == 0x400;
> + unsigned long address = is_exec ? regs->ssr0 : regs->dar;
> + unsigned long error_code = is_exec ? (regs->ssr1 & DSISR_SRR1_MATCH_32S) : regs->dsisr;
Ah, I didn't see that you saved these in srr0/1 already. Hmm, not in
pt_regs though. thread_struct (VMAP_STACK only)? exception_regs (booke
only)? Doesn't seem so easy.
In general I don't have a problem with some processor specific things
like this in do page_fault though if it speeds things up. If it gets
a bit more complicated then we can have some accsssor function
get_fault_details(regs, &address, &error_code, &is_exec);
>> @@ -580,11 +581,12 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
>> NOKPROBE_SYMBOL(do_page_fault);
>>
>> #ifdef CONFIG_PPC_BOOK3S_64
>> -/* Same as do_page_fault but interrupt entry has already run in do_hash_fault */
>> -int hash__do_page_fault(struct pt_regs *regs, unsigned long address,
>> - unsigned long error_code)
>> +/* Same as do_page_fault but no interrupt entry */
>> +long hash__do_page_fault(struct pt_regs *regs)
>> {
>> - int err;
>> + unsigned long address = regs->dar;
>> + unsigned long error_code = regs->dsisr;
>> + long err;
>>
>> err = __do_page_fault(regs, address, error_code);
>> if (unlikely(err)) {
>>
>
> There is probably also something we can simplify around get_and_save_dar_dsisr_on_stack() macro in
> head_32.h, no need to reload DAR, at least for 8xx. Maybe as a followup patch later.
Admittedly my 32-bit knowledge or test environments are not great :(
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc: add compile-time support for lbarx, lwarx
From: Nicholas Piggin @ 2020-11-10 8:18 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <311a1f6d-01ca-e35f-d145-3c643fb40f74@csgroup.eu>
Excerpts from Christophe Leroy's message of November 7, 2020 6:15 pm:
>
>
> Le 07/11/2020 à 04:23, Nicholas Piggin a écrit :
>> ISA v2.06 (POWER7 and up) as well as e6500 support lbarx and lwarx.
>> Add a compile option that allows code to use it, and add support in
>> cmpxchg and xchg 8 and 16 bit values.
>
> Do you mean lharx ? Because lwarx exists on all powerpcs I think.
Thanks all who pointed out mistakes :) Yes lharx.
>
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/Kconfig | 3 +
>> arch/powerpc/include/asm/cmpxchg.h | 236 ++++++++++++++++++++++++-
>> arch/powerpc/platforms/Kconfig.cputype | 5 +
>> 3 files changed, 243 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index e9f13fe08492..d231af06f75a 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -266,6 +266,9 @@ config PPC_BARRIER_NOSPEC
>> default y
>> depends on PPC_BOOK3S_64 || PPC_FSL_BOOK3E
>>
>> +config PPC_LBARX_LWARX
>> + bool
>
> s/LWARX/LHARX/ ?
>
> And maybe better with PPC_HAS_LBARX_LWARX ?
Yes you're right, PPC_HAS_ fits better.
[...]
>> +#endif
>
> That's a lot of code duplication. Could we use some macro, in the same spirit as what is done in
> arch/powerpc/include/asm/io.h for in_be16(), in_be32(), in_be64() and friends ?
For now I don't get too fancy. It's a bit ugly but I'm working through a
generic atomics conversion patch and trying to also work out a nice form
for larx/stcx operation generation macros, I'll look at tidying up this
some time after then.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Greg Kroah-Hartman @ 2020-11-10 8:10 UTC (permalink / raw)
To: Wang Qing
Cc: Aneesh Kumar K.V, Alistair Popple, Peter Zijlstra,
Michael Neuling, linux-kernel, Paul Mackerras, Nicholas Piggin,
Jordan Niethe, tglx, linuxppc-dev
In-Reply-To: <1604995368-29649-1-git-send-email-wangqing@vivo.com>
On Tue, Nov 10, 2020 at 04:02:47PM +0800, Wang Qing wrote:
> PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will
Minor typo on this line with your config option :(
^ permalink raw reply
* [PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Wang Qing @ 2020-11-10 8:02 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Nicholas Piggin, Christophe Leroy, Jordan Niethe, Alistair Popple,
Michael Neuling, Aneesh Kumar K.V, Peter Zijlstra,
Greg Kroah-Hartman, linuxppc-dev, linux-kernel
Cc: Wang Qing, tglx
PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will
be disabled when CONFIG_PREEMPT_RT is enabled, so you need
to add CONFIG_PREEMPT_RT judgments to __die().
Signed-off-by: Wang Qing <wangqing@vivo.com>
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs, long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Christophe Leroy @ 2020-11-10 8:06 UTC (permalink / raw)
To: Wang Qing, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Nicholas Piggin, Jordan Niethe, Alistair Popple,
Michael Neuling, Aneesh Kumar K.V, Peter Zijlstra,
Greg Kroah-Hartman, linuxppc-dev, linux-kernel
Cc: tglx
In-Reply-To: <1604995368-29649-1-git-send-email-wangqing@vivo.com>
Le 10/11/2020 à 09:02, Wang Qing a écrit :
> PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will
s/CONFIG_PRTTMPT/CONFIG_PREEMPT
> be disabled when CONFIG_PREEMPT_RT is enabled, so you need
> to add CONFIG_PREEMPT_RT judgments to __die().
>
> Signed-off-by: Wang Qing <wangqing@vivo.com>
Otherwise
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> Changes in v2:
> - Modify as Christophe suggested.
> ---
> arch/powerpc/kernel/traps.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 5006dcb..dec7b81
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs, long err)
> {
> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>
> - printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
> + printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> PAGE_SIZE / 1024, get_mmu_str(),
> IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
> + IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
>
^ permalink raw reply
* Duplicated ABI entries - Was: Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output
From: Mauro Carvalho Chehab @ 2020-11-10 7:26 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Gautham R. Shenoy, Jason A. Donenfeld, Heikki Krogerus,
Peter Meerwald-Stadler, Petr Mladek, Linux Doc Mailing List,
Alexander Shishkin, Nayna Jain, Jonathan Cameron,
Alexandre Belloni, Mimi Zohar, Sebastian Reichel, linux-mm,
Bruno Meneguele, Vishal Verma, Pavel Machek, Hanjun Guo,
Guenter Roeck, netdev, Oleh Kravchenko, Dan Williams,
Andrew Donnellan, Javier González, Fabrice Gasnier,
Mark Gross, linux-acpi, Jonathan Corbet, Chunyan Zhang,
Mario Limonciello, linux-stm32, Lakshmi Ramasubramanian,
Ludovic Desroches, Pawan Gupta, linux-arm-kernel, Tom Rix,
Frederic Barrat, Niklas Cassel, Len Brown, Juergen Gross,
linuxppc-dev, Mika Westerberg, Alexandre Torgue, linux-pm,
linux-kernel, Richard Cochran, Oded Gabbay, Baolin Wang,
Lars-Peter Clausen, Dan Murphy, Orson Zhai, Philippe Bergheaud,
xen-devel, Boris Ostrovsky, Andy Shevchenko, Benson Leung,
Konstantin Khlebnikov, Jens Axboe, Felipe Balbi, Kranthi Kuntala,
Martin K. Petersen, Greg Kroah-Hartman, linux-usb,
Rafael J. Wysocki, Nicolas Ferre, linux-iio, Thinh Nguyen,
Sergey Senozhatsky, Stefano Stabellini, Thomas Gleixner,
Leonid Maksymchuk, Maxime Coquelin, Johannes Thumshirn,
Enric Balletbo i Serra, Vaibhav Jain, Vineela Tummalapalli,
Peter Rosin, Mike Kravetz
In-Reply-To: <20201108165621.4d0da3f4@archlinux>
Hi Jonathan,
Em Sun, 8 Nov 2020 16:56:21 +0000
Jonathan Cameron <jic23@kernel.org> escreveu:
> > PS.: the IIO subsystem is the one that currently has more duplicated
> > ABI entries:
> > $ ./scripts/get_abi.pl validate 2>&1|grep iio
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:0 Documentation/ABI/testing/sysfs-bus-iio:394
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:1 Documentation/ABI/testing/sysfs-bus-iio:395
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:2 Documentation/ABI/testing/sysfs-bus-iio:396
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:3 Documentation/ABI/testing/sysfs-bus-iio:397
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:4 Documentation/ABI/testing/sysfs-bus-iio:398
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-icm42600:5 Documentation/ABI/testing/sysfs-bus-iio:399
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100 Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:117 Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:14
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available is defined 3 times: Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8:2 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:111 Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:8
> > Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:0 Documentation/ABI/testing/sysfs-bus-iio:599
> > Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:36 Documentation/ABI/testing/sysfs-bus-iio:588
> > Warning: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als:43 Documentation/ABI/testing/sysfs-bus-iio-health-afe440x:38
> > Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:0 Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:0
> > Warning: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010:1 Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x:1
> > Warning: /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-distance-srf08:0 Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935:8
> > Warning: /sys/bus/iio/devices/triggerX/sampling_frequency is defined 2 times: Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:92 Documentation/ABI/testing/sysfs-bus-iio:45
>
> That was intentional. Often these provide more information on the
> ABI for a particular device than is present in the base ABI doc.
FYI, right now, there are 20 duplicated entries, being 16 of them
from IIO, on those files:
$ ./scripts/get_abi.pl validate 2>&1|perl -ne 'if (m,(Documentation/\S+)\:,g) { print "$1\n" }'|sort|uniq
Documentation/ABI/stable/sysfs-driver-w1_ds28e04
Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
Documentation/ABI/testing/sysfs-bus-iio-distance-srf08
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371
Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc2010
Documentation/ABI/testing/sysfs-bus-iio-icm42600
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als
Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
Documentation/ABI/testing/sysfs-class-backlight-adp8860
Documentation/ABI/testing/sysfs-class-led-trigger-pattern
Documentation/ABI/testing/sysfs-kernel-iommu_groups
>
> A bit like when we have additional description for dt binding properties
> for a particular device, even though they are standard properties.
>
> Often a standard property allows for more values than the specific
> one for a particular device. There can also be obscuring coupling
> between sysfs attributes due to hardware restrictions that we would
> like to provide some explanatory info on.
>
> I suppose we could add all this information to the parent doc but
> that is pretty ugly and will make that doc very nasty to read.
I understand what you meant to do, but right now, it is is actually
a lot uglier than merging into a single entry ;-)
Let's view ABI from the PoV of a system admin that doesn't know
yet about a certain ABI symbol.
He'll try to seek for the symbol, more likely using the HTML
documentation. Only very senior system admins might try to take
a look at the Kernel.
This is what happens when one would seek for a duplicated symbol
via command line:
$ ./scripts/get_abi.pl search /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency$
/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
----------------------------------------------------------
Kernel version: 3.4.0
Contact: linux-iio@vger.kernel.org
Defined on file(s): Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 Documentation/ABI/testing/sysfs-bus-iio
Description:
Stores the PLL frequency in Hz for channel Y.
Reading returns the actual frequency in Hz.
The ADF4371 has an integrated VCO with fundamendal output
frequency ranging from 4000000000 Hz 8000000000 Hz.
out_altvoltage0_frequency:
A divide by 1, 2, 4, 8, 16, 32 or circuit generates
frequencies from 62500000 Hz to 8000000000 Hz.
out_altvoltage1_frequency:
This channel duplicates the channel 0 frequency
out_altvoltage2_frequency:
A frequency doubler generates frequencies from
8000000000 Hz to 16000000000 Hz.
out_altvoltage3_frequency:
A frequency quadrupler generates frequencies from
16000000000 Hz to 32000000000 Hz.
Note: writes to one of the channels will affect the frequency of
all the other channels, since it involves changing the VCO
fundamental output frequency.
Output frequency for channel Y in Hz. The number must always be
specified and unique if the output corresponds to a single
channel.
As the "What:" field is identical on both sysfs-bus-iio-frequency-adf4371
and sysfs-bus-iio, those entries are merged, which produces an ABI
documentation mixing both the generic one and the board specific one
into a single output.
Worse than that, the "generic" content is at the end.
The same happens when generating the HTML output.
See, entries at the HTML output are ordered by the What: field,
which is considered within the script as an unique key, as it is
unique (except for IIO and a couple of other cases).
-
As I commented on an e-mail I sent to Greg, I see a few ways
to solve it.
The most trivial one (which I used to solve a few conflicts on
other places), is to place driver-specific details on a separate
file under Documentation/driver-api, and mention it at the
generic entries. The docs building system will generate cross
references for Documentation/.../foo.rst files, so, everything
should be OK.
The second alternative that I also used on a couple of places
is to modify the generic entry for it to contain the generic
definition first, followed by per-device details.
There is a third possible alternative: add a new optional field
(something like Scope:) which would be part of the unique key,
if present. Implementing support for it could be tricky, as the
produced output would likely need to create cross-references
between the generic field (if present) and the per-device details.
Thanks,
Mauro
PS.: I'm taking a few days of PTO during this week. So, it
could take a while for me to reply again to this thread.
^ permalink raw reply
* Re:Re: [PATCH] sched/rt, powerpc: Prepare for PREEMPT_RT
From: 王擎 @ 2020-11-10 6:26 UTC (permalink / raw)
To: Christophe Leroy
Cc: Greg Kroah-Hartman, Peter Zijlstra, linuxppc-dev, Nicholas Piggin,
linux-kernel, Paul Mackerras, Aneesh Kumar K.V, Alistair Popple,
tglx, Jordan Niethe
In-Reply-To: <20201110071839.Horde.h-QuHo16fxj_ok8Qgdbdnw8@messagerie.c-s.fr>
>Quoting Wang Qing <wangqing@vivo.com>:
>
>> Add PREEMPT_RT output to die().
>>
>> Signed-off-by: Wang Qing <wangqing@vivo.com>
>> ---
>> arch/powerpc/kernel/traps.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index 5006dcb..6dfe567
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -258,6 +258,14 @@ static char *get_mmu_str(void)
>> return "";
>> }
>>
>> +#ifdef CONFIG_PREEMPT
>> +#define S_PREEMPT " PREEMPT"
>> +#elif defined(CONFIG_PREEMPT_RT)
>> +#define S_PREEMPT " PREEMPT_RT"
>> +#else
>> +#define S_PREEMPT ""
>> +#endif
>
>I don't like too much that forest of #ifdefs. IS_ENABLED() is prefered
>whenever possible.
>
>> +
>> static int __die(const char *str, struct pt_regs *regs, long err)
>> {
>> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>> @@ -265,7 +273,7 @@ static int __die(const char *str, struct pt_regs
>> *regs, long err)
>> printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
>> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
>> PAGE_SIZE / 1024, get_mmu_str(),
>> - IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
>> + S_PREEMPT,
>> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
>> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
>> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
>> --
>> 2.7.4
>
>I'd prefer to remain in line with the existing and use IS_ENABLED()
>instead of #ifdefs, see below:
>
>diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>index 5006dcbe1d9f..dec7b81c72a4 100644
>--- a/arch/powerpc/kernel/traps.c
>+++ b/arch/powerpc/kernel/traps.c
>@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs
>*regs, long err)
> {
> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>
>- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
>+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> PAGE_SIZE / 1024, get_mmu_str(),
> IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
>+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
>---
>Christophe
Yeah, I agree with it.
Wang Qing
^ permalink raw reply
* Re: [PATCH] sched/rt, powerpc: Prepare for PREEMPT_RT
From: Christophe Leroy @ 2020-11-10 6:18 UTC (permalink / raw)
To: Wang Qing
Cc: Greg Kroah-Hartman, Peter Zijlstra, linuxppc-dev, Nicholas Piggin,
linux-kernel, Paul Mackerras, Aneesh Kumar K.V, Alistair Popple,
tglx, Jordan Niethe
In-Reply-To: <1604893209-18762-1-git-send-email-wangqing@vivo.com>
Quoting Wang Qing <wangqing@vivo.com>:
> Add PREEMPT_RT output to die().
>
> Signed-off-by: Wang Qing <wangqing@vivo.com>
> ---
> arch/powerpc/kernel/traps.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 5006dcb..6dfe567
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -258,6 +258,14 @@ static char *get_mmu_str(void)
> return "";
> }
>
> +#ifdef CONFIG_PREEMPT
> +#define S_PREEMPT " PREEMPT"
> +#elif defined(CONFIG_PREEMPT_RT)
> +#define S_PREEMPT " PREEMPT_RT"
> +#else
> +#define S_PREEMPT ""
> +#endif
I don't like too much that forest of #ifdefs. IS_ENABLED() is prefered
whenever possible.
> +
> static int __die(const char *str, struct pt_regs *regs, long err)
> {
> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
> @@ -265,7 +273,7 @@ static int __die(const char *str, struct pt_regs
> *regs, long err)
> printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> PAGE_SIZE / 1024, get_mmu_str(),
> - IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
> + S_PREEMPT,
> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
> --
> 2.7.4
I'd prefer to remain in line with the existing and use IS_ENABLED()
instead of #ifdefs, see below:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcbe1d9f..dec7b81c72a4 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs
*regs, long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
---
Christophe
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: Fix comparing pointer to 0 warning
From: Christophe Leroy @ 2020-11-10 6:07 UTC (permalink / raw)
To: xiakaixu1987, mpe, benh, paulus; +Cc: linuxppc-dev, Kaixu Xia, linux-kernel
In-Reply-To: <1604976961-20441-1-git-send-email-kaixuxia@tencent.com>
Le 10/11/2020 à 03:56, xiakaixu1987@gmail.com a écrit :
> From: Kaixu Xia <kaixuxia@tencent.com>
>
> Fixes coccicheck warning:
>
> ./arch/powerpc/mm/pgtable_32.c:87:11-12: WARNING comparing pointer to 0
>
> Avoid pointer type value compared to 0.
>
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/pgtable_32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 079159e97bca..888b9713a316 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -84,7 +84,7 @@ int __ref map_kernel_page(unsigned long va, phys_addr_t pa, pgprot_t prot)
> pg = pte_alloc_kernel(pd, va);
> else
> pg = early_pte_alloc_kernel(pd, va);
> - if (pg != 0) {
> + if (pg) {
> err = 0;
> /* The PTE should never be already set nor present in the
> * hash table
>
^ permalink raw reply
* Re: [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
From: Ira Weiny @ 2020-11-10 4:59 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-aio, linux-efi, kvm, linux-doc, Peter Zijlstra, linux-mmc,
Dave Hansen, dri-devel, linux-mm, target-devel, linux-mtd,
linux-kselftest, samba-technical, ceph-devel, drbd-dev, devel,
linux-cifs, linux-nilfs, linux-scsi, linux-nvdimm, linux-rdma,
x86, amd-gfx, io-uring, cluster-devel, Ingo Molnar,
intel-wired-lan, xen-devel, linux-ext4, Fenghua Yu, linux-afs,
linux-um, intel-gfx, ecryptfs, linux-erofs, reiserfs-devel,
linux-block, linux-bcache, Borislav Petkov, Andy Lutomirski,
Dan Williams, Andrew Morton, linux-cachefs, linux-nfs,
linux-ntfs-dev, netdev, Randy Dunlap, kexec, linux-kernel,
linux-f2fs-devel, linux-fsdevel, bpf, linuxppc-dev, linux-btrfs
In-Reply-To: <87h7pyhv3f.fsf@nanos.tec.linutronix.de>
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required to set the protections on multiple
> > processors (globally). Enabling PKS globally can be very expensive
> > depending on the requested operation. Furthermore, enabling a domain
> > globally reduces the protection afforded by PKS.
> >
> > Most kmap() (Aprox 209 of 229) callers use the map within a single thread and
> > have no need for the protection domain to be enabled globally. However, the
> > remaining callers do not follow this pattern and, as best I can tell, expect
> > the mapping to be 'global' and available to any thread who may access the
> > mapping.[1]
> >
> > We don't anticipate global mappings to pmem, however in general there is a
> > danger in changing the semantics of kmap(). Effectively, this would cause an
> > unresolved page fault with little to no information about why the failure
> > occurred.
> >
> > To resolve this a number of options were considered.
> >
> > 1) Attempt to change all the thread local kmap() calls to kmap_atomic()[2]
> > 2) Introduce a flags parameter to kmap() to indicate if the mapping should be
> > global or not
> > 3) Change ~20 call sites to 'kmap_global()' to indicate that they require a
> > global enablement of the pages.
> > 4) Change ~209 call sites to 'kmap_thread()' to indicate that the mapping is to
> > be used within that thread of execution only
> >
> > Option 1 is simply not feasible. Option 2 would require all of the call sites
> > of kmap() to change. Option 3 seems like a good minimal change but there is a
> > danger that new code may miss the semantic change of kmap() and not get the
> > behavior the developer intended. Therefore, #4 was chosen.
>
> There is Option #5:
There is now yes. :-D
>
> Convert the thread local kmap() invocations to the proposed kmap_local()
> interface which is coming along [1].
I've been trying to follow that thread.
>
> That solves a couple of issues:
>
> 1) It relieves the current kmap_atomic() usage sites from the implict
> pagefault/preempt disable semantics which apply even when
> CONFIG_HIGHMEM is disabled. kmap_local() still can be invoked from
> atomic context.
>
> 2) Due to #1 it allows to replace the conditional usage of kmap() and
> kmap_atomic() for purely thread local mappings.
>
> 3) It puts the burden on the HIGHMEM inflicted systems
>
> 4) It is actually more efficient for most of the pure thread local use
> cases on HIGHMEM inflicted systems because it avoids the overhead of
> the global lock and the potential kmap slot exhaustion. A potential
> preemption will be more expensive, but that's not really the case we
> want to optimize for.
>
> 5) It solves the RT issue vs. kmap_atomic()
>
> So instead of creating yet another variety of kmap() which is just
> scratching the particular PKRS itch, can we please consolidate all of
> that on the wider reaching kmap_local() approach?
Yes I agree. We absolutely don't want more kmap*() calls and I was hoping to
dovetail into your kmap_local() work.[2]
I've pivoted away from this work a bit to clean up all the
kmap()/memcpy*()/kunmaps() as discussed elsewhere in the thread first.[3] I
was hoping your work would land and then I could s/kmap_thread()/kmap_local()/
on all of these patches.
Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
[For now my patch just uses kmap_atomic().]
I've not looked at all of the patches in your latest version. Have you
included converting any of the kmap() call sites? I thought you were more
focused on converting the kmap_atomic() to kmap_local()?
Ira
>
> Thanks,
>
> tglx
>
> [1] https://lore.kernel.org/lkml/20201103092712.714480842@linutronix.de/
[2] https://lore.kernel.org/lkml/20201012195354.GC2046448@iweiny-DESK2.sc.intel.com/
[3] https://lore.kernel.org/lkml/20201009213434.GA839@sol.localdomain/
https://lore.kernel.org/lkml/20201013200149.GI3576660@ZenIV.linux.org.uk/
^ permalink raw reply
* [PATCH] powerpc/mm: Fix comparing pointer to 0 warning
From: xiakaixu1987 @ 2020-11-10 2:56 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: Kaixu Xia, linuxppc-dev, linux-kernel
From: Kaixu Xia <kaixuxia@tencent.com>
Fixes coccicheck warning:
./arch/powerpc/mm/pgtable_32.c:87:11-12: WARNING comparing pointer to 0
Avoid pointer type value compared to 0.
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
---
arch/powerpc/mm/pgtable_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 079159e97bca..888b9713a316 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -84,7 +84,7 @@ int __ref map_kernel_page(unsigned long va, phys_addr_t pa, pgprot_t prot)
pg = pte_alloc_kernel(pd, va);
else
pg = early_pte_alloc_kernel(pd, va);
- if (pg != 0) {
+ if (pg) {
err = 0;
/* The PTE should never be already set nor present in the
* hash table
--
2.20.0
^ permalink raw reply related
* Re: [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
From: Thomas Gleixner @ 2020-11-10 1:13 UTC (permalink / raw)
To: ira.weiny, Andrew Morton, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, Peter Zijlstra
Cc: linux-aio, linux-efi, kvm, linux-doc, linux-mmc, Dave Hansen,
dri-devel, linux-mm, target-devel, linux-mtd, linux-kselftest,
samba-technical, Ira Weiny, ceph-devel, drbd-dev, devel,
linux-cifs, linux-nilfs, linux-scsi, linux-nvdimm, linux-rdma,
x86, amd-gfx, linux-afs, cluster-devel, linux-cachefs,
intel-wired-lan, xen-devel, linux-ext4, Fenghua Yu, linux-um,
intel-gfx, ecryptfs, linux-erofs, reiserfs-devel, linux-block,
linux-bcache, Dan Williams, io-uring, linux-nfs, linux-ntfs-dev,
netdev, Randy Dunlap, kexec, linux-kernel, linux-f2fs-devel,
linux-fsdevel, bpf, linuxppc-dev, linux-btrfs
In-Reply-To: <20201009195033.3208459-6-ira.weiny@intel.com>
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending on the requested operation. Furthermore, enabling a domain
> globally reduces the protection afforded by PKS.
>
> Most kmap() (Aprox 209 of 229) callers use the map within a single thread and
> have no need for the protection domain to be enabled globally. However, the
> remaining callers do not follow this pattern and, as best I can tell, expect
> the mapping to be 'global' and available to any thread who may access the
> mapping.[1]
>
> We don't anticipate global mappings to pmem, however in general there is a
> danger in changing the semantics of kmap(). Effectively, this would cause an
> unresolved page fault with little to no information about why the failure
> occurred.
>
> To resolve this a number of options were considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()[2]
> 2) Introduce a flags parameter to kmap() to indicate if the mapping should be
> global or not
> 3) Change ~20 call sites to 'kmap_global()' to indicate that they require a
> global enablement of the pages.
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the mapping is to
> be used within that thread of execution only
>
> Option 1 is simply not feasible. Option 2 would require all of the call sites
> of kmap() to change. Option 3 seems like a good minimal change but there is a
> danger that new code may miss the semantic change of kmap() and not get the
> behavior the developer intended. Therefore, #4 was chosen.
There is Option #5:
Convert the thread local kmap() invocations to the proposed kmap_local()
interface which is coming along [1].
That solves a couple of issues:
1) It relieves the current kmap_atomic() usage sites from the implict
pagefault/preempt disable semantics which apply even when
CONFIG_HIGHMEM is disabled. kmap_local() still can be invoked from
atomic context.
2) Due to #1 it allows to replace the conditional usage of kmap() and
kmap_atomic() for purely thread local mappings.
3) It puts the burden on the HIGHMEM inflicted systems
4) It is actually more efficient for most of the pure thread local use
cases on HIGHMEM inflicted systems because it avoids the overhead of
the global lock and the potential kmap slot exhaustion. A potential
preemption will be more expensive, but that's not really the case we
want to optimize for.
5) It solves the RT issue vs. kmap_atomic()
So instead of creating yet another variety of kmap() which is just
scratching the particular PKRS itch, can we please consolidate all of
that on the wider reaching kmap_local() approach?
Thanks,
tglx
[1] https://lore.kernel.org/lkml/20201103092712.714480842@linutronix.de/
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: misc: convert fsl, qoriq-mc from txt to YAML
From: Rob Herring @ 2020-11-09 22:11 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: devicetree, corbet, netdev, linux-doc, linux-kernel, leoyang.li,
robh+dt, ioana.ciornei, Ionut-robert Aron, kuba, linuxppc-dev,
davem, linux-arm-kernel
In-Reply-To: <20201109104635.21116-2-laurentiu.tudor@nxp.com>
On Mon, 09 Nov 2020 12:46:35 +0200, Laurentiu Tudor wrote:
> From: Ionut-robert Aron <ionut-robert.aron@nxp.com>
>
> Convert fsl,qoriq-mc to YAML in order to automate the verification
> process of dts files. In addition, update MAINTAINERS accordingly
> and, while at it, add some missing files.
>
> Signed-off-by: Ionut-robert Aron <ionut-robert.aron@nxp.com>
> [laurentiu.tudor@nxp.com: update MINTAINERS, updates & fixes in schema]
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> Changes in v2:
> - fixed errors reported by yamllint
> - dropped multiple unnecessary quotes
> - used schema instead of text in description
> - added constraints on dpmac reg property
>
> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 ----------------
> .../bindings/misc/fsl,qoriq-mc.yaml | 210 ++++++++++++++++++
> .../ethernet/freescale/dpaa2/overview.rst | 5 +-
> MAINTAINERS | 4 +-
> 4 files changed, 217 insertions(+), 198 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: misc: convert fsl, dpaa2-console from txt to YAML
From: Rob Herring @ 2020-11-09 22:11 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: devicetree, corbet, netdev, linux-doc, linux-kernel, leoyang.li,
robh+dt, ioana.ciornei, Ionut-robert Aron, kuba, linuxppc-dev,
davem, linux-arm-kernel
In-Reply-To: <20201109104635.21116-1-laurentiu.tudor@nxp.com>
On Mon, 09 Nov 2020 12:46:34 +0200, Laurentiu Tudor wrote:
> From: Ionut-robert Aron <ionut-robert.aron@nxp.com>
>
> Convert fsl,dpaa2-console to YAML in order to automate the
> verification process of dts files.
>
> Signed-off-by: Ionut-robert Aron <ionut-robert.aron@nxp.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> Changes in v2:
> - add missing additionalProperties
>
> .../bindings/misc/fsl,dpaa2-console.txt | 11 --------
> .../bindings/misc/fsl,dpaa2-console.yaml | 25 +++++++++++++++++++
> 2 files changed, 25 insertions(+), 11 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
> create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
>
Applied, thanks!
^ 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