sdk7780_defconfig
i386 alldefconfig
mipsvocore2_defconfig
x86_64randconfig-c001
arm randconfig-c002-20220408
arm randconfig-c002-20220406
arm randconfig-c002-20220407
ia64
On 2022-04-04 23:51:37 Mon, Hari Bathini wrote:
> An LPAR can be terminated by the POWER Hypervisor (PHYP) for various
> reasons. If FADump was configured when PHYP terminates the LPAR,
> platform-assisted dump is initiated to save the kernel dump. But CPU
> register data would not be processed/sav
onfig
i386 alldefconfig
mipsvocore2_defconfig
x86_64randconfig-c001
arm randconfig-c002-20220408
arm randconfig-c002-20220406
arm randconfig-c002-20220407
ia64 allmodc
Christophe Leroy writes:
> Le 04/04/2022 à 07:22, Christophe Leroy a écrit :
>> Le 11/03/2022 à 05:49, Andrew Morton a écrit :
>>> On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman
>>> wrote:
>>>
> What will be the merge strategy ? I guess it's a bit late to get it
> through powerpc tr
Andrew Morton writes:
> On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman
> wrote:
>
>> > What will be the merge strategy ? I guess it's a bit late to get it
>> > through powerpc tree, so I was just wondering whether we could get
>> > patches 2 to 5 in mm this cycle, and the powerpc ones nex
Christophe Leroy writes:
> Le 06/04/2022 à 16:58, Michael Ellerman a écrit :
>> We added checks to __pa() / __va() to ensure they're only called with
>> appropriate addresses. But using BUG_ON() is too strong, it means
>> virt_addr_valid() will BUG when DEBUG_VIRTUAL is enabled.
>>
>> Instead swi
On Thu, 7 Apr 2022 12:28:47 +0200 Jakob Koschel wrote:
> diff --git a/drivers/net/dsa/sja1105/sja1105_vl.c
> b/drivers/net/dsa/sja1105/sja1105_vl.c
> index b7e95d60a6e4..cfcae4d19eef 100644
> --- a/drivers/net/dsa/sja1105/sja1105_vl.c
> +++ b/drivers/net/dsa/sja1105/sja1105_vl.c
> @@ -27,20 +27,2
On Sun, Oct 17, 2021 at 07:19:47PM +0200, Christophe Leroy wrote:
> But for EXEC_RODATA test, execute_location() uses
> lkdtm_rodata_do_nothing() which is already in rodata section
> at build time instead of using a copy of do_nothing(). However
> it still uses the function descriptor of do_nothing
On 4/8/22 04:50, Andrew Morton wrote:
> On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual
> wrote:
>
>> protection_map[] is an array based construct that translates given vm_flags
>> combination. This array contains page protection map, which is populated by
>> the platform via [__S000 ..
On 07/04/2022 11:28, Jakob Koschel wrote:
> In preparation to limit the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element [1].
>
> Before, the code implicitly used the head when no element was found
> when using &pos->list. Since the new v
On Fri, Apr 08, 2022 at 07:14:20AM +0800, Zhouyi Zhou wrote:
> Dear Paul and Miguel
>
> On Fri, Apr 8, 2022 at 1:55 AM Paul E. McKenney wrote:
> >
> > On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> > > On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney
> > > wrote:
> > > >
> > > >
On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual
wrote:
> protection_map[] is an array based construct that translates given vm_flags
> combination. This array contains page protection map, which is populated by
> the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros.
>
Dear Paul and Miguel
On Fri, Apr 8, 2022 at 1:55 AM Paul E. McKenney wrote:
>
> On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> > On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
> > >
> > > Ah. So you would instead look for boot to have completed within 10
> > > seconds?
On Thu, Apr 07, 2022 at 03:43:20PM -0300, Murilo Opsfelder Araújo wrote:
> On 4/6/22 04:08, Joel Stanley wrote:
> >On Thu, 31 Mar 2022 at 23:46, Segher Boessenkool
> > wrote:
> >>On Thu, Mar 31, 2022 at 12:19:52PM -0300, Murilo Opsfelder Araújo wrote:
> >>>My understanding is that the default cpu t
On 4/7/22 12:40 PM, Athira Rajeev wrote:
The selftest "mqueue/mq_perf_tests.c" use CPU_ALLOC to allocate
CPU set. This cpu set is used further in pthread_attr_setaffinity_np
and by pthread_create in the code. But in current code, allocated
cpu set is not freed.
Fix this issue by adding CPU_FREE
On 4/6/22 04:08, Joel Stanley wrote:
On Thu, 31 Mar 2022 at 23:46, Segher Boessenkool
wrote:
On Thu, Mar 31, 2022 at 12:19:52PM -0300, Murilo Opsfelder Araújo wrote:
My understanding is that the default cpu type for -mcpu=powerpc64 can
change.
Different subtargets (Linux, AIX, Darwin, the v
The selftest "mqueue/mq_perf_tests.c" use CPU_ALLOC to allocate
CPU set. This cpu set is used further in pthread_attr_setaffinity_np
and by pthread_create in the code. But in current code, allocated
cpu set is not freed.
Fix this issue by adding CPU_FREE in the "shutdown" function which
is called
Hi Kees,
Le 23/02/2022 à 18:17, Christophe Leroy a écrit :
Hi Kees,
Le 17/10/2021 à 19:19, Christophe Leroy a écrit :
All EXEC tests are based on running a copy of do_nothing()
except lkdtm_EXEC_RODATA which uses a different function
called lkdtm_rodata_do_nothing().
On architectures using fu
Hi Andrew,
Le 04/04/2022 à 07:22, Christophe Leroy a écrit :
Hi Andrew,
Le 11/03/2022 à 05:49, Andrew Morton a écrit :
On Fri, 11 Mar 2022 15:26:42 +1100 Michael Ellerman
wrote:
What will be the merge strategy ? I guess it's a bit late to get it
through powerpc tree, so I was just wonderin
On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
> >
> > Ah. So you would instead look for boot to have completed within 10
> > seconds? Either way, reliable automation might well more important than
> > reduction in time.
>
On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
>
> Ah. So you would instead look for boot to have completed within 10
> seconds? Either way, reliable automation might well more important than
> reduction in time.
No (although I guess that could be an option), I was only pointing out
tha
On 4/7/22 03:11, Finn Thain wrote:
> drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
> via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
> via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
> via-pmu-event.c:(.text+0x94): undefined reference to `i
On 4/7/22 04:32, Anshuman Khandual wrote:
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. It localizes arch_vm_get_page_prot()
as sparc_vm_get_page_prot() and moves near vm_get_page_prot().
Cc: "David S. Miller"
Cc: Khalid Aziz
On Thu, Apr 07, 2022 at 12:07:34PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote:
> >
> > Yes, this happens within 30 seconds after kernel boot. If we take all
> > into account (qemu preparing, kernel loading), we can do one test
> > within 54 seconds.
>
> When it
We can mark arch_get_ima_policy() as __init because it's only caller
ima_init_arch_policy() is __init. We can then mark
is_ppc_trustedboot_enabled() __init because its only caller is
arch_get_ima_policy().
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/ima_arch.c| 2 +-
arch/powerpc
There are no platforms left which use arch_vm_get_page_prot(). Just drop
generic arch_vm_get_page_prot().
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
include/linux/mman.h | 4
mm/mmap.c| 3 +--
2 files changed,
From: Christoph Hellwig
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. This also unsubscribes from config
ARCH_HAS_FILTER_PGPROT, after dropping off arch_filter_pgprot() and
arch_vm_get_page_prot().
Cc: Thomas Gleixner
Cc: Ingo
There are no platforms left which subscribe ARCH_HAS_FILTER_PGPROT. Hence
drop generic arch_filter_pgprot() and also config ARCH_HAS_FILTER_PGPROT.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
mm/Kconfig | 3 ---
mm/mmap.c | 9 +
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. It localizes arch_vm_get_page_prot()
as sparc_vm_get_page_prot() and moves near vm_get_page_prot().
Cc: "David S. Miller"
Cc: Khalid Aziz
Cc: sparcli...@vger.kernel.org
Cc: linux-ker
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. It localizes arch_vm_get_page_prot()
and moves it near vm_get_page_prot().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.o
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. While here, this also localizes
arch_vm_get_page_prot() as powerpc_vm_get_page_prot() and moves it near
vm_get_page_prot().
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: linuxppc-dev@l
Add a new config ARCH_HAS_VM_GET_PAGE_PROT, which when subscribed enables a
given platform to define its own vm_get_page_prot() but still utilizing the
generic protection_map[] array.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Christoph Hellwig
Signed
protection_map[] is an array based construct that translates given vm_flags
combination. This array contains page protection map, which is populated by
the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros.
Primary usage for protection_map[] is for vm_get_page_prot(), which is
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
By av
In preparation to limit the scope of the list iterator variable to the
list traversal loop, use a dedicated pointer to iterate through the
list [1].
Since that variable should not be used past the loop iteration, a
separate variable is used to 'remember the current location within the
loop'.
By av
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer to point to the found element [1].
Before, the code implicitly used the head when no element was found
when using &pos->list. Since the new variable is only set if an
element was found, the lis
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer to point to the found element [1].
Before, the code implicitly used the head when no element was found
when using &pos->list. Since the new variable is only set if an
element was found, the lis
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element, either with list_entry_is_
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
Since "found" and "p_ent" need to be equal, "found" should be used
consistently to limit the scope of "p_ent" to the list traversal in
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable [1].
Link:
https://lor
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
When the list iterator loop does not exit early the list iterator variable
contains a type-confused pointer to a 'bogus' list element computed based
on the head [1].
Often a 'found' variable is used to ensure the list iterator
variable is only accessed after the loop body if the loop did exit earl
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boole
In preparation to limit the scope of a list iterator to the list
traversal loop, use a dedicated pointer to point to the found element [1].
Before, the code implicitly used the head when no element was found
when using &pos->list. Since the new variable is only set if an
element was found, the lis
Le 07/04/2022 à 12:11, Finn Thain a écrit :
> drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
> via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
> via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
> via-pmu-event.c:(.text+0x94): undefined referen
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): unde
On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote:
>
> Yes, this happens within 30 seconds after kernel boot. If we take all
> into account (qemu preparing, kernel loading), we can do one test
> within 54 seconds.
When it does not trigger, the run should be 20 seconds quicker than
that (e.g. 10 s
On Tue, 5 Apr 2022 17:57:31 +0200, Ahmad Fatoum wrote:
> Refactoring in commit a50b7926d015 ("ASoC: fsl_sai: implement 1:1
> bclk:mclk ratio support") led to the bypass never happening
> as (ratio = 1) was caught in the existing if (ratio & 1) continue;
> check. The correct check sequence instead i
From: Lv Ruyi
of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
arch/powerpc/platforms/powernv/ultravisor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/
On Thu, 7 Apr 2022, Christophe Leroy wrote:
> Le 07/04/2022 à 05:16, Randy Dunlap a écrit :
> >
> >
> > On 4/6/22 19:37, Randy Dunlap wrote:
> >> When CONFIG_INPUT=m, the input_*() family of functions is not
> >> available to builtin drivers.
> >>
> >> When CONFIG_RTC_CLASS is not set, rtc_tm_to
Le 06/04/2022 à 20:55, Kees Cook a écrit :
> *thread necromancy*
>
> Is this patch still something folks are working on? It'd be nice to be
> able to trigger this check at runtime.
The series was taken over by Jordan.
v15 of the series was accepted, but that particular patch was dropped in
v1
On Wed, 6 Apr 2022, Randy Dunlap wrote:
> When CONFIG_RTC_CLASS is not set, rtc_tm_to_time64() is not defined.
>
> ...
>
> m68k-linux-ld: drivers/macintosh/via-pmu.o: in function `pmu_set_rtc_time':
> drivers/macintosh/via-pmu.c:1758: undefined reference to `rtc_tm_to_time64'
> m68k-linux-ld: dr
Le 07/04/2022 à 04:37, Randy Dunlap a écrit :
> When CONFIG_INPUT=m, the input_*() family of functions is not
> available to builtin drivers.
>
> When CONFIG_RTC_CLASS is not set, rtc_tm_to_time64() is not defined.
>
> Fix multiple build errors by making these Kconfig symbols required by
> ADB_
Le 07/04/2022 à 05:16, Randy Dunlap a écrit :
>
>
> On 4/6/22 19:37, Randy Dunlap wrote:
>> When CONFIG_INPUT=m, the input_*() family of functions is not
>> available to builtin drivers.
>>
>> When CONFIG_RTC_CLASS is not set, rtc_tm_to_time64() is not defined.
>>
>> Fix multiple build errors b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: b4b76b1523625e00a1c03f65df582df4977693b4 powerpc/mm: Add
virt_addr_valid() checks
elapsed time: 722m
configs tested: 69
configs skipped: 107
The following configs have been built successfull
60 matches
Mail list logo
