On 2021/4/6 19:14, Niklas Schnelle wrote:
> and move the have_mio variable out of the PCI only code or use a raw
> "#ifdef CONFIG_PCI". Obviously we don't have any actual users of
> ioremap() that don't depend on CONFIG_PCI but it would make it so that
> iore
gt; - * In a SEV guest, NONE and RESERVED should not be mapped encrypted because
>>> - * there the whole memory is already encrypted.
>>> + * In a SEV or TDX guest, NONE and RESERVED should not be mapped encrypted
>>> (or
>>> + * private in TDX case) because there
On Thu, Apr 01, 2021 at 01:26:23PM -0700, Dave Hansen wrote:
> On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> > From: "Kirill A. Shutemov"
> >
> > All ioremap()ed paged that are not backed by normal memory (NONE or
> > RESERVED) have to be
On Thu, 2021-04-01 at 20:46 +0800, Bixuan Cui wrote:
> The ioremap/iounmap is implemented in arch/s390/pci/pci.c.
> While CONFIG_PCI is disabled,the compilation error is reported:
> s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
> cistpl.c:(.text+
This documents the newly introduced ioremap_np() along with all the
other common ioremap() variants, and some higher-level abstractions
available.
Reviewed-by: Linus Walleij
Signed-off-by: Hector Martin
---
Documentation/driver-api/device-io.rst | 218 +
1 file changed
ARM64 currently defaults to posted MMIO (nGnRE), but some devices
require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap()
variant to handle this case. ioremap_np() returns NULL on arches that
do not implement this variant.
sparc64 is the only architecture that needs to be touched
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> From: "Kirill A. Shutemov"
>
> All ioremap()ed paged that are not backed by normal memory (NONE or
> RESERVED) have to be mapped as shared.
s/paged/pages/
> +/* Make the page accesable by VMM */
> +#define pgpr
The ioremap/iounmap is implemented in arch/s390/pci/pci.c.
While CONFIG_PCI is disabled,the compilation error is reported:
s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
cistpl.c:(.text+0x32a): undefined reference to `ioremap'
s390x-linux-gnu-ld
it
> > > > + * requests stronger semantics than regular ioremap(). Portable drivers
> > > > + * should instead use one of the higher-level abstractions, like
> > > > + * devm_ioremap_resource(), to choose the correct variant for any given
> > >
On 25/03/2021 04.09, Arnd Bergmann wrote:
On Wed, Mar 24, 2021 at 7:12 PM Will Deacon wrote:
+/*
+ * ioremap_np needs an explicit architecture implementation, as it
+ * requests stronger semantics than regular ioremap(). Portable drivers
+ * should instead use one of the higher-level
On Wed, Mar 24, 2021 at 7:12 PM Will Deacon wrote:
>
> > +/*
> > + * ioremap_np needs an explicit architecture implementation, as it
> > + * requests stronger semantics than regular ioremap(). Portable drivers
> > + * should instead use one of the high
On Fri, Mar 05, 2021 at 06:38:43AM +0900, Hector Martin wrote:
> ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
> require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
> variant to handle this case. ioremap_np() is aliased to ioremap() by
> defau
ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "ioremap" [drivers/pcmcia/pcmcia.ko] undefined!
>> ERROR: modpost: "iounma
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Reviewed-by: Miaohe Lin
Reviewed-by: Christoph Hellwig
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 d
ioremap() variants, and some higher-level abstractions
available.
Signed-off-by: Hector Martin
I like this, I just want one change:
Put the common ioremap() on top in all paragraphs, so the norm
comes before the exceptions.
I.e. it is weird to mention ioremap_np() before mentioning ioremap().
+1
On Thu, 04 Mar 2021 21:38:43 +,
Hector Martin wrote:
>
> ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
> require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
> variant to handle this case. ioremap_np() is aliased to ioremap() by
> default
On Fri, Mar 5, 2021 at 4:09 PM Andy Shevchenko
wrote:
> On Fri, Mar 5, 2021 at 12:25 PM Linus Walleij
> wrote:
> > On Thu, Mar 4, 2021 at 10:40 PM Hector Martin wrote:
> >
> > > This documents the newly introduced ioremap_np() along with all the
> > > other
On 05/03/2021 23.45, Andy Shevchenko wrote:
On Thu, Mar 4, 2021 at 11:40 PM Hector Martin wrote:
ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
variant to handle this case. ioremap_np() is aliased to
On Fri, Mar 5, 2021 at 12:25 PM Linus Walleij wrote:
> On Thu, Mar 4, 2021 at 10:40 PM Hector Martin wrote:
>
> > This documents the newly introduced ioremap_np() along with all the
> > other common ioremap() variants, and some higher-level abstractions
> > availabl
On Thu, Mar 4, 2021 at 11:40 PM Hector Martin wrote:
>
> ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
> require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
> variant to handle this case. ioremap_np() is aliased to ioremap() by
> default on
On Thu, Mar 4, 2021 at 10:40 PM Hector Martin wrote:
> This documents the newly introduced ioremap_np() along with all the
> other common ioremap() variants, and some higher-level abstractions
> available.
>
> Signed-off-by: Hector Martin
I like this, I just want one change:
ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
variant to handle this case. ioremap_np() is aliased to ioremap() by
default on arches that do not implement this variant.
sparc64 is the only architecture that
This documents the newly introduced ioremap_np() along with all the
other common ioremap() variants, and some higher-level abstractions
available.
Signed-off-by: Hector Martin
---
Documentation/driver-api/device-io.rst | 218 +
1 file changed, 218 insertions(+)
diff
Like volatile, the kernel primitives which make concurrent
access to data safe (spinlocks, mutexes, memory barriers,
etc.) are designed to prevent unwanted optimization.
If they are being used properly, there will be no need to
use volatile as well. If volatile is still necessary,
there is almost
On 16/02/2021 19.53, Christoph Hellwig wrote:
Your new iomremap variant needs proper documentation explaining the
semantics in detail.
What's the right place for this? I haven't found any generic ioremap
documentation page in the tree yet. I suppose I could write an
ARM64-specifi
Your new iomremap variant needs proper documentation explaining the
semantics in detail.
ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
variant to handle this case. ioremap_np() is aliased to ioremap() by
default on arches that do not implement this variant.
This adds the
:
>
> 1. Something similar to the current hacky patch (which isn't really
> intended as a real solution...); change ioremap to default to nGnRnE
> using some kind of platform-level flag in the DT, then figure out how to
> get the PCI drivers to bypass that. This requires chang
Solutions discussed in this thread and elsewhere include:
1. Something similar to the current hacky patch (which isn't really
intended as a real solution...); change ioremap to default to nGnRnE
using some kind of platform-level flag in the DT, then figure out how to
get the PCI drivers
On 09/02/2021 18.15, Arnd Bergmann wrote:
Right, these are the same ranges that I found in the adt and that Mark
listed in his code snippet, so it seems we all see the same partitioning
of the address space. I also see them reflected in the
/defaults/pmap-io-ranges property in ADT, which seems to
> From: Arnd Bergmann
> Date: Tue, 9 Feb 2021 10:15:31 +0100
>
> On Tue, Feb 9, 2021 at 1:25 AM Hector Martin wrote:
> > On 09/02/2021 08.20, Mark Kettenis wrote:
> > I probed writing to i<<28 for i = [0..255], using nGnRE. This reveals
> > that nGnRE writes are allowed (i.e. either succeed or e
On 09/02/2021 08.20, Mark Kettenis wrote:
It is only PCI mmio space that needs to be nGnRE. The PCI host
controller register space itself needs nGnRnE just like all other
integrated peripherals (or at least it works that way).
This is correct. Actually, as I just discovered, nGnRE writes to MM
> From: Arnd Bergmann
> Date: Mon, 8 Feb 2021 23:57:20 +0100
>
> On Thu, Feb 4, 2021 at 9:39 PM Hector Martin wrote:
>
> > (3) Do it at a lower level, in ioremap() itself. This requires that
> > ioremap() somehow discriminates based on address range to pick what
From: "Kirill A. Shutemov"
All ioremap()ed paged that are not backed by normal memory (NONE or
RESERVED) have to be mapped as shared.
Reuse the infrastructure we have for AMD SEV.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "ioremap" [drivers/pcmcia/pcmcia.ko] undefined!
>> ERROR: modpost: "iounma
e any fabric configuration or other bit we
can flip to make the problem go away.
As an additional confounding factor, reportedly PCIe MMIO BAR mappings
conversely *do* need to use nGnRE to work properly. So we can't even get
away with a single ioremap setting, but need to discriminate based o
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Reviewed-by: Miaohe Lin
Reviewed-by: Christoph Hellwig
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 d
Hi,
> On Fri, 29 Jan 2021 17:01:35 +0100
> Gregory CLEMENT wrote:
>
>> Could you sent me the patch I don't have it in my emails boxes.
>
> https://lore.kernel.org/lkml/20201112032149.21906-1-chris.pack...@alliedtelesis.co.nz/raw
Applied on mvebu/arm
Thanks,
Gregory
>
> Thomas
> --
> Thomas
On Fri, 29 Jan 2021 17:01:35 +0100
Gregory CLEMENT wrote:
> Could you sent me the patch I don't have it in my emails boxes.
https://lore.kernel.org/lkml/20201112032149.21906-1-chris.pack...@alliedtelesis.co.nz/raw
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
h
Hi:
On 2021/1/26 12:45, Nicholas Piggin wrote:
> This will be used as a generic kernel virtual mapping function, so
> re-name it in preparation.
>
Looks good to me. Thanks.
Reviewed-by: Miaohe Lin
> Signed-off-by: Nicholas Piggin
> ---
> mm/ioremap.c | 64 +++-
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
Looks good,
Reviewed-by: Christoph Hellwig
vers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on
> >> line 1106 and execution via conditional on line
> >>
> >> It took some staring but I don't think there is a problem because the
> >> file global `mbus_state` is passed mvebu_mbus_co
Hi All,
On 12/11/20 9:02 pm, Thomas Petazzoni wrote:
> On Thu, 12 Nov 2020 16:21:49 +1300
> Chris Packham wrote:
>
>> make coccicheck complains:
>>
>>./drivers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on
>> line 1106 and execution via condi
Excerpts from Christoph Hellwig's message of January 24, 2021 9:36 pm:
> On Sun, Jan 24, 2021 at 06:22:22PM +1000, Nicholas Piggin wrote:
>> This will be used as a generic kernel virtual mapping function, so
>> re-name it in preparation.
>
> The new name looks ok, but shouldn't it also move to vma
On Sun, Jan 24, 2021 at 06:22:22PM +1000, Nicholas Piggin wrote:
> This will be used as a generic kernel virtual mapping function, so
> re-name it in preparation.
The new name looks ok, but shouldn't it also move to vmalloc.c with
the more generic name and purpose?
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
We don't need to print an error message when these ioremap operations
fail. The function that returns an error already prints an error message
and properly attributes it to the device. Drop them to save some code.
Cc: V Sujith Kumar Reddy
Cc: Srinivasa Rao
Cc: Srinivas Kandagatla
Cc: Che
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
On Wed 04 Nov 01:03 CST 2020, Sibi Sankar wrote:
> Fix the sparse warnings reported by the kernel test bot by replacing
> ioremap calls with memremap.
>
> Reported-by: kernel test robot
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Sibi Sankar
> ---
>
On Fri, Nov 13, 2020 at 09:53:25AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> here comes a patch set that implements the suggestion in the previous
> mail so we have something to discuss about.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (2):
> base: Rename devm_ioremap_resource to make the i
Hello,
here comes a patch set that implements the suggestion in the previous
mail so we have something to discuss about.
Best regards
Uwe
Uwe Kleine-König (2):
base: Rename devm_ioremap_resource to make the implicit request_mem
explicit
platform: Rename devm_platform_ioremap_resource to
On Thu, 12 Nov 2020 16:21:49 +1300
Chris Packham wrote:
> make coccicheck complains:
>
> ./drivers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on
> line 1106 and execution via conditional on line
>
> It took some staring but I don't think there i
make coccicheck complains:
./drivers/bus/mvebu-mbus.c:1113:2-8: ERROR: missing iounmap; ioremap on line
1106 and execution via conditional on line
It took some staring but I don't think there is a problem because the
file global `mbus_state` is passed mvebu_mbus_common_init() a
Fix the sparse warnings reported by the kernel test bot by replacing
ioremap calls with memremap.
Reported-by: kernel test robot
Signed-off-by: Sibi Sankar
---
I'll send out the patches to convert ioremap to memremap on other
qc remoteproc drivers once I get a chance to test them.
dr
From: Lorenzo Pieralisi
Date: Fri, 2 Oct 2020 15:50:29 +0100
> On Tue, Sep 15, 2020 at 01:11:21PM -0700, David Miller wrote:
>> From: Lorenzo Pieralisi
>> Date: Tue, 15 Sep 2020 10:32:02 +0100
>>
>> > Move the ioremap/iounmap declaration before asm-generic/io.h
On Tue, Sep 15, 2020 at 01:11:21PM -0700, David Miller wrote:
> From: Lorenzo Pieralisi
> Date: Tue, 15 Sep 2020 10:32:02 +0100
>
> > Move the ioremap/iounmap declaration before asm-generic/io.h is
> > included so that it is visible within it.
> >
> >
xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_r
xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_r
xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_r
xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_r
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Palmer Dabbelt
Signed-off-by: Palmer Dabbelt
Move the ioremap/iounmap declaration before asm-generic/io.h is
included so that it is visible within it.
Signed-off-by: Lorenzo Pieralisi
Cc: "David S. Miller"
---
arch/sparc/include/asm/io_32.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/
#define memcpy_toio(d,s,sz) _memcpy_toio(d,s,sz)
>
> +#ifdef __KERNEL__
> +
> +/*
> + * Bus number may be embedded in the higher bits of the physical address.
> + * This is why we have no bus number argument to ioremap().
> + */
> +void __iomem *ioremap(phys_addr_t o
32.h
> > @@ -11,6 +11,16 @@
> > #define memcpy_fromio(d,s,sz) _memcpy_fromio(d,s,sz)
> > #define memcpy_toio(d,s,sz) _memcpy_toio(d,s,sz)
> >
> > +#ifdef __KERNEL__
> > +
> > +/*
> > + * Bus number may be embedded in the higher bits of the physica
From: Lorenzo Pieralisi
Date: Tue, 15 Sep 2020 10:32:02 +0100
> Move the ioremap/iounmap declaration before asm-generic/io.h is
> included so that it is visible within it.
>
> Signed-off-by: Lorenzo Pieralisi
Acked-by: David S. Miller
Move the ioremap/iounmap declaration before asm-generic/io.h is
included so that it is visible within it.
Signed-off-by: Lorenzo Pieralisi
Cc: "David S. Miller"
---
arch/sparc/include/asm/io_32.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/
On 7/13/20 10:05 AM, Evgeny Novikov wrote:
> smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
> patch fixes that exactly like for case 0x710/2.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Evgeny Novikov
Applie
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Palmer Dabbelt
---
arch/riscv/Kconfig
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
ind
On Fri, Aug 21, 2020 at 02:44:23PM +1000, Nicholas Piggin wrote:
> This will be moved to mm/ and used as a generic kernel virtual mapping
> function, so re-name it in preparation.
>
> Signed-off-by: Nicholas Piggin
> ---
> mm/ioremap.c | 55 ++--
>
This will be moved to mm/ and used as a generic kernel virtual mapping
function, so re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 55 ++--
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/mm/ioremap.c b
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Palmer Dabbelt
---
arch/riscv/Kconfig
This will be moved to mm/ and used as a generic kernel virtual mapping
function, so re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 55 ++--
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/mm/ioremap.c b
On Wed, 12 Aug 2020 16:47:51 PDT (-0700), Atish Patra wrote:
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig
: Ingo Molnar
CommitterDate: Sat, 15 Aug 2020 13:56:16 +02:00
x86/mm/64: Do not sync vmalloc/ioremap mappings
Remove the code to sync the vmalloc and ioremap ranges for x86-64. The
page-table pages are all pre-allocated so that synchronization is
no longer necessary.
This is a patch that
From: Joerg Roedel
Hi,
as discussed here are the updates to the recent patches and fixes to
pre-allocate the vmalloc/ioremap second-level page-table pages on
x86-64.
Patch one is a re-send of
commit 8bb9bf242d1f ("x86/mm/64: Do not sync vmalloc/ioremap mappings")
From: Joerg Roedel
Remove the code to sync the vmalloc and ioremap ranges for x86-64. The
page-table pages are all pre-allocated so that synchronization is
no longer necessary.
This is a patch that already went into the kernel as:
commit 8bb9bf242d1f ("x86/mm/64: Do not sync vm
On Thu, Aug 13, 2020 at 5:18 AM Atish Patra wrote:
>
> UEFI uses early IO or memory mappings for runtime services before
> normal ioremap() is usable. Add the necessary fixmap bindings and
> pmd mappings for generic ioremap support to work.
>
> Signed-off-by: Atish Patra
&
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/Kbuild | 1
This will be moved to mm/ and used as a generic kernel virtual mapping
function, so re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 55 ++--
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/mm/ioremap.c b
: Ingo Molnar
CommitterDate: Thu, 06 Aug 2020 15:11:03 +02:00
Revert "x86/mm/64: Do not sync vmalloc/ioremap mappings"
This reverts commit 8bb9bf242d1fee925636353807c511d54fde8986.
Jason reported that this causes a new oops in process_one_work(),
and bisected it to this comm
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/Kbuild | 1
: Ingo Molnar
CommitterDate: Mon, 27 Jul 2020 12:32:29 +02:00
x86/mm/64: Do not sync vmalloc/ioremap mappings
Remove the code to sync the vmalloc and ioremap ranges for x86-64. The
page-table pages are all pre-allocated now so that synchronization is
no longer necessary.
Signed-off-by: Joerg
* Joerg Roedel wrote:
> From: Joerg Roedel
>
> Hi,
>
> here is the third version of the patches to pre-allocate P4D/PUD pages
> for the vmalloc/ioremap areas on x86-64. This makes the page-table
> synchronization code obsolete and so it is also removed.
>
>
stubs for
> devm_platform_ioremap_resource() and its dependencies to build, we can
> remove the HAS_IOMEM requirement here, rather than playing whack-a-mole
> with different drivers which don't try to build against ARCH=um.
>
> The reason this works at the moment is that stub ioremap and iounmap
>
nt stubs for
> devm_platform_ioremap_resource() and its dependencies to build, we can
> remove the HAS_IOMEM requirement here, rather than playing whack-a-mole
> with different drivers which don't try to build against ARCH=um.
>
> The reason this works at the moment is that stub ioremap and iounmap
> fun
On Tue, Jul 21, 2020 at 11:59:50AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Hi,
>
> here is the third version of the patches to pre-allocate P4D/PUD pages
> for the vmalloc/ioremap areas on x86-64. This makes the page-table
> synchronization code obsolete and
From: Joerg Roedel
Hi,
here is the third version of the patches to pre-allocate P4D/PUD pages
for the vmalloc/ioremap areas on x86-64. This makes the page-table
synchronization code obsolete and so it is also removed.
Please review.
Thanks,
Joerg
Changes to v2:
- Rebased to
From: Joerg Roedel
Remove the code to sync the vmalloc and ioremap ranges for x86-64. The
page-table pages are all pre-allocated now so that synchronization is
no longer necessary.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/pgtable_64_types.h | 2 --
arch/x86/mm/init_64.c
HAS_IOMEM requirement here, rather than playing whack-a-mole
with different drivers which don't try to build against ARCH=um.
The reason this works at the moment is that stub ioremap and iounmap
functions were added to UML to support this sort-of thing[3]. This
particular change doesn't requ
On Mon, Jul 20, 2020 at 10:53:26AM -0400, Rich Felker wrote:
> On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Christoph!
> >
> > On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> > >> H
On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> >> Hello!
> >>
> >> I have applied Christoph's full series on top of Linus' t
Hi Christoph!
On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
>> Hello!
>>
>> I have applied Christoph's full series on top of Linus' tree and I can
>> confirm that
>> the kernel boots fine on my SH-7785LCR board.
>>
>> Thu
On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I have applied Christoph's full series on top of Linus' tree and I can
> confirm that
> the kernel boots fine on my SH-7785LCR board.
>
> Thus, for the whole series of patches:
>
> Tested-by: John Paul Adria
ioremap smmu mmio region before calling into implementation init.
This is necessary to allow mapped address available during vendor
specific implementation init.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry
UEFI uses early IO or memory mappings for runtime services before
normal ioremap() is usable. Add the necessary fixmap bindings and
pmd mappings for generic ioremap support to work.
Signed-off-by: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/Kbuild | 1
On 7/16/20 9:28 PM, Peter Zijlstra wrote:
> For some reason I had a whole bunch of junk left in my checkout and had
> to basically: rm `git status -s | awk '{print $2}'`.
>
> Sorry for the noise.
>
> OK, let me go try my own patches :-)
FWIW, I just successfully built the "defconfig" configurati
1 - 100 of 1104 matches
Mail list logo
