The mhp_restrictions struct really doesn't specify anything resembling
a restriction anymore so rename it to be mhp_modifiers.
Signed-off-by: Logan Gunthorpe
---
arch/arm64/mm/mmu.c| 4 ++--
arch/ia64/mm/init.c| 4 ++--
arch/powerpc/mm/mem.c | 4 ++--
: Christoph Hellwig
Cc: Jason Gunthorpe
Signed-off-by: Logan Gunthorpe
---
mm/memremap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/memremap.c b/mm/memremap.c
index 45ab4ef0643d..d36ff688b768 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -187,7 +187,10 @@ void *memremap_pages(struct
bles explicitly
using _set_memory_prot() (seeing they are already mapped). For sh, reject
anything but PAGE_KERNEL settings -- this should be fine, for now, seeing
sh doesn't support ZONE_DEVICE anyway.
Cc: Dan Williams
Cc: David Hildenbrand
Cc: Michal Hocko
Signed-off-by: Logan Gunthorpe
On 2019-12-10 4:25 a.m., David Hildenbrand wrote:
> On 10.12.19 11:34, Michal Hocko wrote:
>> On Tue 10-12-19 11:09:46, David Hildenbrand wrote:
>>> On 10.12.19 11:04, Michal Hocko wrote:
>>>> On Mon 09-12-19 12:43:40, Dan Williams wrote:
>>>>> On
On 2019-12-09 2:00 p.m., Dan Williams wrote:
Can we fiddle that into "struct mhp_restrictions" instead?
>>>
>>> Yes, if that's what people want, it's pretty trivial to do. I chose not
>>> to do it that way because it doesn't get passed down to add_pages() and
>>> it's not really a "restrict
On 2019-12-09 1:41 p.m., Michal Hocko wrote:
> On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
>>
>>
>> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
>>> On 09.12.19 20:13, Logan Gunthorpe wrote:
>>>> devm_memremap_pages() is currently used by
On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> On 09.12.19 20:13, Logan Gunthorpe wrote:
>> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
>> struct page mappings for IO memory. At present, these mappings are created
>> with PAGE_KERNEL whic
In prepartion to support a pgprot_t argument for arch_add_memory().
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Signed-off-by: Logan Gunthorpe
---
arch/powerpc/include/asm/book3s/64/hash.h | 3 ++-
arch/powerpc/include/asm/book3s/64/radix.h | 3 ++-
arch/powerpc
in"
Cc: x...@kernel.org
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Signed-off-by: Logan Gunthorpe
---
arch/x86/include/asm/page_types.h | 3 ---
arch/x86/include/asm/pgtable.h| 3 +++
arch/x86/kernel/amd_gart_64.c | 3 ++-
arch/x86/mm/init.c| 9 +
arch
bles explicitly
using _set_memory_prot() (seeing they are already mapped). For sh, reject
anything but PAGE_KERNEL settings -- this should be fine, for now, seeing
sh doesn't support ZONE_DEVICE anyway.
Cc: Dan Williams
Cc: David Hildenbrand
Cc: Michal Hocko
Signed-off-by: Logan Gunthorpe
For use in the 32bit arch_add_memory() to set the pgprot type of the
memory to add.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Signed-off-by: Logan Gunthorpe
---
arch/x
will
not support P2PDMA memory until the work for this is done.
Thanks,
Logan
--
Logan Gunthorpe (6):
x86/mm: Thread pgprot_t through init_memory_mapping()
x86/mm: Introduce _set_memory_prot()
powerpc/mm: Thread pgprot_t through create_section_mapping()
s390/mm: Thread pgprot_t th
In prepartion to support a pgprot_t argument for arch_add_memory().
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Signed-off-by: Logan Gunthorpe
---
arch/s390/include/asm/pgtable.h | 3 ++-
arch/s390/mm/extmem.c | 3 ++-
arch/s390/mm/init.c | 2
: Christoph Hellwig
Cc: Jason Gunthorpe
Signed-off-by: Logan Gunthorpe
---
mm/memremap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/memremap.c b/mm/memremap.c
index 4edcca074e15..ced32593e4a7 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -187,7 +187,10 @@ void *memremap_pages(struct
On 15/11/18 03:05 AM, Alexander Fomichev wrote:
> This issue makes functions dma_set_mask() and dma_set_coherent_mask() and
> dma_alloc_coherent() fail in ntb_hw_switchtec. And the driver can't start on
> powerpc.
I don't know a lot about powerpc in this area, but a quick peek shows
that dma_
On 6/26/2017 2:43 PM, Arnd Bergmann wrote:
This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.
I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the s
Hi Jyri,
Thanks for the ack. However, I'm reworking this patch set to use the
include/linux/io-64-nonatomic* headers which will explicitly devolve
into two 32-bit transfers. It's not clear whether this is appropriate
for the tilcdc driver as it was never setup to use 32-bit transfers
(unlike the o
Thanks Horia.
I'm inclined to just use your patch verbatim. I can set you as author,
but no matter how I do it, I'll need your Signed-off-by.
Logan
On 23/06/17 12:51 AM, Horia Geantă wrote:
> On 6/22/2017 7:49 PM, Logan Gunthorpe wrote:
>> Now that ioread64 and iowrite64 are
On 6/22/2017 3:03 PM, Arnd Bergmann wrote:
Drivers that want a non-atomic variant should include either
include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h
depending on what they need. Drivers that require 64-bit I/O should
probably just depend on CONFIG_64BIT and maybe
On 6/22/2017 2:36 PM, Alan Cox wrote:
I think that makes sense for the platforms with that problem. I'm not
sure there are many that can't do it for mmio at least. 486SX can't do it
and I guess some ARM32 but I think almost everyone else can including
most 32bit x86.
What's more of a problem is
On 6/22/2017 2:14 PM, Alan Cox wrote:
If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.
Yes, I understand that.
The thing is that every user that's currently
On 6/22/2017 2:08 PM, Alan Cox wrote:
But this does not do the same thing as an ioread64 with regards to
atomicity or side effects on the device. The same is true of the other
hacks. You either have a real 64bit single read/write from MMIO space or
you don't. You can't fake it.
Yes, I know. But
On 6/22/2017 11:29 AM, Stephen Bates wrote:
+#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
Logan, thanks for taking this cleanup on. I think this should be iowrite64 not
iowrite32?
Yup, good catch. Thanks. I'll fix it in a v2 of this series.
Logan
This is a prep patch for adding a universal iowrite64.
The patch is to prevent compiler warnings when we add iowrite64 that
would occur because there is an unnecessary volatile in this driver.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu
Now that ioread64 and iowrite64 are always available we don't
need the ugly ifdefs to change their implementation when they
are not.
Signed-off-by: Logan Gunthorpe
Cc: "Horia Geantă"
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
---
driver
Now that we can expect iowrite64 to always exist the hack is no longer
necessary so we just call iowrite64 directly.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
1 file changed, 6 deletions(-)
diff
g the functions universally available to
configurations with CONFIG_GENERIC_IOMAP=y.
For any pio accesses, the 64bit operations remain unsupported and
simply call bad_io_access in cases readq would be called.
Signed-off-by: Logan Gunthorpe
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ell
hacks that have accumulated in the kernel,
thus far, for working around this.
This set is based off of v4.12-rc6.
Thanks,
Logan
[1] https://marc.info/?l=linux-kernel&m=149774601910663&w=2
Logan Gunthorpe (7):
drm/tilcdc: don't use volatile with iowrite64
iomap: implement
the alpha architecture.)
Signed-off-by: Logan Gunthorpe
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
---
arch/alpha/include/asm/io.h | 2 ++
arch/alpha/kernel/io.c | 18 ++
2 files changed, 20 insertions(+)
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/includ
Now that ioread64 and iowrite64 are available generically we can
remove the hack at the top of ntb_hw_intel.c that patches them in
when they are not available.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
---
drivers/ntb/hw/intel/ntb_hw_intel.c | 30
warning
on arm.
Signed-off-by: Logan Gunthorpe
Cc: Arnd Bergmann
---
include/asm-generic/io.h | 54 +---
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015eb3403..817edaa3da78
101 - 131 of 131 matches
Mail list logo