with my
understanding based on the code. The description of pgmap_owner is good as
it's usage wasn't immediately clear on the first code read through. So feel
free to add:
Reviewed-by: Alistair Popple
> Jason
This fixed the problem I was having trying to issue istep operations to the
SBE.
Tested-by: Alistair Popple
On Monday, 21 January 2019 11:15:58 AM AEST Eddie James wrote:
> SBE fifo operations should be allowed while the SBE is in any of the
> "IPL" states. Operations should
-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 1c383f3..050bd5d 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
There is of_property_read_u32_index but no u64 variant. This patch
adds one similar to the u32 version for u64.
Signed-off-by: Alistair Popple
Acked-by: Rob Herring
---
drivers/of/base.c | 31 +++
include/linux/of.h | 3 +++
2 files changed, 34 insertions(+)
diff
when a device should stop issuing address translation
requests (ATRs). It also adds a fault handler to allow device drivers
to demand fault pages in.
Signed-off-by: Alistair Popple
---
Changes since v1:
- Moved exported function call prototypes to an externally accessable
header.
- Fixed
On Friday, 8 December 2017 6:41:02 PM AEDT Ivan Mikhaylov wrote:
> add irq error handlers for cmu, plb, opb, mcue, conf
> with debug information output in case of problems.
>
> Signed-off-by: Ivan Mikhaylov
Acked-by: Alistair Popple
> ---
> arch/powerpc/platforms
This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.
Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alis
Again, I'm not familiar with this specific hardware so can only provide general
comments.
On Thursday, 2 November 2017 4:07:05 PM AEDT Ivan Mikhaylov wrote:
> * tvsense(temperature and voltage sensors) may provide
> erratic sense values which may result in parity errors
> on CMU.
It would be
I'm not familiar with the hardware setup going on here so I can't comment on
it's correctness but the code looks ok. A commit message describing why this
particular setup is needed would be nice though.
Reviewed-by: Alistair Popple
On Thursday, 2 November 2017 4:07:04 PM AEDT
Hi Ivan,
Does it make sense to have these in a seperate include file? From what I could
see these defines were only used in fsp2.c so you could just put them directly
in there.
- Alistair
On Thursday, 2 November 2017 4:07:03 PM AEDT Ivan Mikhaylov wrote:
> * add cmu, plbX, l2 register definition
On Thursday, 2 November 2017 4:07:06 PM AEDT Ivan Mikhaylov wrote:
> * add irq error handlers for cmu, plb, opb, mcue, conf
> with debug information output in case of problem.
>
> Signed-off-by: Ivan Mikhaylov
> ---
> arch/powerpc/platforms/44x/fsp2.c | 204
>
Balbir,
> > + /* Update partition table control register on all Nest MMUs */
> > + opal_nmmu_set_ptcr(-1UL, __pa(partition_tb) | (PATB_SIZE_SHIFT - 12));
> > +
>
> Just wondering if
>
> 1. Instead of using -1 for all cpus, we should do
> for_each_online_cpu() {
> opal_
address of the partition table
(ie. the PTCR) which needs to be programmed into the NMMU.
This patch adds a call to OPAL to set the PTCR for the nest mmu in
opal_init().
Signed-off-by: Alistair Popple
---
This patch depends on a new OPAL call which has yet to be added to
skiboot, although the
unnecessary as it is no longer checked,
instead relying on pfn_valid() to determine if there is an associated
page or not.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/gma500/fbdev.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 5 ++---
drivers/s390/block/dcssblk.c | 3 +--
drivers
org
Cc: da...@redhat.com
Cc: linux-kernel@vger.kernel.org
Cc: nvd...@lists.linux.dev
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-e...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: jhubb...@nvidia.com
Cc: h...@lst.de
Alistair Popple (4):
mm: Remove PFN_MAP, PFN_SG
The PFN_MAP flag is no longer used for anything, so remove it. The
PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
also remove them.
Signed-off-by: Alistair Popple
---
include/linux/pfn_t.h | 10 ++
tools/testing/nvdimm/test/iomap.c | 4
2 files
None of the functionality in pfn_t.h is required so delete it.
Signed-off-by: Alistair Popple
---
include/linux/pfn.h | 10 +-
include/linux/pfn_t.h | 88 +
2 files changed, 98 deletions(-)
delete mode 100644 include/linux/pfn_t.h
diff --git a
All PFN_* pfn_t flags have been removed. Therefore there is no longer
a need for the pfn_t type and all uses can be replaced with normal
pfns.
Signed-off-by: Alistair Popple
---
I'm guessing people will want this split up into several patches for
merging/review. If so I will do that onc
On Thu, Apr 10, 2025 at 01:14:42PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed
> "WARNING:at_mm/truncate.c:#truncate_folio_batch_exceptionals" on:
>
> commit: bde708f1a65d025c45575bfe1e7bf7bdf7e71e87 ("fs/dax: always remove DAX
> page-cache entries when breaking
On Fri, Apr 11, 2025 at 10:37:17AM +0200, David Hildenbrand wrote:
> (adding CC list again, because I assume it was dropped by accident)
Whoops. Thanks.
> > > diff --git a/fs/dax.c b/fs/dax.c
> > > index af5045b0f476e..676303419e9e8 100644
> > > --- a/fs/dax.c
> > > +++ b/fs/dax.c
> > > @@ -396,6
pXd_devmap to skip DAX pages
continue to do so by adding explicit checks of the VMA instead.
Signed-off-by: Alistair Popple
---
fs/userfaultfd.c | 2 +-
mm/hmm.c | 2 +-
mm/userfaultfd.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
nel.org
Cc: nvd...@lists.linux.dev
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-e...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: jhubb...@nvidia.com
Cc: h...@lst.de
Cc: zhang.l...@gmail.com
Cc: de...@rivosinc.com
Cc: bj...@kernel.org
Cc: balb...@nvidia.com
Alistair Po
;t support pte_devmap
so those will continue to rely on pfn_valid() to determine if the page can
be mapped.
Signed-off-by: Alistair Popple
---
mm/hmm.c| 3 ---
mm/memory.c | 20 ++--
mm/vmscan.c | 2 +-
3 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/mm/hmm.c b/mm/h
Previously dax pages were skipped by the pagewalk code as pud_special() or
vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
refcounted normally that is no longer the case, so add explicit checks to
skip them.
Signed-off-by: Alistair Popple
---
include/linux/memremap.h
The PFN_MAP flag is no longer used for anything, so remove it. The
PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
also remove them.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
---
include/linux/pfn_t.h | 31 +++
mm
All PFN_* pfn_t flags have been removed. Therefore there is no longer
a need for the pfn_t type and all uses can be replaced with normal
pfns.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
---
arch/x86/mm/pat/memtype.c| 6 +-
drivers/dax/device.c
memmap so there is no need to hold a reference on the pgmap
data structure to ensure this.
Furthermore mappings with PFN_DEV are no longer created, hence this
effectively dead code anyway so can be removed.
Signed-off-by: Alistair Popple
---
include/linux/huge_mm.h | 3 +-
mm/gup.c
PFN_DEV no longer exists. This means no devmap PMDs or PUDs will be
created, so checking for them is redundant. Instead mappings of pages that
would have previously returned true for pXd_devmap() will return true for
pXd_trans_huge()
Signed-off-by: Alistair Popple
---
arch/powerpc/mm/book3s64
The only users of pmd_devmap were device dax and fs dax. The check for
pmd_devmap() in check_pmd_state() is therefore redundant as callers
explicitly check for is_zone_device_page(), so this check can be dropped.
Signed-off-by: Alistair Popple
---
mm/khugepaged.c | 2 --
1 file changed, 2
It's no longer used so remove it.
Signed-off-by: Alistair Popple
---
mm/memremap.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index d875534..e40672b 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -38,30 +38,6 @@ unsigned
Now that DAX and all other reference counts to ZONE_DEVICE pages are
managed normally there is no need for the special devmap PTE/PMD/PUD
page table bits. So drop all references to these, freeing up a
software defined page table bit on architectures supporting it.
Signed-off-by: Alistair Popple
behaviour as it will always be false.
Signed-off-by: Alistair Popple
---
fs/dax.c | 5 ++---
include/linux/huge_mm.h| 10 --
include/linux/pgtable.h| 2 +-
mm/hmm.c | 4 ++--
mm/huge_memory.c | 31 +--
mm
vmf_insert_mixed(). This is unnecessary as it is no longer checked, instead
relying on pfn_valid() to determine if there is an associated page or not.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/gma500/fbdev.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 5
On Thu, Feb 27, 2025 at 11:01:55AM +0100, Danilo Krummrich wrote:
> On Thu, Feb 27, 2025 at 11:25:55AM +1100, Alistair Popple wrote:
> > On Tue, Feb 25, 2025 at 12:04:35PM +0100, Danilo Krummrich wrote:
> > > On Tue, Feb 25, 2025 at 04:50:05PM +1100, Alistair Popple wrote:
On Thu, Dec 19, 2024 at 06:04:09PM +0100, Danilo Krummrich wrote:
> I/O memory is typically either mapped through direct calls to ioremap()
> or subsystem / bus specific ones such as pci_iomap().
>
> Even though subsystem / bus specific functions to map I/O memory are
> based on ioremap() / iounma
On Fri, Feb 21, 2025 at 04:58:59AM +0100, Miguel Ojeda wrote:
> Hi Alistair,
>
> On Fri, Feb 21, 2025 at 2:20 AM Alistair Popple wrote:
> >
> > Is this a known issue or limitation? Or is this a bug/rough edge that still
> > needs fixing? Or alternatively am I just d
On Tue, Feb 25, 2025 at 12:04:35PM +0100, Danilo Krummrich wrote:
> On Tue, Feb 25, 2025 at 04:50:05PM +1100, Alistair Popple wrote:
> > Kind of, but given the current state of build_assert's and the impossiblity
> > of
> > debugging them should we avoid adding th
On Tue, May 27, 2025 at 02:46:28PM -0700, Dan Williams wrote:
> Alistair Popple wrote:
> > Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning
> > entries") introduced a new function, wait_entry_unlocked_exclusive(),
> > which waits for
which is equivalent in
implementation to xas_pause() but does not advance the XArray state.
Fixes: 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries")
Signed-off-by: Alistair Popple
Cc: Dan Williams
Cc: Alison Schofield
Cc: Matthew Wilcow (Oracle)
Cc: Balb
On Tue, Jun 17, 2025 at 05:43:38PM +0200, David Hildenbrand wrote:
> Let's convert to vmf_insert_folio_pmd().
>
> In the unlikely case there is already something mapped, we'll now still
> call trace_dax_pmd_load_hole() and return VM_FAULT_NOPAGE.
>
> That should probably be fine, no need to add s
The PFN_MAP flag is no longer used for anything, so remove it.
The PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been
used so also remove them. The last user of PFN_SPECIAL was removed
by 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED
support").
Signed-off-by
On Tue, Jun 10, 2025 at 06:18:09PM +0200, Marek Szyprowski wrote:
> Dear All,
>
> On 04.06.2025 05:21, Alistair Popple wrote:
> > The PFN_MAP flag is no longer used for anything, so remove it.
> > The PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been
> > us
On Wed, Jun 11, 2025 at 02:06:52PM +0200, David Hildenbrand wrote:
> We setup the cache mode but ... don't forward the updated pgprot to
> insert_pfn_pud().
>
> Only a problem on x86-64 PAT when mapping PFNs using PUDs that
> require a special cachemode.
>
> Fix it by using the proper pgprot wher
> 12/13 ndctl:dax / dm.sh FAIL 0.23s exit
> status 1
> 13/13 ndctl:dax / mmap.sh OK 437.86s
>
> So, no idea if this series breaks something, because the tests are rather
> unreliable. I have plenty of other debug setting
On Wed, Jun 11, 2025 at 02:06:53PM +0200, David Hildenbrand wrote:
> Marking PMDs that map a "normal" refcounted folios as special is
> against our rules documented for vm_normal_page().
>
> Fortunately, there are not that many pmd_special() check that can be
> mislead, and most vm_normal_page_pmd
On Wed, Jun 11, 2025 at 10:42:16AM +0200, Marek Szyprowski wrote:
> On 11.06.2025 10:23, David Hildenbrand wrote:
> > On 11.06.25 10:03, Marek Szyprowski wrote:
> >> On 11.06.2025 04:38, Alistair Popple wrote:
> >>> On Tue, Jun 10, 2025 at 06:18:09PM +0200, Mar
On Fri, Jul 04, 2025 at 03:22:28PM +0200, David Hildenbrand wrote:
> On 25.06.25 11:03, David Hildenbrand wrote:
> > On 24.06.25 03:16, Alistair Popple wrote:
> > > On Tue, Jun 17, 2025 at 05:43:38PM +0200, David Hildenbrand wrote:
> > > > Let
whole struct down. It makes it very obvious what
elements insert_pmd() cares about (in this case one of about fourteen fields).
Anyway looks good, thanks:
Reviewed-by: Alistair Popple
> --
> Oscar Salvador
> SUSE Labs
On Tue, Jun 17, 2025 at 05:43:36PM +0200, David Hildenbrand wrote:
> Let's clean it all further up.
Looks good:
Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
> ---
> mm/huge_memory.c | 36 +---
> 1 file changed, 13 inserti
sonable to not handle huge zero folios differently
> to inserting PMDs mapping folios when there already is something mapped.
Yeah, this all sounds reasonable and I was never able to hit this path with the
RFC version of this series anyway. So I suspect it really is impossible to hit
and ther
201 - 250 of 250 matches
Mail list logo
