On Sun, Mar 21, 2021, at 6:00 PM, Dmitry Torokhov wrote:
> This simplifies error unwinding path and allows us to get rid of
> remove() method.
>
> Signed-off-by: Dmitry Torokhov <mailto:dmitry.torokhov%40gmail.com>>
Reviewed-by: Alistair Francis
Alistair
> ---
>
On Sun, Mar 21, 2021, at 6:00 PM, Dmitry Torokhov wrote:
> Instead of forcing interrupt trigger to "level low" rely on the
> platform to set it up according to how it is wired on the given
> board.
>
> Signed-off-by: Dmitry Torokhov <mailto:dmitry.torokhov%40gmail.
On Wed, May 6, 2020, at 1:27 AM, Geert Uytterhoeven wrote:
> Hi Alistair,
>
> On Wed, May 6, 2020 at 3:41 AM Alistair Francis
> wrote:
> > Add a setup function that can be used to support using generic GPIO
> > lines for the chip select.
> >
>
gt;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Alistair
On Tue, 27 Feb 2001, Heusden, Folkert van wrote:
> But; it's not that much of hassle to run it trough some awk/sed/whatsoever
> script, would it? Imho there should be as less as possible code in the
man fromdos (on most linux systems anyway)
--
Alistair Riddell - BOFH
IT Support
On Mon, 15 Aug 2016 04:51:59 PM Alistair Popple wrote:
> POWER9 contains an off core mmu called the nest mmu (NMMU). This is
> used by other hardware units on the chip to translate virtual
> addresses into real addresses. The unit attempting an address
> translation provides the maj
Acked-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
Regards,
Alistair
[006280989170] Generic RTC Driver v1.07
[006
On Fri, Aug 3, 2018 at 3:26 AM Thomas Gleixner wrote:
>
> On Wed, 18 Jul 2018, Alistair Strachan wrote:
> > export CPPFLAGS_vdso.lds += -P -C
> >
> > -VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
> > - -Wl,--no-undefined \
> &
el-t...@android.com
Cc: j...@joelfernandes.org
Signed-off-by: Alistair Strachan
Acked-by: Andy Lutomirski
---
v2: Updated changelog and rediffed
Supersedes "x86: vdso: Fix leaky vdso link with CC=clang"
arch/x86/entry/vdso/Makefile | 22 +-
1 file changed, 9 insertions(+), 13
On Fri, Aug 3, 2018 at 9:38 AM Nick Desaulniers wrote:
>
> On Fri, Aug 3, 2018 at 6:10 AM Jean Delvare wrote:
> >
> > Hi Nick,
> >
> > It seems that this linux kernel commit of yours:
> >
> > commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7
> > Author: Nick Desaulniers
> > Date: Thu Jun 21 09:23
On Mon, Jun 18, 2018 at 8:09 AM Arnd Bergmann wrote:
>
> The timespec structure suffers from the y2038 overflow and should not
> be used. This changes handle_vsoc_cond_wait() to use ktime_t directly.
>
> Signed-off-by: Arnd Bergmann
Tested-by: Alistair Strachan
> ---
g else) is very welcome.
>
> Thanks so much!
> Ray
>
> Signed-off-by: Ray Clinton
Acked-by: Alistair Strachan
> ---
> drivers/staging/android/uapi/vsoc_shm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/uapi
olnar
Cc: "H. Peter Anvin"
Cc: Greg Kroah-Hartman
Cc: x...@kernel.org
Cc: kernel-t...@android.com
Cc: j...@joelfernandes.com
Signed-off-by: Alistair Strachan
---
Supersedes "x86: vdso: Fix leaky vdso link with CC=clang"
arch/x86/entry/vdso/Makefile | 22 +---
KBUILD_CFLAGS. These flags direct clang to the
appropriate toolchain to link the vdsos.
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Greg Kroah-Hartman
Cc: x...@kernel.org
Cc: kernel-t...@android.com
Cc: j...@joelfernandes.com
Signed-off-by: Alistai
On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin wrote:
> On 07/12/18 13:10, Alistair Strachan wrote:
> > The vdso{32,64}.so can fail to link with CC=clang when clang tries to
> > find a suitable GCC toolchain to link these libraries with.
> >
> > /usr/bin/ld: arch/x86/
On Thu, Jul 12, 2018 at 4:20 PM Andy Lutomirski wrote:
>
> > On Jul 12, 2018, at 3:06 PM, H. Peter Anvin wrote:
> >
> >> On 07/12/18 13:37, Alistair Strachan wrote:
> >>> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin wrote:
> >>>> On 07/12
...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Greg Hartman
[astrachan: rebased against 4.16, added TODO, fixed checkpatch issues]
Signed-off-by: Alistair Strachan
---
v2: addressed issues with class_create() failure handling and redundant
null pointer checks noticed by Dan
...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Greg Hartman
[astrachan: rebased against 4.16, added TODO, fixed checkpatch issues]
Signed-off-by: Alistair Strachan
---
drivers/staging/android/Kconfig |9 +
drivers/staging/android/Makefile|1 +
drivers/staging/android/TODO
(Resent plain text)
On Thu, May 24, 2018 at 11:24 AM Nick Desaulniers
wrote:
> On Thu, May 24, 2018 at 11:20 AM wrote:
> > A stack canary on an *inlined* function? That's bound to break things
> elsewhere too sooner or later.
> But it's *not* inlined by GCC or Clang.
FWIW, GCC can also insert
namespace implementation, maintaining
> kernel mounts of proc is removed.
>
> In addition removing the unnecessary complexity of the kernel mount
> fixes a regression that caused the proc mount options to be ignored.
> Now that the initial mount of proc comes from userspace, those mount
>
if (rc == 0)
> + break;
> + msleep(1);
> + }
The rc handling above took me a little while to grok but I didn't come up with a
cleaner alternative and I think it's correct.
- Alistair
> >
> > That said, cronus does a bunch
On Monday, 18 June 2018 2:46:33 PM AEST Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-18 at 14:09 +1000, Alistair Popple wrote:
> > On Sunday, 17 June 2018 11:22:11 AM AEST Benjamin Herrenschmidt wrote:
> > > On Sun, 2018-06-17 at 11:17 +1000, Benjamin Herrenschmidt wrote:
&
: Alistair Strachan
---
drivers/staging/android/ashmem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index a1a0025b59e0..1eeedb529a10 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
HI Greg,
On Tue, Jun 19, 2018 at 4:01 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 19, 2018 at 03:24:44PM -0700, Alistair Strachan wrote:
> > The ashmem driver did not check that the size/offset of the vma passed
> > to its .mmap() function was not larger than the ashmem objec
Signed-off-by: Alistair Strachan
---
drivers/staging/android/ashmem.c | 34
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index a1a0025b59e0..c6386e4f5c9b 100644
--- a/drivers/staging
...@android.com
Cc: Joel Fernandes
Signed-off-by: Alistair Strachan
---
v2: Removed unnecessary use of unlikely() macro
drivers/staging/android/ashmem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index c6386e4f5c9b
On Mon, Jun 11, 2018 at 6:22 PM Eric W. Biederman wrote:
>
> Alistair Strachan writes:
>
> > In commit e94591d0d90c "proc: Convert proc_mount to use mount_ns"
> > the parsing of mount parameters for the proc filesystem was broken.
> >
> &
google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
A similar (non-compiling) patch was provided at that time.
Reported-by: syzbot
Signed-off-by: Alistair Strachan
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: kernel-t...@android.com
---
drivers/media/usb/uvc/uv
Hi Laurent,
On Tue, Dec 18, 2018 at 1:42 AM Laurent Pinchart
wrote:
>
> Hi Alistair,
>
> Thank you for the patch.
>
> On Monday, 17 December 2018 23:02:22 EET Alistair Strachan wrote:
> > When initially testing the Camera Terminal Descriptor wTerminalType
> > fiel
in the wTerminalType field.
If the bit is set, assume the descriptor is bad, and abort parsing it.
Originally reported here:
https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
A similar (non-compiling) patch was provided at that time.
Reported-by: syzbot
Signed-off-by: Alistair
On Wed, Dec 19, 2018 at 12:16 AM Laurent Pinchart
wrote:
>
> Hi Alistair,
>
> Thank you for the patch.
>
> On Wednesday, 19 December 2018 03:32:48 EET Alistair Strachan wrote:
> > From: Laurent Pinchart
>
> Are you sure you don't want to keep authorship ? I&#
Hi Laura,
On Fri, Dec 14, 2018 at 1:48 PM Laura Abbott wrote:
> Hi,
>
> There are two reports of a regression with unwinding with
> 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
>
> https://bugzilla.kernel.org/show_bug.cgi?id=201741
> https://bugzilla.redhat.com/show_bug.cgi?id=16592
"H. Peter Anvin"
Cc: X86 ML
Cc: Florian Weimer ,
Cc: Carlos O'Donell ,
Cc: "H. J. Lu"
Cc: Joel Fernandes
Cc: kernel-t...@android.com
Signed-off-by: Alistair Strachan
---
arch/x86/entry/vdso/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
stead of $CC to link")
Cc: sta...@vger.kernel.org
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: X86 ML
Cc: Joel Fernandes
Cc: kernel-t...@android.com
Signed-off-by: Alistair Strachan
---
v2: Updated commit message, no changes to the code
arch/x86/entry/vdso/Makefil
Enable generic PCIe by default in the RISC-V defconfig, this allows us
to use QEMU's PCIe support out of the box. Also remove the Xilinx PCIe
support by default as this is rarely used and conflicts with the more
commonly used (out of tree) MicroSemi PCIe root complex.
Signed-off-by: Ali
On Fri, 2018-12-21 at 11:13 -0800, Paul Walmsley wrote:
> Hello Alistair,
>
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > Enable generic PCIe by default in the RISC-V defconfig, this allows
> > us
> > to use QEMU's PCIe support out of the box. Also rem
Enable generic PCIe by default in the RISC-V defconfig, this allows us
to use QEMU's PCIe support out of the box.
Signed-off-by: Alistair Francis
---
v2:
- Keep the Xilinx PCIE enabled
arch/riscv/configs/defconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/co
On Fri, 2018-12-21 at 11:27 -0800, Paul Walmsley wrote:
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > When the MicroSemi driver does eventually go upstream this will
> > probably have to be discussed though as either the config or device
> > tree will need to be e
On Fri, 2018-12-21 at 14:34 -0800, Paul Walmsley wrote:
>
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > On Fri, 2018-12-21 at 11:27 -0800, Paul Walmsley wrote:
> > > On Fri, 21 Dec 2018, Alistair Francis wrote:
> > >
> > > > When the MicroSemi
o/bzImage -drive
file=root.ext4" on x86_64_defconfig with CONFIG_OF_UNITTEST enabled.
If the FDT is unpacked successfully, the
/proc/device-tree/firmware/android/compatible file will exist, and
contain the string "android,firmware" instead of junk.
I'm still looking into the root cause for this, but I just wanted to
let you know.
Alistair.
t; >> fuse by doing something (looking up ./file0/file0) and the one that
> >> reads the fuse device (returning with the LOOKUP request for "file0").
> >> The second one will return with that lock held, but it's not the one
> >> that acquired it, so
Thanks for this Huang, I had been hoping to take a look at it this week
but have run out of time. I'm keen to do some testing with it as well.
Hopefully next week...
Huang Ying writes:
> We have the explicit memory tiers framework to manage systems with
> multiple types of memory, e.g., DRAM
of
> algorithm implementations can be specified via
> priority (notifier_block.priority).
How/what decides the priority though? That seems like something better
decided by a device driver than the algorithm driver IMHO.
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
&g
refactor looks good and I have run the whole series on a system with
some hmat data so:
Reviewed-by: Alistair Popple
Tested-by: Alistair Popple
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Popple
> Cc: Dan Williams
> Cc: Dave
rate/complete.
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Popple
> Cc: Dan Williams
> Cc: Dave Hansen
> Cc: Davidlohr Bueso
> Cc: Johannes Weiner
> Cc: Jonathan Cameron
> Cc: Michal Hocko
>
ut into the "kmem_memory_types" list and protected by
> kmem_memory_type_lock.
See below but I wonder if kmem_memory_types could be a common helper
rather than kdax specific?
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Pop
"Huang, Ying" writes:
> Hi, Alistair,
>
> Thanks a lot for comments!
>
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> The abstract distance may be calculated by various drivers, such as
>>> ACPI HMAT, CXL CDAT, etc. Whi
ory device drivers can use the general notifier chain
>>> interface at the same time.
How would that work in practice though? The abstract distance as far as
I can tell doesn't have any meaning other than establishing preferences
for memory demotion order. Therefore all calculations are relative to
the rest of the calculations on the system. So if a driver does it's own
thing how does it choose a sensible distance? IHMO the value here is in
coordinating all that through a standard interface, whether that is HMAT
or something else.
- Alistair
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>>>> And, I don't think that we are forced to use the general notifier
>>>>> chain interface in all memory device drivers. If the memory
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>>>>> While other memory device drivers can use the general notifier chain
>>>>>&
"Huang, Ying" writes:
> Hi, Alistair,
>
> Sorry for late response. Just come back from vacation.
Ditto for this response :-)
I see Andrew has taken this into mm-unstable though, so my bad for not
getting around to following all this up sooner.
> Alistair Popple wri
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> A memory tiering abstract distance calculation algorithm based on ACPI
>>> HMAT is implemented. The basic idea is as follows.
>>>
>>> The perform
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> Huang Ying writes:
>>
>>> Previously, a fixed abstract distance MEMTIER_DEFAULT_DAX_ADISTANCE is
>>> used for slow memory type in kmem driver. This limits the usage of
>>> km
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Hi, Alistair,
>>>
>>> Sorry for late response. Just come back from vacation.
>>
>> Ditto for this response :-)
>>
>> I
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Hi, Alistair,
>>>>>
&g
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> Huang Ying writes:
>>>>
>>>>> Previously, a fixed abstract distance MEMTIER_DEF
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Alistair Popple writes:
>>>
"Huang, Ying" writes:
> Alistair Popple writes:
>
>> "Huang, Ying" writes:
>>
>>> Alistair Popple writes:
>>>
>>>> "Huang, Ying" writes:
>>>>
>>>>> Alistair Popple writes:
>>&g
Cc: Greg Kroah-Hartman
Cc: Arve Hjønnevåg
Cc: Todd Kjos
Cc: Martijn Coenen
Cc: Greg Hartman
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Alistair Strachan
---
drivers/staging/android/vsoc.c | 100 -
1 file changed, 49 insertions
an
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Alistair Strachan
---
drivers/staging/android/vsoc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 794137b7751f..3e6e4af7d6a1 100644
---
Map the region shm as write-combining instead of uncachable.
Cc: Greg Kroah-Hartman
Cc: Arve Hjønnevåg
Cc: Todd Kjos
Cc: Martijn Coenen
Cc: Greg Hartman
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Alistair Strachan
---
drivers/staging/android/TODO | 1
:03:00.0: startup error -19
xhci_hcd :03:00.0: USB bus 2 deregistered
xhci_hcd :03:00.0: WARNING: Host System Error
xhci_hcd :03:00.0: remove, state 1
Signed-off-by: Alistair Francis
---
I'm not sure if this is the correct fix, it's possible something else is
wr
On Thu, Feb 28, 2019 at 2:39 PM Paul Walmsley wrote:
>
> Hello Alistair,
>
> On Thu, 28 Feb 2019, Alistair Francis wrote:
>
> > This reverts commit 6778be4e520959659b27a441c06a84c9cb009085.
> >
> > Reverting the commit fixes these error messages and an non-functio
et_pte_at was
> > called later).
Thanks for the fixup. I didn't realise that invalidate_range() always gets
called but I now see that is the case so this change looks good to me as well.
Reviewed-by: Alistair Popple
> > All the necessary cache invalidation should all be
On Fri, Mar 22, 2019 at 6:27 AM Christoph Hellwig wrote:
>
> On Wed, Mar 20, 2019 at 05:04:58PM -0700, Alistair Francis wrote:
> > > Well, it starts at 0x00, but the first one is reserved. If you think
> > > that is too confusing I'd rather throw in a comment expl
;s probably other issues as well,
> since this
> is so early).
>
> Sorry I missed this the first time around, I wasn't paying enough
> attention.
>
> Can someone add instructions for 32-bit boots to the QEMU wiki? It
> sounds like
> it's time to add that to the testing list...
Done!
https://wiki.qemu.org/Documentation/Platforms/RISCV
Alistair
>
> Thanks for digging in to this!
>
> > Regards,
> > Anup
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > Device private pages are used to represent device memory that is not
> > directly accessible from the CPU. Extra references to a device priva
do what was required (a callback on CPU access).
However I have been reworking this to use mmu notifiers as the callback and it
seems to simplify some things nicely so think I also agree. It removes the
requirement for the pin as well which is nice, I'll post it as a v2 soon.
- Alistair
.
Alistair Popple (4):
hmm: Device exclusive memory access
hmm: Selftests for exclusive device memory
nouveau/svm: Refactor nouveau_range_fault
nouveau/svm: Implement atomic SVM access
Documentation/vm/hmm.rst | 15 ++
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345
to proceed.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 86 ---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst
Apologies for the noise, looks like I don't have a CONFIG_DEVICE_PRIVATE=n
build in my tests and missed creating definitions for the new static inline
functions for that configuration.
I'll wait for some feedback on the overall approach and fix this in a v3.
- Alistair
On Friday, 1
On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo wrote:
>
> On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote:
> > The reMarkable2 requires VMSPLIT_2G, so lets set this in the
> > imx_v6_v7_defconfig.
>
> Hmm, why is VMSPLIT_2G required by reMarkable2?
I'm
On Tue, Feb 2, 2021 at 11:50 PM Arnd Bergmann wrote:
>
> On Wed, Feb 3, 2021 at 3:37 AM Alistair Francis wrote:
> >
> > On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo wrote:
> > >
> > > On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote:
> > &
Signed-off-by: Alistair Francis
---
arch/arm/boot/dts/imx7d-remarkable2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
b/arch/arm/boot/dts/imx7d-remarkable2.dts
index 0aae13f5eed6..0978e26f5db5 100644
--- a/arch/arm/boot/dts/imx7d-remarkable2
accessed without having to open up the device via the OTG pogo pins.
Currently the kernel boots, but there is no support for the dispaly,
WiFi or the power controller chips.
Signed-off-by: Alistair Francis
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-remarkable2.dts
Run make imx_v6_v7_defconfig; make savedefconfig to regenerate the
defconfig.
Signed-off-by: Alistair Francis
---
arch/arm/configs/imx_v6_v7_defconfig | 36
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch
moved has yet to be resolved so any discussion is
welcome.
Alistair Popple (9):
mm/migrate.c: Always allow device private pages to migrate
mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup()
mm/migrate: Add a unmap and pin migration mode
Documentation: Add unmap and pin to
private page migration as this can lead to failures to
migrate pages back to the CPU which are fatal to the user process.
Signed-off-by: Alistair Popple
---
mm/migrate.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 20ca887ea769
freed it is safe to allow the unmap
and pin operation to proceed in cases where there are extra page
references present.
Signed-off-by: Alistair Popple
---
include/linux/migrate.h | 2 +
include/linux/migrate_mode.h | 1 +
mm/migrate.c | 74
Update the HMM documentation to include information on the unmap and pin
operation.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index
pfn arrays.
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++--
lib/test_hmm.c | 6 --
mm/migrate.c | 1 -
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm
Adds a basic test of the HMM unmap and pin operation.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 107 +
lib/test_hmm_uapi.h| 1 +
tools/testing/selftests/vm/hmm-tests.c | 49 +++
3 files changed, 140
uired.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 92987daa5e17..9579bd001f11 100644
--- a/drivers/gp
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
when accessing some GPU pages.
This patch extends the existing Nouveau device private page allocator to
make it easier to allocate device private pages with different callbacks
but should not introduce any functional changes.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau
: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_dmem.c| 148 --
drivers/gpu/drm/nouveau/nouveau_dmem.h| 4 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 116 --
drivers/gpu/drm/nouveau/nvkm
might be missing some other callbacks to be
> able to move these pages, instead of abusing longterm pins for lack of
> better tools.
Yes, I would like to avoid the long term pin constraints as well if possible I
just haven't found a solution yet. Are you suggesting it might be po
stead of device
private pages.
Alistair Popple (8):
mm: Remove special swap entry functions
mm/swapops: Rework swap entry manipulation code
mm/rmap: Split try_to_munlock from try_to_unmap
mm/rmap: Split migration into its own function
mm: Device exclusive memory access
mm: Selftests for e
-off-by: Alistair Popple
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10
rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
---
Given the comments on not needing to hold mmap_lock it was not 100% clear
to me if it is safe to check vma->vma_flags & VM_LOCK
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 10 +-
mm/migrate.c | 9 +-
mm/rmap.c| 352 +++
4 files changed, 269 insertions(+), 106
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gp
original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst
to proceed.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 88 ---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files
Signed-off-by: Alistair Delva
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 9e73f82e0d86..3269e155fbe4 100644
--- a/Makefile
+++ b/Makefile
@@ -1074,8 +1074,9 @@ export mod_sign_cmd
HOST_LIBELF_LIBS = $(shell pkg-config libel
1 - 100 of 658 matches
Mail list logo
