It is possible to run out of memory while allocating IDs. The current
code would create a context with an invalid ID; change it to return
-ENOMEM to userspace.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 29 +++-
1 file changed, 11
It is possible to run out of memory while allocating IDs. The current
code would create an object with an invalid ID; change it to return
-ENOMEM to the caller.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +--
drivers/gpu/drm/virtio/virtgpu_fb.c| 10
rly handle one of the error cases ... see the comment
embedded in one of the patches.
Matthew Wilcox (4):
drm/virtio: Replace IDRs with IDAs
drm/virtio: Handle context ID allocation errors
drm/virtio: Handle object ID allocation errors
drm/virtio: Use IDAs more efficiently
drivers/gpu/
0-based IDAs are more efficient than any other base. Convert the
1-based IDAs to be 0-based.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 ++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers
These IDRs were only being used to allocate unique numbers, not to look
up pointers, so they can use the more space-efficient IDA instead.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 18 --
drivers
On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote:
> @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct
> virtio_gpu_device *vgdev,
>
> if (handle < 0)
> return handle;
> + handle++;
> virtio_gpu_cmd_context_create(v
Signed-off-by: Xueshi Hu
Reviewed-by: Matthew Wilcox (Oracle)
On Tue, Aug 29, 2023 at 01:34:22PM -0400, James Zhu wrote:
> > > > @@ -1067,7 +1055,7 @@ static void drm_core_exit(void)
> > > > unregister_chrdev(DRM_MAJOR, "drm");
> > > > debugfs_remove(drm_debugfs_root);
> > > > drm_sysfs_destroy();
> > > > - idr_destroy(&drm_minor
On Tue, Aug 29, 2023 at 02:35:34PM -0400, James Zhu wrote:
>
> On 2023-08-29 14:33, Matthew Wilcox wrote:
> > On Tue, Aug 29, 2023 at 01:34:22PM -0400, James Zhu wrote:
> > > > > > @@ -1067,7 +1055,7 @@ static void drm_core_exit(void)
> > > > > &g
On Sat, Mar 23, 2024 at 10:01:47PM +0530, Amogh Cheluvaraj wrote:
> Fix duplicate C declaration warnings at
> Documentation/gpu/drm-kms.rst that was found by
> compiling htmldocs
I'm sure this removes the warning, but it removes all kernel-doc
which exists in drivers/gpu/drm/drm_fourcc.c. Isn't t
On Tue, Sep 19, 2023 at 10:26:42AM +0200, Oleksandr Natalenko wrote:
> Andrzej asked me to try to revert commits 0b62af28f249, e0b72c14d8dc and
> 1e0877d58b1e, and reverting those fixed the i915 crash for me. The
> e0b72c14d8dc and 1e0877d58b1e commits look like just prerequisites, so I
> assume
On Tue, Sep 19, 2023 at 04:43:41PM +0100, Matthew Wilcox wrote:
> Could I ask you to try this patch? I'll follow up with another patch
> later because I think I made another assumption that may not be valid.
Ah, no, never mind. I thought we could start in the middle of a folio,
bu
On Tue, Sep 19, 2023 at 08:11:47PM +0200, Oleksandr Natalenko wrote:
> I can confirm this one fixes the issue for me on T460s laptop. Thank you!
Yay!
> Should you submit it, please add:
>
> Fixes: 0b62af28f2 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Thanks for collecting all
On Mon, Oct 02, 2023 at 01:02:52PM +0200, Oleksandr Natalenko wrote:
> > > > > BUG: KFENCE: memory corruption in drm_gem_put_pages+0x186/0x250
> > > > >
> > > > > Corrupted memory at 0xe173a294 [ ! ! ! ! ! ! ! ! ! ! ! ! ! !
> > > > > ! ! ] (in kfence-#108):
> > > > > drm_gem_put_pages+0x
On Thu, Oct 05, 2023 at 09:56:03AM +0200, Oleksandr Natalenko wrote:
> Hello.
>
> On čtvrtek 5. října 2023 9:44:42 CEST Thomas Zimmermann wrote:
> > Hi
> >
> > Am 02.10.23 um 17:38 schrieb Oleksandr Natalenko:
> > > On pondělí 2. října 2023 16:32:45 CEST Matt
On Thu, Oct 05, 2023 at 02:30:55PM +0200, Oleksandr Natalenko wrote:
> No-no, sorry for possible confusion. Let me explain again:
>
> 1. we had an issue with i915, which was introduced by 0b62af28f249, and later
> was fixed by 863a8eb3f270
> 2. now I've discovered another issue, which looks very
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> +++ b/mm/internal.h
Why are you putting __kstrndup in a header file when it's only used
in util.c?
Also, I think this function is actually __kmemdup_nul(), not
__kstrndup().
On Sun, Jun 23, 2024 at 10:29:30AM +0800, Yafang Shao wrote:
> On Fri, Jun 21, 2024 at 9:57 PM Matthew Wilcox wrote:
> >
> > On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> > > +++ b/mm/internal.h
> >
> > Why are you putting __kstrndup in a he
Souptick and I have been auditing the various page fault handler routines
and we've noticed that graphics drivers assume that a signal should be
able to interrupt a page fault. In contrast, the page cache takes great
care to allow only fatal signals to interrupt a page fault.
I believe (but have
On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote:
> Quoting Matthew Wilcox (2018-04-02 15:10:58)
> > Souptick and I have been auditing the various page fault handler routines
> > and we've noticed that graphics drivers assume that a signal should be
> > able
On Tue, Apr 03, 2018 at 02:20:43PM +0100, Chris Wilson wrote:
> Quoting Matthew Wilcox (2018-04-03 14:10:25)
> > On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote:
> > > Quoting Matthew Wilcox (2018-04-02 15:10:58)
> > > > I don't think the graphics dr
On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote:
> I think the TTM page fault handler originally set the standard for this.
> First, IMO any critical section that waits for the GPU (like typically the
> page fault handler does), should be locked at least killable. The need for
> in
On Wed, Apr 04, 2018 at 11:32:54AM +0200, Daniel Vetter wrote:
> So we've done some experiments for the case where the fault originated
> from kernel context (copy_to|from_user and friends). The fixup code seems
> to retry the copy once after the fault (in copy_user_handle_tail), if that
> fails ag
On Wed, Apr 04, 2018 at 05:15:46PM +0200, Daniel Vetter wrote:
> On Wed, Apr 4, 2018 at 4:39 PM, Matthew Wilcox wrote:
> > I actually have plans to allow mutex_lock_{interruptible,killable} to
> > return -EWOULDBLOCK if a flag is set. So this doesn't seem entirely
> >
Three^W Two of the TTM drivers intercept the pagefault handler in a rather
un-Linuxy and racy way. If they really must intercept the fault call
(and it's not clear to me that they need to), I'd rather see them do it
like this.
The QXL driver seems least likely to need it; as the virtio driver ha
On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
> Not exactly. The plan for these patches is to introduce new vm_fault_t type
> in vm_operations_struct fault handlers. It's now available in 4.17-rc1. We
> will
> push all the required drivers/filesystem changes through different m
On Wed, Apr 18, 2018 at 10:24:39AM +0200, Thierry Reding wrote:
> > @@ -437,20 +436,7 @@ static int tegra_bo_fault(struct vm_fault *vmf)
> > offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
> > page = bo->pages[offset];
> >
> > - err = vm_insert_page(vma, vmf->address, page);
> > -
On Tue, Oct 10, 2017 at 09:56:22PM +0900, Masahiro Yamada wrote:
> One refactoring alone does not produce much benefits,
> but making continuous efforts will disentangle the knotted threads.
> Of course, this might be a pipe dream...
A lot of people have had that dream, and some of those refactori
On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
> Reducing the header dependency will help for speeding the kernel
> build, suppressing unnecessary recompile of objects during
> git-bisect'ing, etc.
Well, does it? You could provide measurements showing before/after
time to compil
On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> things such as the following need to be below (1 << 40), and also accessible
> to both CPU (user space) and GPU hardware.
> -- command buffers (CPU user
On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote:
> I have a patchset that creates a vsprintf extension for
> print_vma_addr and removes all the uses similar to the
> print_symbol() removal.
>
> This now avoids any possible printk interleaving.
>
> Unfortunately, without some #ifdef in
On Thu, Nov 30, 2017 at 08:56:43PM +0100, Daniel Vetter wrote:
> Adding dri-devel, I think a pile of those are in drm.
Yeah, quite a lot! This is a good thing; means you didn't invent your
own custom ID allocator.
> On Thu, Nov 30, 2017 at 6:36 PM, Matthew Wilcox wrote:
> >
On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> Darrick reported that the fairly new XFS xfile code blows up when force
> enabling large folio for shmem. This series fixes this quickly by disabling
> large folios for this particular shmem file for now until it can
On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote:
> Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> > However we specifically pass "huge=within_size" to vfs_kern_mount when
> > creating a private mount of tmpfs for the purpose of i915 created
> > allocations.
> >
> > Older hardware
On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"
> wrote:
>
> > > > Fixing this will require a bit of an API change, and prefeably sorting
> > > > out
> > > > the hwpoison story for pages vs folio and where it is placed in the
We're currently trying to remove page->mapping from the entire kernel.
This has me interested in fb_defio and since I made such a mess of it
with commits ccf953d8f3d6 / 0b78f8bcf495, I'd like to discuss what to
do before diving in.
Folios continue to have a mapping. So we can effectively do
page_
On Mon, Dec 11, 2023 at 11:38:01PM -0800, Vivek Kasireddy wrote:
> @@ -42,7 +42,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
> if (pgoff >= ubuf->pagecount)
> return VM_FAULT_SIGBUS;
>
> - pfn = page_to_pfn(ubuf->pages[pgoff]);
> + pfn = page_to_pfn(&u
On Mon, Dec 11, 2023 at 11:38:02PM -0800, Vivek Kasireddy wrote:
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -42,7 +42,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
> if (pgoff >= ubuf->pagecount)
> return VM_FAULT_SIGBUS;
>
> - pfn = page_to_pfn(&ubuf->folios[p
On Fri, Dec 15, 2023 at 10:05:33PM -0800, Vivek Kasireddy wrote:
> +++ b/include/linux/memfd.h
> @@ -6,11 +6,16 @@
>
> #ifdef CONFIG_MEMFD_CREATE
> extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int
> arg);
> +extern struct folio *memfd_alloc_folio(struct file *memfd, pg
me to keep track of
> stuff.
As long as 3.14 turns into a long-term support kernel and gets up to 159 ...
In all serious, I'm very supportive of this move. I'm heartily sick
of people claiming "we have version 2.6 support" when they really mean
they ha
me to keep track of
> stuff.
As long as 3.14 turns into a long-term support kernel and gets up to 159 ...
In all serious, I'm very supportive of this move. I'm heartily sick
of people claiming "we have version 2.6 support" when they really mean
they ha
On Mon, Nov 11, 2024 at 08:26:54AM +, Fuad Tabba wrote:
> Thanks for your comments Jason, and for clarifying my cover letter
> David. I think David has covered everything, and I'll make sure to
> clarify this in the cover letter when I respin.
I don't want you to respin. I think this is a bad
On Tue, Nov 12, 2024 at 03:22:46PM +0100, David Hildenbrand wrote:
> On 12.11.24 14:53, Jason Gunthorpe wrote:
> > On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote:
> > > On 12.11.24 06:26, Matthew Wilcox wrote:
> > > > I don't want you to
I've pushed out a new tree to
git://git.infradead.org/users/willy/pagecache.git shrunk-page
aka
http://git.infradead.org/?p=users/willy/pagecache.git;a=shortlog;h=refs/heads/shrunk-page
The observant will notice that it doesn't actually shrink struct page
yet. However, we're getting close. What
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
Well, this is a horrid little function. Rather than iterating just the
dirty folios, it iterates all folios, then locks them before checking
whether
On Wed, Jan 08, 2025 at 04:18:41PM +, Lorenzo Stoakes wrote:
> +++ b/include/linux/rmap.h
> @@ -754,6 +754,26 @@ unsigned long page_address_in_vma(const struct folio
> *folio,
> */
> int folio_mkclean(struct folio *);
>
> +/**
The kerneldoc comment should be with the implementation, not
On Wed, Jan 08, 2025 at 04:18:42PM +, Lorenzo Stoakes wrote:
> @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_struct *work)
> struct folio *folio = page_folio(pageref->page);
>
> folio_lock(folio);
> - folio_mkclean(folio);
> +
On Wed, Jan 08, 2025 at 04:18:40PM +, Lorenzo Stoakes wrote:
> +/*
> + * rmap_walk_file - do something to file page using the object-based rmap
> method
> + * @folio: the folio to be handled
> + * @rwc: control variable according to each walk type
> + * @locked: caller holds relevant rmap lock
On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> You could have static const within functions too. You get the rodata
> protection and function local scope, best of both worlds?
timer_active is on the stack, so it can't be static const.
Does this really need to be cc'd to such a wid
On Mon, Jan 13, 2025 at 11:34:53AM +0200, Kirill A. Shutemov wrote:
> diff --git a/mm/migrate.c b/mm/migrate.c
> index caadbe393aa2..beba72da5e33 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -686,6 +686,8 @@ void folio_migrate_flags(struct folio *newfolio, struct
> folio *folio)
>
On Mon, Jan 13, 2025 at 11:34:45AM +0200, Kirill A. Shutemov wrote:
> Use PG_dropbehind instead of PG_reclaim and remove PG_reclaim.
I was hoping we'd end up with the name PG_reclaim instead of the name
PG_dropbehind. PG_reclaim is a better name for this functionality.
On Wed, Jan 08, 2025 at 09:14:53PM +0100, David Hildenbrand wrote:
> On 08.01.25 18:32, Matthew Wilcox wrote:
> > On Wed, Jan 08, 2025 at 04:18:42PM +, Lorenzo Stoakes wrote:
> > > @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_s
On Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote:
> On 08.01.25 21:54, Matthew Wilcox wrote:
> > Not necessarily! We already do that (since 2022) for DAX (see
> > 6a8e0596f004). rmap lets you find every place that a given range
> > of a file is mapped int
On Wed, Jan 15, 2025 at 11:31:29AM +0200, Kirill A. Shutemov wrote:
> -static void lru_deactivate_file(struct lruvec *lruvec, struct folio *folio)
> -{
> - bool active = folio_test_active(folio) || lru_gen_enabled();
> - long nr_pages = folio_nr_pages(folio);
> -
> - if (folio_test_unev
On Fri, Feb 21, 2025 at 05:53:16PM +, Lorenzo Stoakes wrote:
> On Fri, Feb 21, 2025 at 05:31:29PM +0000, Matthew Wilcox (Oracle) wrote:
> > There is no need to print out page->index as part of the debug message.
> >
> > Signed-off-by: Matthew Wilcox (Oracle)
On Thu, Mar 06, 2025 at 12:25:53AM +0900, Ryosuke Yasuoka wrote:
> Some drivers can use vmap in drm_panic, however, vmap is sleepable and
> takes locks. Since drm_panic will vmap in panic handler, atomic_vmap
> requests pages with GFP_ATOMIC and maps KVA without locks and sleep.
In addition to the
On Wed, Mar 05, 2025 at 08:39:17AM +0100, Simona Vetter wrote:
> On Tue, Mar 04, 2025 at 04:21:30PM +0000, Matthew Wilcox wrote:
> > On Fri, Feb 21, 2025 at 05:53:16PM +, Lorenzo Stoakes wrote:
> > > On Fri, Feb 21, 2025 at 05:31:29PM +0000, Matthew Wilcox (Oracle) wrote:
&
There's no need to give the page an address_space. Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's set now, and that was the only reason to
set the address_space in the first place.
Signed-off-by: Matthew Wilcox (Oracle)
---
There's no need to give the page an address_space. Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's handled now, and that was the only reason to
set the address_space in the first place.
Signed-off-by: Matthew Wilcox (Oracle)
All users are now converted to use the folio_batch so we can get rid of
this data structure.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 63 +++--
mm/swap.c | 18 ++--
2 files changed, 13 insertions(+), 68
These files no longer need pagevec.h, mostly due to function declarations
being moved out of it.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/fadvise.c| 1 -
mm/memory_hotplug.c | 1 -
mm/migrate.c| 1 -
mm/readahead.c | 1 -
mm/swap_state.c | 1 -
5 files changed, 5
This should always have been called folio_batch_count().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index 42aad53e382e..3a9d29dd28a3 100644
--- a
Removes a folio->page->folio conversion for each folio that's involved.
More importantly, removes one of the last few uses of a pagevec.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/afs/write.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/
Remove one of the last remaining users of pagevec.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/i915_gpu_error.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915
Remove a few hidden compound_head() calls by converting the returned
page to a folio once and using the folio APIs.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/drm_gem.c | 68 ++-
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a
All callers have now been converted to call check_move_unevictable_folios().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/swap.h | 1 -
mm/vmscan.c | 17 -
2 files changed, 18 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index
We're almost done with the pagevec -> folio_batch conversion. Finish
the job.
Matthew Wilcox (Oracle) (13):
afs: Convert pagevec to folio_batch in afs_extend_writeback()
mm: Add __folio_batch_release()
scatterlist: Add sg_set_folio()
i915: Convert shmem_sg_free_table()
This performs the same role as __pagevec_release(), ie skipping the
check for batch length of 0.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index
We don't use pagevecs for the LRU cache any more, and we don't know
that the failed invalidations were due to the folio being in an
LRU cache. So rename it to be more accurate.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/fadvise.c | 16 +++-
mm/internal.h |
: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 55 +--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 33d5d5178103..8f1633c3fb93 100644
--- a
olios.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/scatterlist.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index ec46d8e8e49d..77df3d7b18a6 100644
--- a/include/linux/scatterlist.h
+++ b/include/
Most of these should just refer to the LRU cache rather than the
data structure used to implement the LRU cache.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/huge_memory.c| 2 +-
mm/khugepaged.c | 6 +++---
mm/ksm.c| 6 +++---
mm/memory.c | 6 +++---
mm
Remove the last usage of pagevecs. There is a slight change here; we
now free the folio_batch as soon as it fills up instead of freeing the
folio_batch when we try to add a page to a full batch. This should have
no effect in practice.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux
functions may also have been affected.
Clamp the length of the last entry in the sg list to be the expected
length.
Signed-off-by: Matthew Wilcox (Oracle)
Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Cc: sta...@vger.kernel.org # 6.5.x
L
If the shared memory object is larger than the DRM object that it backs,
we can overrun the page array. Limit the number of pages we install
from each folio to prevent this.
Signed-off-by: Matthew Wilcox (Oracle)
Reported-by: Oleksandr Natalenko
Tested-by: Oleksandr Natalenko
Link: https
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
mtd NOR driver.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/mtd/maps/Kconfig| 7 -
drivers/mtd/maps/Makefile | 1 -
drivers/mtd/maps
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
fbdev driver and the backlight driver.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/video/backlight/Kconfig |7 -
drivers/video/backlight
There is no need to print out page->index as part of the debug message.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/staging/fbtft/fbtft-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-cor
201 - 278 of 278 matches
Mail list logo
