Hi Marco,
> > > > Overall I think the idea of getting rid of these misc/ drivers is goes
> > > > into the right direction, but registering directly into NVMEM makes
> > > > more sense IMO.
> > >
> > > So you propose to have two places for the partition handling (one for
> > > MTD and one for
On 7/13/2024 4:12 PM, Thomas Gleixner wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Fri, Jul 12 2024 at 15:16, Vignesh Balasubramanian wrote:
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/
On 02/07/2024 14:26, Jocelyn Falempe wrote:
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new struct kmsg_dump_detail, that will hold the
reason and description, and pass it to the dump() callback.
To avoid updating all kmsg_dump() call, it ad
On Tue Jul 2, 2024 at 7:10 PM EEST, Rob Herring (Arm) wrote:
> The PPC64 specific MMIO setup open codes DT address functions rather
> than using standard address parsing functions. The open-coded version
> fails to handle any address translation and is not endian safe.
>
> I haven't found any evide
On Wed Jul 17, 2024 at 3:08 PM EEST, Jarkko Sakkinen wrote:
> On Tue Jul 2, 2024 at 7:10 PM EEST, Rob Herring (Arm) wrote:
> > The PPC64 specific MMIO setup open codes DT address functions rather
> > than using standard address parsing functions. The open-coded version
> > fails to handle any addre
From: Stewart Hildebrand
> Sent: 16 July 2024 20:33
>
> This series sets the default minimum resource alignment to 4k for memory
> BARs. In preparation, it makes an optimization and addresses some corner
> cases observed when reallocating BARs. I consider the prepapatory
> patches to be prerequisi
From: David Laight
> Sent: 17 July 2024 14:15
>
> From: Stewart Hildebrand
> > Sent: 16 July 2024 20:33
> >
> > This series sets the default minimum resource alignment to 4k for memory
> > BARs. In preparation, it makes an optimization and addresses some corner
> > cases observed when reallocating
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
sgi-ip27 is the only system that defines NODE_DATA() differently than
the rest of NUMA machines.
Add node_data array of struct pglist pointers that will point to
__node_data[node]->pglist and redefine NODE_DATA() to use
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Make definition of node_data match other architectures.
This will allow pulling declaration of node_data to the generic mm code in
the following commit.
Signed-off-by: Mike Rapoport (Microsoft)
---
Reviewed-by: David
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Every architecture that supports NUMA defines node_data in the same way:
struct pglist_data *node_data[MAX_NUMNODES];
No reason to keep multiple copies of this definition and its forward
declarations, especially
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
Signed-off-by: Mike Rapoport (Microsoft)
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On 16.07.24 13:13, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Architectures that support NUMA duplicate the code that allocates
NODE_DATA on the node-local memory with slight variations in reporting
of the addresses where the memory was allocated.
Use x86 version as the basis for t
On Wed, Jul 17, 2024 at 03:02:23PM +0530, Balasubrmanian, Vignesh wrote:
>
> On 7/13/2024 4:12 PM, Thomas Gleixner wrote:
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Fri, Jul 12 2024
On 7/17/24 09:15, David Laight wrote:
> From: Stewart Hildebrand
>> Sent: 16 July 2024 20:33
>>
>> This series sets the default minimum resource alignment to 4k for memory
>> BARs. In preparation, it makes an optimization and addresses some corner
>> cases observed when reallocating BARs. I conside
From: "Liam R. Howlett"
The arch_unmap call was previously moved above the rbtree modifications
in commit 5a28fc94c914 ("x86/mpx, mm/core: Fix recursive munmap()
corruption"). The move was motivated by an issue with calling
arch_unmap() after the rbtree was modified.
Since the above commit, mpx
On Wed, 17 Jul 2024 13:58:35 +1000
Michael Ellerman wrote:
> Masami Hiramatsu (Google) writes:
> > Hi Naveen,
> >
> > On Sun, 14 Jul 2024 14:04:23 +0530
> > Naveen N Rao wrote:
> >
> >> I have switched to using my @kernel.org id for my contributions. Update
> >> MAINTAINERS and mailmap to refle
This is an RFC series, so not yet for merging. Please don't be scared by
the code changes: most of them are code movements only.
This series is based on the dax mprotect fix series here (while that one is
based on mm-unstable):
[PATCH v3 0/8] mm/mprotect: Fix dax puds
https://lore.kernel.org
Introduce two more sub-options for PGTABLE_HAS_HUGE_LEAVES:
- PGTABLE_HAS_PMD_LEAVES: set when there can be PMD mappings
- PGTABLE_HAS_PUD_LEAVES: set when there can be PUD mappings
It will help to identify whether the current build may only want PMD
helpers but not PUD ones, as these sub-opt
It's always 0 for all archs, and there's no sign to even support p4d entry
in the near future. Remove it until it's needed for real.
Signed-off-by: Peter Xu
---
arch/arm64/include/asm/pgtable.h | 5 -
arch/powerpc/include/asm/book3s/64/pgtable.h | 5 -
arch/x86/include/asm/p
Make pmd/pud helpers to rely on the new PGTABLE_HAS_*_LEAVES option, rather
than THP alone, as THP is only one form of huge mapping.
Signed-off-by: Peter Xu
---
arch/arm64/include/asm/pgtable.h | 6 ++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
arch/powerpc/mm/book3s64/
Most of the huge mapping relevant helpers are declared in huge_mm.h, not
internal.h. Move the only few from internal.h into huge_mm.h.
Here to move pmd_needs_soft_dirty_wp() over, we'll also need to move
vma_soft_dirty_enabled() into mm.h as it'll be needed in two headers
later (internal.h, huge_
This patch converted all such checks into one *_leaf() check under common
mm/, as "thp+devmap" should compose everything for a *_leaf() for now. I
didn't yet touch arch code in other directories, as some arch may need some
special attention, so I left those separately.
It should start to save som
At some point, we need to decouple "huge mapping" with THP, for any non-THP
huge mappings in the future (hugetlb, pfnmap, etc..). This is the first
step towards it.
Or say, we already started to do this when PGTABLE_HAS_HUGE_LEAVES option
was introduced: that is the first thing Linux start to des
The of_property_for_each_u32() macro needs five parameters, two of which
are primarily meant as internal variables for the macro itself (in the
for() clause). Yet these two parameters are used by a few drivers, and this
can be considered misuse or at least bad practice.
Now that the kernel uses C1
On 7/2/2024 5:26 AM, Jocelyn Falempe wrote:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new struct kmsg_dump_detail, that will hold the
> reason and description, and pass it to the dump() callback.
>
> To avoid updating all kmsg_dump() cal
On 7/17/24 11:43 PM, Masami Hiramatsu (Google) wrote:
On Wed, 17 Jul 2024 13:58:35 +1000
Michael Ellerman wrote:
Masami Hiramatsu (Google) writes:
On Sun, 14 Jul 2024 14:04:23 +0530
Naveen N Rao wrote:
I have switched to using my @kernel.org id for my contributions. Update
MAINTAINERS and
Quoting Luca Ceresoli (2024-07-17 09:16:32)
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index 4ce83c5265b8..d4904f59f83f 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1175,8 +1175,8 @@ static int si5351_dt_parse(struct i2c_client *client,
>
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
MAINTAINERS
between commit:
c638b130e83e ("MAINTAINERS: Update powerpc BPF JIT maintainers")
from the bpf tree and commit:
e8061392ee09 ("MAINTAINERS: Update powerpc BPF JIT maintainers")
from the powerpc tree.
I
Hi all,
The following commit is also in the bpf tree as a different commit
(but the same patch):
358492fc426f ("MAINTAINERS: Update email address of Naveen")
This is commit
afcc8e1ef7bb ("MAINTAINERS: Update email address of Naveen")
in the bpf tree.
Note also that commit
e8061392ee09
llnoconfig clang-18
i386 allnoconfig gcc-13
i386 allyesconfig clang-18
i386 allyesconfig gcc-13
i386 buildonly-randconfig-001-20240717 clang-18
i386 buildonly-randconfig-001-20240718 g
ng-18
i386 allnoconfig gcc-13
i386 allyesconfig clang-18
i386 allyesconfig gcc-13
i386 buildonly-randconfig-001-20240717 clang-18
i386 buildonly-randconfig-001-20240718 gcc-11
i386 buildonly-randconfig-002-2024
On 2024/7/16 16:33, Masahiro Yamada wrote:
On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian wrote:
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not be removed. Besides,
due to lacking of size for kallsyms, kernel compute function siz
On 7/16/24 5:22 PM, Gautam Menghani wrote:
Refactor HFSCR emulation for KVM guests when they exit out with
H_FAC_UNAVAIL to use a switch case instead of checking all "cause"
values, since the "cause" values are mutually exclusive; and this is
better expressed with a switch case.
Signed-off-by:
Stephen Rothwell writes:
> Hi all,
>
> The following commit is also in the bpf tree as a different commit
> (but the same patch):
>
> 358492fc426f ("MAINTAINERS: Update email address of Naveen")
>
> This is commit
>
> afcc8e1ef7bb ("MAINTAINERS: Update email address of Naveen")
>
> in the bpf
Hello,
On Sat, Jul 13, 2024 at 10:25:26PM +0530, Athira Rajeev wrote:
> There are cases where define a global register variable and associate it
> with a specified register. Example, in powerpc, two registers are
> defined to represent variable:
> 1. r13: represents local_paca
> register struct pa
On Sat, Jul 13, 2024 at 10:25:27PM +0530, Athira Rajeev wrote:
> In case of register defined variable (found using
> find_data_type_global_reg), if the type of variable happens to be base
> type (example, long unsigned int), perf report captures it as:
>
> 12.85% long unsigned int long unsig
Hello,
On Sat, Jul 13, 2024 at 10:25:11PM +0530, Athira Rajeev wrote:
> The patchset from Namhyung added support for data type profiling
> in perf tool. This enabled support to associate PMU samples to data
> types they refer using DWARF debug information. With the upstream
> perf, currently it po
> On 18 Jul 2024, at 11:04 AM, Namhyung Kim wrote:
>
> Hello,
>
> On Sat, Jul 13, 2024 at 10:25:11PM +0530, Athira Rajeev wrote:
>> The patchset from Namhyung added support for data type profiling
>> in perf tool. This enabled support to associate PMU samples to data
>> types they refer using
On Wed, Jul 17, 2024 at 11:12 PM Athira Rajeev
wrote:
>
>
>
> > On 18 Jul 2024, at 11:04 AM, Namhyung Kim wrote:
> >
> > Hello,
> >
> > On Sat, Jul 13, 2024 at 10:25:11PM +0530, Athira Rajeev wrote:
> >> The patchset from Namhyung added support for data type profiling
> >> in perf tool. This enab
39 matches
Mail list logo
