> On Mar 19, 2024, at 04:03, pet...@redhat.com wrote:
>
> From: Peter Xu
>
> Please refer to the previous patch on the reasoning for x86. Now sparc is
> the only architecture that will allow swap entries to be reported as
> pXd_huge(). After this patch, all architectures should forbid swap
On Tue, Mar 19, 2024 at 10:24 AM Shengjiu Wang wrote:
>
> On Mon, Mar 18, 2024 at 11:56 PM Hans Verkuil wrote:
> >
> > Hi Shengjiu,
> >
> > I was about to prepare a pull request for this when I realized that
> > entries for the new drivers need to be added to the MAINTAINERS file.
> >
> > Can
On Mon, Mar 18, 2024 at 11:56 PM Hans Verkuil wrote:
>
> Hi Shengjiu,
>
> I was about to prepare a pull request for this when I realized that
> entries for the new drivers need to be added to the MAINTAINERS file.
>
> Can you post patches 'v14 17/16' and 'v14/18/16' adding entries for each
> new
This updates the driver to gpiod API, and removes yet another use of
of_get_named_gpio().
Signed-off-by: Andy Shevchenko
---
v2: fixed compilation error
sound/soc/fsl/imx-es8328.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/imx-es8328.c
From: Peter Xu
There's one small section already, but since we're going to remove
pXd_huge(), that comment may start to obsolete.
Rewrite that section with more information, hopefully with that the API is
crystal clear on what it implies.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Peter Xu
From: Peter Xu
ARM/ARM64 used to define pmd_thp_or_huge(). Now this macro is completely
redundant. Remove it and use pmd_leaf().
Cc: Mark Salter
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Russell King
Cc: Shawn Guo
Cc: Krzysztof Kozlowski
Cc: Bjorn Andersson
Cc: Arnd Bergmann
Cc: Konrad
From: Peter Xu
This API is not used anymore, drop it for the whole tree.
Signed-off-by: Peter Xu
---
arch/arm/mm/Makefile | 1 -
arch/arm/mm/hugetlbpage.c | 29 ---
arch/arm64/mm/hugetlbpage.c | 10 ---
From: Peter Xu
Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(),
reuse it. Luckily, pXd_huge() isn't widely used.
Signed-off-by: Peter Xu
---
arch/arm/include/asm/pgtable-3level.h | 2 +-
arch/arm64/include/asm/pgtable.h | 2 +-
arch/arm64/mm/hugetlbpage.c
From: Peter Xu
Unlike most archs, aarch64 defines pXd_huge() and pXd_leaf() slightly
differently. Redefine the pXd_huge() with pXd_leaf().
There used to be two traps for old aarch64 definitions over these APIs that
I found when reading the code around, they're:
(1) 4797ec2dc83a ("arm64: fix
From: Peter Xu
Huge mapping checks in GUP are slightly redundant and can be simplified.
pXd_huge() now is the same as pXd_leaf(). pmd_trans_huge() and
pXd_devmap() should both imply pXd_leaf(). Time to merge them into one.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Peter Xu
---
mm/gup.c |
From: Peter Xu
PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
constantly returns 0 for hash MMUs. As Michael Ellerman pointed out [1],
it is safe to check _PAGE_PTE on hash MMUs, as the bit will never be set so
it will keep returning false.
As a reference,
From: Peter Xu
Most of the archs already define these two APIs the same way. ARM is more
complicated in two aspects:
- For pXd_huge() it's always checking against !PXD_TABLE_BIT, while for
pXd_leaf() it's always checking against PXD_TYPE_SECT.
- SECT/TABLE bits are defined differently
From: Peter Xu
It's already confusing that ARM 2-level v.s. 3-level defines SECT bit
differently on pmd/puds. Always use a macro which is much clearer.
Cc: Russell King
Cc: Shawn Guo
Cc: Krzysztof Kozlowski
Cc: Bjorn Andersson
Cc: Arnd Bergmann
Cc: Konrad Dybcio
Cc: Fabio Estevam
Cc:
From: Peter Xu
Please refer to the previous patch on the reasoning for x86. Now sparc is
the only architecture that will allow swap entries to be reported as
pXd_huge(). After this patch, all architectures should forbid swap entries
in pXd_huge().
Cc: David S. Miller
Cc: Andreas Larsson
Cc:
From: Peter Xu
This patch partly reverts below commits:
3a194f3f8ad0 ("mm/hugetlb: make pud_huge() and follow_huge_pud() aware of
non-present pud entry")
cbef8478bee5 ("mm/hugetlb: pmd_huge() returns true for non-present hugepage")
Right now, pXd_huge() definition across kernel is unclear. We
From: Peter Xu
Currently there should have no p4d swap entries so it may not matter much,
however this may help us to rule out swap entries in pXd_huge() API, which
will include p4d_huge(). The p4d_present() checks make it 100% clear that
we won't rely on p4d_huge() for swap entries.
From: Peter Xu
Add a variable to cache p4d in follow_p4d_mask(). It's a good practise to
make sure all the following checks will have a consistent view of the entry.
Signed-off-by: Peter Xu
---
mm/gup.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
From: Peter Xu
Swap pud entries do not always return true for pud_huge() for all archs.
x86 and sparc (so far) allow it, but all the rest do not accept a swap
entry to be reported as pud_huge(). So it's not safe to check swap entries
within pud_huge(). Check swap entries before pud_huge(), so
From: Peter Xu
[based on akpm/mm-unstable commit b66d4391d8fe, March 18th]
v2:
- Add a patch to cleanup ARM's pmd_thp_or_huge [Christophe]
- Enhance commit message for PowerPC patch on hugepd [Christophe]
v1: https://lore.kernel.org/r/20240313214719.253873-1-pet...@redhat.com
In previous work
On Mon, Mar 18, 2024 at 09:58:37PM +0200, Andy Shevchenko wrote:
> This updates the driver to gpiod API, and removes yet another use of
> of_get_named_gpio().
This won't compile, sorry for the noise. I'll send a v2.
--
With Best Regards,
Andy Shevchenko
This updates the driver to gpiod API, and removes yet another use of
of_get_named_gpio().
Signed-off-by: Andy Shevchenko
---
sound/soc/fsl/imx-es8328.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/imx-es8328.c b/sound/soc/fsl/imx-es8328.c
On Mon, Mar 18, 2024 at 10:50:49PM +1100, Michael Ellerman wrote:
> Michael Ellerman writes:
> > Michal Suchánek writes:
> >> Hello,
> >>
> >> I cannot load the wireguard module.
> >>
> >> Loading the module provides no diagnostic other than 'No such device'.
> >>
> >> Please provide maningful
On Thu, Mar 14, 2024 at 08:59:22AM -0400, Peter Xu wrote:
> > > --- a/mm/hmm.c
> > > +++ b/mm/hmm.c
> > > @@ -429,7 +429,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned
> > > long start, unsigned long end,
> > > return hmm_vma_walk_hole(start, end, -1, walk);
> > >
On Thu, Mar 14, 2024 at 01:11:59PM +, Christophe Leroy wrote:
>
>
> Le 14/03/2024 à 13:53, Peter Xu a écrit :
> > On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote:
> >>
> >>
> >> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> >>> From: Peter Xu
> >>>
> >>> PowerPC
Hi Shengjiu,
I was about to prepare a pull request for this when I realized that
entries for the new drivers need to be added to the MAINTAINERS file.
Can you post patches 'v14 17/16' and 'v14/18/16' adding entries for each
new driver?
Thank you,
Hans
On 11/03/2024 10:53 am, Shengjiu
Michael Ellerman writes:
> Breno Leitao writes:
>> On Tue, Mar 12, 2024 at 08:17:42AM +, Christophe Leroy wrote:
>>> +Nathan as this is RTAS related.
Thanks!
>>> Le 21/08/2018 à 20:42, Breno Leitao a écrit :
>>> > The rtas syscall reads a value from a user-provided structure and uses it
On 3/14/24 13:45, Tobias Huschle wrote:
> On Fri, Mar 08, 2024 at 03:11:38PM +, Luis Machado wrote:
>> On 2/28/24 16:10, Tobias Huschle wrote:
>>>
>>> Questions:
>>> 1. The kworker getting its negative lag occurs in the following scenario
>>>- kworker and a cgroup are supposed to execute
Since the current calculation of calc_nr_kernel_pages() has taken into
consideration of kernel reserved memory, no need to have
arch_reserved_kernel_pages() any more.
Signed-off-by: Baoquan He
---
arch/powerpc/include/asm/mmu.h | 4
arch/powerpc/kernel/fadump.c | 5 -
Nobody calls calc_memmap_size() now.
Signed-off-by: Baoquan He
---
mm/mm_init.c | 20
1 file changed, 20 deletions(-)
diff --git a/mm/mm_init.c b/mm/mm_init.c
index 55a2b886b7a6..9ed4b9e77c4a 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -1331,26 +1331,6 @@ static void
Currently, in free_area_init_core(), when initialize zone's field, a
rough value is set to zone->managed_pages. That value is calculated by
(zone->present_pages - memmap_pages).
In the meantime, add the value to nr_all_pages and nr_kernel_pages which
represent all free pages of system (only low
This is a preparation to calculate nr_kernel_pages and nr_all_pages,
both of which will be used later in alloc_large_system_hash().
nr_all_pages counts up all free but not reserved memory in memblock
allocator, including HIGHMEM memory. While nr_kernel_pages counts up
all free but not reserved
This is not needed any more.
Signed-off-by: Baoquan He
---
arch/x86/include/asm/pgtable.h | 1 -
arch/x86/kernel/setup.c| 2 --
arch/x86/mm/init.c | 45 --
3 files changed, 48 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h
Variable dma_reserve and its usage was introduced in commit 0e0b864e069c
("[PATCH] Account for memmap and optionally the kernel image as holes").
Its original purpose was to accounting for the reserved pages in DMA
zone to make DMA zone's watermarks calculation more accurate on x86.
However,
In function free_area_init_core(), the code calculating
zone->managed_pages and the subtracting dma_reserve from DMA zone looks
very confusing.
>From git history, the code calculating zone->managed_pages was for
zone->present_pages originally. The early rough assignment is for
optimize zone's pcp
Christophe Leroy writes:
> Le 29/02/2024 à 07:37, Michael Ellerman a écrit :
>> Stephen Rothwell writes:
>>> Hi all,
>>>
>>> Today's linux-next merge of the powerpc tree got a conflict in:
>>>
>>>arch/powerpc/mm/pgtable_32.c
>>>
>>> between commit:
>>>
>>>a5e8131a0329 ("arm64, powerpc,
Michael Ellerman writes:
> Michal Suchánek writes:
>> Hello,
>>
>> I cannot load the wireguard module.
>>
>> Loading the module provides no diagnostic other than 'No such device'.
>>
>> Please provide maningful diagnostics for loading software-only driver,
>> clearly there is no particular
> On 09-Mar-2024, at 11:13 PM, Segher Boessenkool
> wrote:
>
> All instructions with a primary opcode from 32 to 63 are memory insns,
> and no others. It's trivial to see whether it is a load or store, too
> (just bit 3 of the insn). Trying to parse disassembled code is much
> harder, and
> On 09-Mar-2024, at 3:18 PM, Christophe Leroy
> wrote:
>
>
>
> Le 09/03/2024 à 08:25, Athira Rajeev a écrit :
>> Add powerpc instruction nmemonic table to associate load/store
>> instructions with move_ops. mov_ops is used to identify mem_type
>> to associate instruction with data type
> On 09-Mar-2024, at 3:24 PM, Christophe Leroy
> wrote:
>
>
>
> Le 09/03/2024 à 08:25, Athira Rajeev a écrit :
>> The function get_dwarf_regnum() returns a DWARF register number
>> from a register name string. This calls arch specific function
>> get_arch_regnum to return register number
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller :
On Thu, 14 Mar 2024 13:33:46 +0100 you wrote:
> The fsl_qmc_driver does not compile as module:
> error: ‘qmc_hdlc_driver’ undeclared here (not in a function);
> 405 | MODULE_DEVICE_TABLE(of, qmc_hdlc_driver);
>
40 matches
Mail list logo
