Le 01/02/2024 à 18:12, Hari Bathini a écrit :
> With module addresses supported, override bpf_jit_supports_kfunc_call()
> to enable kfunc support. Module address offsets can be more than 32-bit
> long, so override bpf_jit_supports_far_kfunc_call() to enable 64-bit
> pointers.
What's the impact
Le 01/02/2024 à 18:12, Hari Bathini a écrit :
> Currently, bpf jit code on powerpc assumes all the bpf functions and
> helpers to be kernel text. This is false for kfunc case, as function
> addresses are mostly module addresses in that case. Ensure module
> addresses are supported to enable
On Tue, Feb 13, 2024 at 8:01 PM Barry Song <21cn...@gmail.com> wrote:
>
> Hi Alex, Valentin,
>
>
> On Sun, Feb 11, 2024 at 12:37 AM wrote:
> >
> > From: Alex Shi
> >
> > SD_CLUSTER shares the CPU resources like llc tags or l2 cache, that's
> > easy confuse with SD_SHARE_PKG_RESOURCES. So let's
Hi Alex, Valentin,
On Sun, Feb 11, 2024 at 12:37 AM wrote:
>
> From: Alex Shi
>
> SD_CLUSTER shares the CPU resources like llc tags or l2 cache, that's
> easy confuse with SD_SHARE_PKG_RESOURCES. So let's specifical point
> what the latter shares: LLC. That would reduce some confusing.
On
* Shrikanth Hegde [2024-02-13 10:56:35]:
> powerVM hypervisor updates the VPA fields with stolen time data.
> It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
> this purpose. In linux these two fields are used to report the stolen time.
>
> The VPA fields are updated at the TB
On Tue Feb 13, 2024 at 3:26 PM AEST, Shrikanth Hegde wrote:
> powerVM hypervisor updates the VPA fields with stolen time data.
> It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
> this purpose. In linux these two fields are used to report the stolen time.
>
> The VPA fields are
On Mon, Feb 12, 2024 at 07:31:03PM +, Christophe Leroy wrote:
>
>
> Le 09/02/2024 à 08:59, Naveen N Rao a écrit :
> > diff --git a/arch/powerpc/include/asm/sections.h
> > b/arch/powerpc/include/asm/sections.h
> > index ea26665f82cf..d389dcecdb0b 100644
> > ---
powerVM hypervisor updates the VPA fields with stolen time data.
It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
this purpose. In linux these two fields are used to report the stolen time.
The VPA fields are updated at the TB frequency. On powerPC its mostly
set at 512Mhz. Hence
- Original Message -
> From: "Michael Ellerman"
> To: "Timothy Pearson" , "Segher Boessenkool"
>
> Cc: "linuxppc-dev"
> Sent: Monday, February 12, 2024 11:23:30 PM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> Timothy Pearson writes:
>> - Original
Timothy Pearson writes:
> - Original Message -
>> From: "Segher Boessenkool"
>> To: "Timothy Pearson"
>> Cc: "linuxppc-dev"
>> Sent: Monday, February 12, 2024 12:23:22 PM
>> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
>
>> On Mon, Feb 12, 2024 at 12:07:03PM
On Fri, 2024-02-09 at 13:29 +0530, Naveen N Rao wrote:
> Michael reported that we are seeing ftrace bug on bootup when KASAN
> is
> enabled, and if we are using -fpatchable-function-entry:
>
> ftrace: allocating 47780 entries in 18 pages
> ftrace-powerpc: 0xc20b3d5c: No module
The memset/memcpy functions are by default instrumented by KASAN, which
complains about user memory access when using a poking page in
userspace.
Using a userspace address is expected though, so don't instrument with
KASAN for this function.
Signed-off-by: Benjamin Gray
---
I tried to replace
On 02/12/24 at 07:27pm, Sourabh Jain wrote:
> Hello Baoquan,
>
> On 05/02/24 08:40, Baoquan He wrote:
> > Hi Sourabh,
> >
..
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index 802052d9c64b..7880d74dc5c4 100644
> > > --- a/include/linux/kexec.h
> > > +++
Christophe Leroy writes:
> Le 09/02/2024 à 08:59, Naveen N Rao a écrit :
>> Michael reported that we are seeing ftrace bug on bootup when KASAN is
>> enabled, and if we are using -fpatchable-function-entry:
>>
...
>> diff --git a/arch/powerpc/include/asm/sections.h
>>
Hello Andy
On 2/12/24 12:53, Andy Shevchenko wrote:
On Mon, Feb 12, 2024 at 1:52 AM George Stark wrote:
I haven't lose hope for the devm_mutex thing and keep pinging those guys
from time to time.
I don't understand. According to v4 thread Christophe proposed on how
the patch should look
Don't know why the previous mail went blank.
On Mon, 2024-02-12 at 17:42 +1100, Michael Ellerman wrote:
> KASAN is seen to increase stack usage, to the point that it was
> reported
> to lead to stack overflow on some 32-bit machines (see link).
>
> To avoid overflows the stack size was doubled
On 12/02/2024 14:29, David Hildenbrand wrote:
> On 12.02.24 15:10, Ryan Roberts wrote:
>> On 12/02/2024 12:14, David Hildenbrand wrote:
>>> On 02.02.24 09:07, Ryan Roberts wrote:
The goal is to be able to advance a PTE by an arbitrary number of PFNs.
So introduce a new API that takes a
[...]
+static inline bool mm_is_user(struct mm_struct *mm)
+{
+ /*
+ * Don't attempt to apply the contig bit to kernel mappings, because
+ * dynamically adding/removing the contig bit can cause page faults.
+ * These racing faults are ok for user space, since
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the ibmebus_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the macio_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the mpic_subsys variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the vio_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg
In order to make the distinction of the vio_bus_type variable based on
CONFIG_PPC_SMLPAR more explicit, move the required structs into a new
ifdef block. This is needed in order to make vio_bus_type const and
because the distinction is made explicit, there is no need to set the
fields within the
This series is part of an effort to cleanup the users of the driver
core, as can be seen in many recent patches authored by Greg across the
tree (e.g. [1]). Patch 1/5 is a prerequisite to 2/5, but the others have
no dependency. They were built using bootlin's without warnings using
Please disregard this series, I will send a v2.
Thank you,
- Ricardo.
Le 09/02/2024 à 08:59, Naveen N Rao a écrit :
> Michael reported that we are seeing ftrace bug on bootup when KASAN is
> enabled, and if we are using -fpatchable-function-entry:
>
> ftrace: allocating 47780 entries in 18 pages
> ftrace-powerpc: 0xc20b3d5c: No module provided
On Mon, Feb 12, 2024 at 7:36 PM Naresh Kamboju
wrote:
> I encountered the following build warnings/errors while compiling the powerpc
> kernel on Linux next-20240208 .. next-20240212 tag with clang toolchain.
>
> Reported-by: Linux Kernel Functional Testing
>
> powerpc64le-lin
On Mon, Feb 12, 2024 at 04:36:36PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 03:20:22PM +0100, Herve Codina wrote:
> > On Mon, 12 Feb 2024 16:01:38 +0200
> > Andy Shevchenko wrote:
>
> ...
>
> > Agree, the bitmap_onto() code is simpler to understand than its help.
> >
> > I
On 2/12/24 10:36, Naresh Kamboju wrote:
> I encountered the following build warnings/errors while compiling the powerpc
> kernel on Linux next-20240208 .. next-20240212 tag with clang toolchain.
>
> Reported-by: Linux Kernel Functional Testing
>
> powerpc64le-linux-g
On Mon, Feb 12, 2024 at 10:37:18AM -0800, Yury Norov wrote:
> On Mon, Feb 12, 2024 at 08:56:32AM +0100, Herve Codina wrote:
> > The bitmap_onto() function translates one bitmap relative to another but
> > no function are present to perform the reverse translation.
> >
> > Introduce bitmap_off()
On Mon, Feb 12, 2024 at 08:56:32AM +0100, Herve Codina wrote:
> The bitmap_onto() function translates one bitmap relative to another but
> no function are present to perform the reverse translation.
>
> Introduce bitmap_off() to fill this hole.
>
> Signed-off-by: Herve Codina
> ---
>
I encountered the following build warnings/errors while compiling the powerpc
kernel on Linux next-20240208 .. next-20240212 tag with clang toolchain.
Reported-by: Linux Kernel Functional Testing
powerpc64le-linux-gnu-ld: drivers/ps3/ps3av.o: in function `ps3av_probe':
ps3av.c:(.text+0x19e8
- Original Message -
> From: "Segher Boessenkool"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev"
> Sent: Monday, February 12, 2024 12:23:22 PM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
>>
On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
> > I have done it for *all* architectures some ten years ago. Never found
> > any problem.
>
> That makes sense, what I mean by invasive is that we'd need buy-in from the
> other
> maintainers across all of the affected
- Original Message -
> From: "Segher Boessenkool"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev"
> Sent: Monday, February 12, 2024 11:59:06 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
>>
On Mon, Feb 12, 2024 at 11:46:19AM -0600, Timothy Pearson wrote:
> Interesting, that make sense.
>
> How should we proceed from the current situation? Bringing in libgcc seems
> like a fairly invasive change,
I have done it for *all* architectures some ten years ago. Never found
any problem.
- Original Message -
> From: "Segher Boessenkool"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev"
> Sent: Monday, February 12, 2024 11:30:43 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
>
> Long long time ago, linux-0.11 or something, it was discovered
On Mon, Feb 12, 2024 at 11:09:38AM -0600, Timothy Pearson wrote:
> There is existing code in the kernel right now to provide support functions
> for gpr0 and altivec save/restore. I don't know the full story here, but at
> some point in the kernel's history it seems to have been decided to
When building the kernel in size optimized mode with the amdgpu module enabled,
gcc will begin referencing external gpr1 and fpu save/restore functions. This
will then cause a linker failure as we do not link against libgcc which
normally contains those builtin functions.
Implement gpr1 and fpu
- Original Message -
> From: "Segher Boessenkool"
> To: "Timothy Pearson"
> Cc: "linuxppc-dev"
> Sent: Monday, February 12, 2024 11:02:07 AM
> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
> On Mon, Feb 12, 2024 at 10:41:18AM -0600, Timothy Pearson wrote:
>>
On Mon, Feb 12, 2024 at 10:41:18AM -0600, Timothy Pearson wrote:
> Implement gpr1 and fpu save/restore functions per the ABI v2 documentation.
There is no "ABI v2". This is the ELFv2 ABI, it is a name, it is not a
version 2 of anything (in fact, it is version 1 everywhere).
The same functions
When building the kernel in size optimized mode with the amdgpu module enabled,
gcc will begin referencing external gpr1 and fpu save/restore functions. This
will then cause a linker failure as we do not link against libgcc which
normally contains those builtin functions.
Implement gpr1 and fpu
On 12.02.24 16:47, Ryan Roberts wrote:
On 12/02/2024 13:43, David Hildenbrand wrote:
On 02.02.24 09:07, Ryan Roberts wrote:
Some architectures (e.g. arm64) can tell from looking at a pte, if some
follow-on ptes also map contiguous physical memory with the same pgprot.
(for arm64, these are
On 12.02.24 16:34, Ryan Roberts wrote:
On 12/02/2024 15:26, David Hildenbrand wrote:
On 12.02.24 15:45, Ryan Roberts wrote:
On 12/02/2024 13:54, David Hildenbrand wrote:
If so, I wonder if we could instead do that comparison modulo the access/dirty
bits,
I think that would work - but will
On 12/02/2024 13:43, David Hildenbrand wrote:
> On 02.02.24 09:07, Ryan Roberts wrote:
>> Some architectures (e.g. arm64) can tell from looking at a pte, if some
>> follow-on ptes also map contiguous physical memory with the same pgprot.
>> (for arm64, these are contpte mappings).
>>
>> Take
On 12/02/2024 15:26, David Hildenbrand wrote:
> On 12.02.24 15:45, Ryan Roberts wrote:
>> On 12/02/2024 13:54, David Hildenbrand wrote:
> If so, I wonder if we could instead do that comparison modulo the
> access/dirty
> bits,
I think that would work - but will need to think
On 2024-02-12 08:06:25 Mon, Christophe Leroy wrote:
>
>
> Le 05/02/2024 à 06:36, Mahesh Salgaonkar a écrit :
> > [Vous ne recevez pas souvent de courriers de mah...@linux.ibm.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> >
On 12/02/2024 12:59, Ryan Roberts wrote:
> On 12/02/2024 12:00, Mark Rutland wrote:
>> Hi Ryan,
>>
>> Overall this looks pretty good; I have a bunch of minor comments below, and a
>> bigger question on the way ptep_get_lockless() works.
>
> OK great - thanks for the review. Let's see if I can
On 12.02.24 15:45, Ryan Roberts wrote:
On 12/02/2024 13:54, David Hildenbrand wrote:
If so, I wonder if we could instead do that comparison modulo the access/dirty
bits,
I think that would work - but will need to think a bit more on it.
and leave ptep_get_lockless() only reading a single
On 12/02/2024 13:43, David Hildenbrand wrote:
> On 02.02.24 09:07, Ryan Roberts wrote:
>> Some architectures (e.g. arm64) can tell from looking at a pte, if some
>> follow-on ptes also map contiguous physical memory with the same pgprot.
>> (for arm64, these are contpte mappings).
>>
>> Take
On 12/02/2024 13:54, David Hildenbrand wrote:
>>> If so, I wonder if we could instead do that comparison modulo the
>>> access/dirty
>>> bits,
>>
>> I think that would work - but will need to think a bit more on it.
>>
>>> and leave ptep_get_lockless() only reading a single entry?
>>
>> I think
On Mon, Feb 12, 2024 at 03:20:22PM +0100, Herve Codina wrote:
> On Mon, 12 Feb 2024 16:01:38 +0200
> Andy Shevchenko wrote:
...
> Agree, the bitmap_onto() code is simpler to understand than its help.
>
> I introduced bitmap_off() to be the "reverse" bitmap_onto() operations
> and I preferred
On 12.02.24 15:10, Ryan Roberts wrote:
On 12/02/2024 12:14, David Hildenbrand wrote:
On 02.02.24 09:07, Ryan Roberts wrote:
The goal is to be able to advance a PTE by an arbitrary number of PFNs.
So introduce a new API that takes a nr param.
We are going to remove pte_next_pfn() and replace
On Mon, 12 Feb 2024 16:01:38 +0200
Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 02:37:53PM +0100, Herve Codina wrote:
> > On Mon, 12 Feb 2024 14:27:16 +0200
> > Andy Shevchenko wrote:
> > > On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:
> > > > Currently the bitmap_onto()
On 09.02.24 06:42, Anshuman Khandual wrote:
All platforms could benefit from page order check against MAX_PAGE_ORDER
before allocating a CMA area for gigantic hugetlb pages. Let's move this
check from individual platforms to generic hugetlb.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Michael
On 12/02/2024 12:14, David Hildenbrand wrote:
> On 02.02.24 09:07, Ryan Roberts wrote:
>> The goal is to be able to advance a PTE by an arbitrary number of PFNs.
>> So introduce a new API that takes a nr param.
>>
>> We are going to remove pte_next_pfn() and replace it with
>> pte_advance_pfn().
On Mon, Feb 12, 2024 at 02:37:53PM +0100, Herve Codina wrote:
> On Mon, 12 Feb 2024 14:27:16 +0200
> Andy Shevchenko wrote:
> > On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:
> > > Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
> > > while some users may
Hello Baoquan,
On 05/02/24 08:40, Baoquan He wrote:
Hi Sourabh,
Thanks for the great work. There are some concerns, please see inline
comments.
Thank you :)
On 01/11/24 at 04:21pm, Sourabh Jain wrote:
..
Now, if the kexec tool sends KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag to
the
If so, I wonder if we could instead do that comparison modulo the access/dirty
bits,
I think that would work - but will need to think a bit more on it.
and leave ptep_get_lockless() only reading a single entry?
I think we will need to do something a bit less fragile. ptep_get() does collect
On 02.02.24 09:07, Ryan Roberts wrote:
When core code iterates over a range of ptes and calls ptep_get() for
each of them, if the range happens to cover contpte mappings, the number
of pte reads becomes amplified by a factor of the number of PTEs in a
contpte block. This is because for each call
On 02.02.24 09:07, Ryan Roberts wrote:
Some architectures (e.g. arm64) can tell from looking at a pte, if some
follow-on ptes also map contiguous physical memory with the same pgprot.
(for arm64, these are contpte mappings).
Take advantage of this knowledge to optimize folio_pte_batch() so that
Hi Andy,
On Mon, 12 Feb 2024 14:27:16 +0200
Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:
> > Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
> > while some users may benefit out of it and being independent to NUMA
> > code.
> >
>
On 12/02/2024 13:15, David Hildenbrand wrote:
> On 12.02.24 14:05, Ryan Roberts wrote:
>> On 12/02/2024 12:44, David Hildenbrand wrote:
>>> On 02.02.24 09:07, Ryan Roberts wrote:
Split __flush_tlb_range() into __flush_tlb_range_nosync() +
__flush_tlb_range(), in the same way as the
Le 07/02/2024 à 10:27, David Engraf a écrit :
> [Vous ne recevez pas souvent de courriers de david.eng...@sysgo.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Commit e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h")
>
On 12.02.24 14:05, Ryan Roberts wrote:
On 12/02/2024 12:44, David Hildenbrand wrote:
On 02.02.24 09:07, Ryan Roberts wrote:
Split __flush_tlb_range() into __flush_tlb_range_nosync() +
__flush_tlb_range(), in the same way as the existing flush_tlb_page()
arrangement. This allows calling
On 12/02/2024 12:44, David Hildenbrand wrote:
> On 02.02.24 09:07, Ryan Roberts wrote:
>> Split __flush_tlb_range() into __flush_tlb_range_nosync() +
>> __flush_tlb_range(), in the same way as the existing flush_tlb_page()
>> arrangement. This allows calling __flush_tlb_range_nosync() to elide the
On 12/02/2024 12:00, Mark Rutland wrote:
> Hi Ryan,
>
> Overall this looks pretty good; I have a bunch of minor comments below, and a
> bigger question on the way ptep_get_lockless() works.
OK great - thanks for the review. Let's see if I can answer them all...
>
> On Fri, Feb 02, 2024 at
On 02.02.24 09:07, Ryan Roberts wrote:
Split __flush_tlb_range() into __flush_tlb_range_nosync() +
__flush_tlb_range(), in the same way as the existing flush_tlb_page()
arrangement. This allows calling __flush_tlb_range_nosync() to elide the
trailing DSB. Forthcoming "contpte" code will take
On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:
> Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
> while some users may benefit out of it and being independent to NUMA
> code.
>
> Make it available to users by moving out of ifdeffery and exporting for
>
On Mon, Feb 12, 2024 at 08:56:29AM +0100, Herve Codina wrote:
> The QMC HDLC driver provides support for HDLC using the QMC (QUICC
> Multichannel Controller) to transfer the HDLC data.
...
> +#include
> +#include
> +#include
> +#include
> +#include
I do not see how these are being used,
On 02.02.24 09:07, Ryan Roberts wrote:
The goal is to be able to advance a PTE by an arbitrary number of PFNs.
So introduce a new API that takes a nr param.
We are going to remove pte_next_pfn() and replace it with
pte_advance_pfn(). As a first step, implement pte_next_pfn() as a
wrapper around
On 02.02.24 09:07, Ryan Roberts wrote:
set_ptes() spec implies that it can only be used to set a present pte
because it interprets the PFN field to increment it. However,
set_pte_at() has been implemented on top of set_ptes() since set_ptes()
was introduced, and set_pte_at() allows setting a pte
Hi Ryan,
Overall this looks pretty good; I have a bunch of minor comments below, and a
bigger question on the way ptep_get_lockless() works.
On Fri, Feb 02, 2024 at 08:07:50AM +, Ryan Roberts wrote:
> With the ptep API sufficiently refactored, we can now introduce a new
> "contpte" API
On 05/02/24 08:41, Baoquan He wrote:
On 01/11/24 at 04:21pm, Sourabh Jain wrote:
In the event of memory hotplug or online/offline events, the crash
memory hotplug notifier `crash_memhp_notifier()` receives a
`memory_notify` object but doesn't forward that object to the
generic and
On 12.02.24 12:21, Ryan Roberts wrote:
On 12/02/2024 11:05, David Hildenbrand wrote:
On 12.02.24 11:56, David Hildenbrand wrote:
On 12.02.24 11:32, Ryan Roberts wrote:
On 12/02/2024 10:11, David Hildenbrand wrote:
Hi Ryan,
-static void tlb_batch_pages_flush(struct mmu_gather *tlb)
+static
From: Arnd Bergmann
A previous bugfix added a call to kcalloc(), which starting in gcc-14
causes a harmless warning about the argument order:
drivers/soc/fsl/dpio/dpio-service.c: In function
'dpaa2_io_service_enqueue_multiple_desc_fq':
drivers/soc/fsl/dpio/dpio-service.c:526:29: error:
On 12/02/2024 11:05, David Hildenbrand wrote:
> On 12.02.24 11:56, David Hildenbrand wrote:
>> On 12.02.24 11:32, Ryan Roberts wrote:
>>> On 12/02/2024 10:11, David Hildenbrand wrote:
Hi Ryan,
>> -static void tlb_batch_pages_flush(struct mmu_gather *tlb)
>> +static void
From: Arnd Bergmann
On powerpc, it is possible to compile test both the new apple (arm) and
old pasemi (powerpc) drivers for the i2c hardware at the same time,
which leads to a warning about linking the same object file twice:
scripts/Makefile.build:244: drivers/i2c/busses/Makefile:
On 12.02.24 11:56, David Hildenbrand wrote:
On 12.02.24 11:32, Ryan Roberts wrote:
On 12/02/2024 10:11, David Hildenbrand wrote:
Hi Ryan,
-static void tlb_batch_pages_flush(struct mmu_gather *tlb)
+static void __tlb_batch_free_encoded_pages(struct mmu_gather_batch *batch)
{
- struct
On 12.02.24 11:32, Ryan Roberts wrote:
On 12/02/2024 10:11, David Hildenbrand wrote:
Hi Ryan,
-static void tlb_batch_pages_flush(struct mmu_gather *tlb)
+static void __tlb_batch_free_encoded_pages(struct mmu_gather_batch *batch)
{
- struct mmu_gather_batch *batch;
-
- for (batch =
On 12/02/2024 10:11, David Hildenbrand wrote:
> Hi Ryan,
>
>>> -static void tlb_batch_pages_flush(struct mmu_gather *tlb)
>>> +static void __tlb_batch_free_encoded_pages(struct mmu_gather_batch *batch)
>>> {
>>> - struct mmu_gather_batch *batch;
>>> -
>>> - for (batch = >local; batch &&
Hi Ryan,
-static void tlb_batch_pages_flush(struct mmu_gather *tlb)
+static void __tlb_batch_free_encoded_pages(struct mmu_gather_batch *batch)
{
- struct mmu_gather_batch *batch;
-
- for (batch = >local; batch && batch->nr; batch = batch->next) {
- struct
On Mon, Feb 12, 2024 at 1:52 AM George Stark wrote:
> I haven't lose hope for the devm_mutex thing and keep pinging those guys
> from time to time.
I don't understand. According to v4 thread Christophe proposed on how
the patch should look like. What you need is to incorporate an updated
version
On 12/02/2024 08.56, Herve Codina wrote:
> The bitmap_onto() function translates one bitmap relative to another but
> no function are present to perform the reverse translation.
>
> Introduce bitmap_off() to fill this hole.
>
> Signed-off-by: Herve Codina
> ---
> include/linux/bitmap.h | 3
On 09/02/2024 22:15, David Hildenbrand wrote:
> Similar to how we optimized fork(), let's implement PTE batching when
> consecutive (present) PTEs map consecutive pages of the same large
> folio.
>
> Most infrastructure we need for batching (mmu gather, rmap) is already
> there. We only have to
On 09/02/2024 22:15, David Hildenbrand wrote:
> It's a pain that we have to handle cond_resched() in
> tlb_batch_pages_flush() manually and cannot simply handle it in
> release_pages() -- release_pages() can be called from atomic context.
> Well, in a perfect world we wouldn't have to make our
On 12.02.24 09:51, Ryan Roberts wrote:
On 09/02/2024 22:15, David Hildenbrand wrote:
Add __tlb_remove_folio_pages(), which will remove multiple consecutive
pages that belong to the same large folio, instead of only a single
page. We'll be using this function when optimizing unmapping/zapping of
On 09/02/2024 22:15, David Hildenbrand wrote:
> Add __tlb_remove_folio_pages(), which will remove multiple consecutive
> pages that belong to the same large folio, instead of only a single
> page. We'll be using this function when optimizing unmapping/zapping of
> large folios that are mapped by
On 09/02/2024 22:15, David Hildenbrand wrote:
> Let's prepare for further changes by factoring out processing of present
> PTEs.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Ryan Roberts
> ---
> mm/memory.c | 94 ++---
> 1 file changed, 53
Le 05/02/2024 à 06:36, Mahesh Salgaonkar a écrit :
> [Vous ne recevez pas souvent de courriers de mah...@linux.ibm.com. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
>
Hi all,
I duplicated patches in this series :(
My bad, I was mistaken in 'git format-patch'.
Can you consider only the "[PATCH v3 RESEND n/6]: xx" in this review.
The other patches ("RESEND PATCH v3") are the duplicated ones.
If ok I will send a clean v4 series.
Of course, if some
Add framer support in the fsl_qmc_hdlc driver in order to be able to
signal carrier changes to the network stack based on the framer status
Also use this framer to provide information related to the E1/T1 line
interface on IF_GET_IFACE and configure the line interface according to
IF_IFACE_{E1,T1}
QMC channels support runtime timeslots changes but nothing is done at
the QMC HDLC driver to handle these changes.
Use existing IFACE ioctl in order to configure the timeslots to use.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
---
Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
while some users may benefit out of it and being independent to NUMA
code.
Make it available to users by moving out of ifdeffery and exporting for
modules.
Signed-off-by: Herve Codina
---
lib/bitmap.c | 3 ++-
1 file
The QMC HDLC driver provides support for HDLC using the QMC (QUICC
Multichannel Controller) to transfer the HDLC data.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
---
drivers/net/wan/Kconfig| 12 +
drivers/net/wan/Makefile | 1 +
Add framer support in the fsl_qmc_hdlc driver in order to be able to
signal carrier changes to the network stack based on the framer status
Also use this framer to provide information related to the E1/T1 line
interface on IF_GET_IFACE and configure the line interface according to
IF_IFACE_{E1,T1}
The bitmap_onto() function translates one bitmap relative to another but
no function are present to perform the reverse translation.
Introduce bitmap_off() to fill this hole.
Signed-off-by: Herve Codina
---
include/linux/bitmap.h | 3 +++
lib/bitmap.c | 42
Hi,
Note: Resent this v3 series with missing maintainers added in CC.
This series introduces the QMC HDLC support.
Patches were previously sent as part of a full feature series and were
previously reviewed in that context:
"Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
The bitmap_onto() function translates one bitmap relative to another but
no function are present to perform the reverse translation.
Introduce bitmap_off() to fill this hole.
Signed-off-by: Herve Codina
---
include/linux/bitmap.h | 3 +++
lib/bitmap.c | 42
1 - 100 of 102 matches
Mail list logo
