Hi Mina,
I recommend you cc linux-mm and Matthew Wilcox on these two patches also.
David
kushagra...@outlook.com wrote:
> @@ -256,7 +256,6 @@ struct fscache_cookie *fscache_acquire_cookie(struct
> fscache_volume *volume,
>
> /**
> * fscache_use_cookie - Request usage of cookie attached to an object
> - * @object: Object description
> * @will_modify: If cache is expected to be
Jani Nikula wrote:
> David, please try [1].
Assuming you mean this:
https://patchwork.freedesktop.org/patch/366958/?series=77635&rev=1
yes, that works.
Tested-by: David Howells
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
Here's the dmesg from a successful boot (commit
f84e1ba336a4f47ae251e4d2d8a694902571b0df).
David
---
[0.007455] Normal [mem 0x0001-0x00041fdf]
[0.007456] Movable zone start for each node
[0.007456] Early memory node ranges
[0.007457] node 0: [mem 0x0
Hi,
I'm seeing the attached oops and panic from the i915 drm driver. I've tried
bisecting it, but there's a problem in that one of the merged branches causes
the machine to hang without output.
The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
BUG: kernel NULL pointer de
Peter Zijlstra wrote:
> I tried using wake_up_var() today and accidentally noticed that it
> didn't imply an smp_mb() and specifically requires it through
> wake_up_bit() / waitqueue_active().
Thinking about it again, I'm not sure why you need to add the barrier when
wake_up() (which this is a w
Hi Al,
I wonder if it would be possible to extend anon_inodes to return just an
anonymous inode, thereby allowing the drm filesystem to be removed in favour
of just using an anon_inode.
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
nverts a slew of filesystems to use the mount API.
(9) Fixes a bug in hypfs.
The patches can be found here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
on branch:
mount-api-viro
David
---
Andrew Price (1):
gfs2: Convert gfs2 to fs_context
-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..9eead5a478de
Signed-off-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48
be found here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
on branch:
mount-api-viro
David
---
David Howells (38):
vfs: Provide sb->s_iflags settings in fs_context struct
vfs: Provide a mount_pseudo-replacement for fs_context
vfs
The i810 and msm drm drivers use C++ keywords as structural members. Fix
this by inserting an anonymous union that provides an alternative name and
then hide the reserved name in C++.
Signed-off-by: David Howells
cc: Rob Clark
cc: David Airlie
cc: linux-arm-...@vger.kernel.org
cc: dri-devel
eader to fs/coda/.
The patches can also be found here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check
Thanks,
David
---
David Howells (11):
UAPI: drm: Fix use of C++ keywords as structural members
UAPI: keys: Fix use of C++ keywords as struct
Greg KH wrote:
> > Here's a set of patches that inserts a step into the build process to make
> > sure that the UAPI headers can all be built together with C++ (if the
> > compiler being used supports C++). All but the final patch perform fixups,
> > including:
>
> Wait, why do we care? What h
The i810 and msm drm drivers use C++ keywords as structural members. Fix
this by inserting an anonymous union that provides an alternative name and
then hide the reserved name in C++.
Signed-off-by: David Howells
cc: Rob Clark
cc: David Airlie
cc: linux-arm-...@vger.kernel.org
cc: dri-devel
Compile all of the UAPI headers (with a few exceptions) together as
C++ to catch new errors occurring as part of the regular build
process.
The patches can also be found here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check
Thanks,
David
--
Do we have anything left that still implements NOMMU?
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Arnd Bergmann wrote:
> - mn10300 appears to be wrong, broken by David Howells in
> commit 83c2dc15ce82 ("MN10300: Handle cacheable PCI regions
> in pci_iomap()") for any driver calling ioremap() by to get uncached
> memory,
It's not clear what the right thing to
Joe Perches wrote:
> .c and .h source files should not be executable, change
> the permissions to 0644.
Acked-by: David Howells
- but that's shared with the debugfs interface where you can't do
that, so I don't see an easy way of doing it.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 22 +++---
1 file changed, 7 insertions(+), 15 del
an give you is 10 chars (4294967295) plus a NUL, so round up to 12 as the
stack is likely to be 4- or 8-byte aligned.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 13 +
drivers/gpu/drm/drm_stub.c |2 +-
include/drm/drmP.h
Constify drm_proc_list[] and related pointers.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c |6 +++---
include/drm/drmP.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b
- but that's shared with the debugfs interface where you can't do
that, so I don't see an easy way of doing it.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions
an give you is 10 chars (4294967295) plus a NUL, so round up to 12 as the
stack is likely to be 4- or 8-byte aligned.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 13 +
drivers/gpu/drm/drm_stub.c |2 +-
include/drm/drmP.h
Constify drm_proc_list[] and related pointers.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c |6 +++---
include/drm/drmP.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b
Cong Ding wrote:
> > > the variable sender is dereferenced in line 190, so it is no reason to
> > > check
> > > null again in line 198.
> >
> > Did you mean "The variable 'chan'"?
> sorry, my fault. so should I send a new version to correct the typo?
Yep.
David
Cong Ding wrote:
> the variable sender is dereferenced in line 190, so it is no reason to check
> null again in line 198.
Did you mean "The variable 'chan'"?
David
Cong Ding wrote:
> > > the variable sender is dereferenced in line 190, so it is no reason to
> > > check
> > > null again in line 198.
> >
> > Did you mean "The variable 'chan'"?
> sorry, my fault. so should I send a new version to correct the typo?
Yep.
David
___
Cong Ding wrote:
> the variable sender is dereferenced in line 190, so it is no reason to check
> null again in line 198.
Did you mean "The variable 'chan'"?
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
Luis R. Rodriguez wrote:
> >> The include_next trick can work as well but that'd mean synching the UAPI
> >> files regularly into compat. I'd much prefer to have code intact when
> >> possible when backporting so the option I stuck with then was to patch
> >> the code directly and then as part of
Luis R. Rodriguez wrote:
> >> The include_next trick can work as well but that'd mean synching the UAPI
> >> files regularly into compat. I'd much prefer to have code intact when
> >> possible when backporting so the option I stuck with then was to patch
> >> the code directly and then as part of
David Howells wrote:
> Linus Torvalds wrote:
>
> > Ok, as usual I actually wanted to do the merge myself despite the
> > annoying conflicts (this *really* is the last time I will ever accept
> > any header file "cleanups" - they simply aren't worth the
Linus Torvalds wrote:
> Ok, as usual I actually wanted to do the merge myself despite the
> annoying conflicts (this *really* is the last time I will ever accept
> any header file "cleanups" - they simply aren't worth the pain).
There was a reason I asked you to pull the patches at the *end* of
David Howells wrote:
> Linus Torvalds wrote:
>
> > Ok, as usual I actually wanted to do the merge myself despite the
> > annoying conflicts (this *really* is the last time I will ever accept
> > any header file "cleanups" - they simply aren't worth the
Linus Torvalds wrote:
> Ok, as usual I actually wanted to do the merge myself despite the
> annoying conflicts (this *really* is the last time I will ever accept
> any header file "cleanups" - they simply aren't worth the pain).
There was a reason I asked you to pull the patches at the *end* of
Tejun Heo wrote:
> > > My question to all of you: Should system_nrt_wq be made freezable, or
> > > should I create a new workqueue that is both freezable and
> > > non-reentrant? And if I do, which of the usages above should be
> > > converted to the new workqueue?
> >
> > As far as keys are
Alan Stern wrote:
> My question to all of you: Should system_nrt_wq be made freezable, or
> should I create a new workqueue that is both freezable and
> non-reentrant? And if I do, which of the usages above should be
> converted to the new workqueue?
As far as keys are concerned, it's only f
Tejun Heo wrote:
> > > My question to all of you: Should system_nrt_wq be made freezable, or
> > > should I create a new workqueue that is both freezable and
> > > non-reentrant? And if I do, which of the usages above should be
> > > converted to the new workqueue?
> >
> > As far as keys are
Alan Stern wrote:
> My question to all of you: Should system_nrt_wq be made freezable, or
> should I create a new workqueue that is both freezable and
> non-reentrant? And if I do, which of the usages above should be
> converted to the new workqueue?
As far as keys are concerned, it's only f
39 matches
Mail list logo
