| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Claudio Suarez <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Zheyu Ma <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Zhen Lei <[email protected]>
Cc: Xiyu Yang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: William Kucharski <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Zheyu Ma <[email protected]>
Cc: Zhen Lei <[email protected]>
Cc: Xiyu Yang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated con2fb_map to the new value
before calling this function, but upon error con2fb_acquire_newinfo
reset it to the old value. Since I removed the call to fbcon_release
anyway that strange error path was sticking out like a sore thumb,
hence I removed it. Which also allows us to remove the oldidx
parameter from that function.
v2: Explain what's going on with oldidx and error paths (Sam)
v3: Drop unused variable (0day)
v4: Rebased over bisect fix in previous patch, unchagend end result.
Acked-by: Sam Ravnborg <[email protected]> (v2)
Acked-by: Thomas Zimmermann <[email protected]>
Cc: kernel test robot <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Du Cheng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It doesn't ever fail anymore.
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock (especially all the global variables), so the minor changes in
ordering of setup/cleanup do not matter.
v2: Explain a bit better why this is all correct (Sam)
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Du Cheng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It's only one flag and slightly tidier code.
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Claudio Suarez <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Allows us to delete a bunch of hand-rolled stuff using a timer plus a
separate work). Also to simplify the code we initialize the
cursor_work completely when we allocate the fbcon_ops structure,
instead of trying to cope with console re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
v2:
- Only INIT_DELAYED_WORK when kzalloc succeeded (Tetsuo)
- Explain that we replace both the timer and a work with the combined
delayed_work (Javier)
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Qing Wang <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter <[email protected]>
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Since I had to audit the entire fbcon load code I also spotted a wrong
function name in a comment in fbcon_startup(), which this patch also
fixes.
v2: Explain why we also fix the comment (Sam)
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Du Cheng <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Acked-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]> (v1)
Reviewed-by: Geert Uytterhoeven <[email protected]> (v1)
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Du Cheng <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Claudio Suarez <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
page_mapped_in_vma() sets nr_pages to 1, which is usually correct as we
only want to know about the precise page and not about other pages in
the folio. However, hugetlbfs does want to know about the entire hpage,
and using nr_pages to get the size of the hpage is wrong. We could
change page_mapped_in_vma() to special-case hugetlbfs pages, but it's
better to ignore nr_pages in page_vma_mapped_walk() and get the size
from the VMA instead.
Fixes: 2aff7a4755bed ("mm: Convert page_vma_mapped_walk to work on PFNs")
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Muchun Song <[email protected]>
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
[edit commit message, use hstate directly]
|
|
Simplify new_page() by unifying the THP and base page cases, and
handle orders other than 0 and HPAGE_PMD_ORDER correctly.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Reviewed-by: William Kucharski <[email protected]>
|
|
This wrapper around alloc_pages_vma() calls prep_transhuge_page(),
removing the obligation from the caller. This is in the same spirit
as __folio_alloc().
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Reviewed-by: William Kucharski <[email protected]>
|
|
Unify alloc_misplaced_dst_page() and alloc_misplaced_dst_page_thp().
Removes an assumption that compound pages are HPAGE_PMD_ORDER.
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Reviewed-by: William Kucharski <[email protected]>
|
|
This removes an assumption that a large folio is HPAGE_PMD_ORDER
as well as letting us remove the call to prep_transhuge_page()
and a few hidden calls to compound_head().
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Reviewed-by: William Kucharski <[email protected]>
|
|
Calling try_to_unmap() with TTU_SPLIT_HUGE_PMD and a folio that's not
mapped by a PMD causes oopses on arm64 because we now call page_folio()
on an invalid page. pmd_page() returns a valid page for non-leaf PMDs on
some architectures, so this bug escaped testing before now. Fix this bug
by delaying the call to pmd_page() until after we know the PMD is a leaf.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215804
Fixes: af28a988b313 ("mm/huge_memory: Convert __split_huge_pmd() to take a folio")
Reported-by: Zorro Lang <[email protected]>
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Tested-by: Zorro Lang <[email protected]>
|
|
The commit 73511edf8b19 ("dma-buf: specify usage while adding fences to
dma_resv obj v7") ported all the DRM drivers to use the newer fence API
that specifies the usage with the enum dma_resv_usage rather than doing
an explicit shared / exclusive distinction.
But the commit didn't do it properly in two callers of the vc4 driver,
leading to build errors.
Fixes: 73511edf8b19 ("dma-buf: specify usage while adding fences to dma_resv obj v7")
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Christian König <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the same, but
the SH1106 doesn't support the horizontal or vertical address modes.
Add support for this display driver. The default values for some of
the hardware settings are taken from the datasheet.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306,
only the basic page addressing mode is supported. This addressing mode
is not as easy to use compared to the currently supported horizontal
addressing mode, as the page address has to be set prior to writing
out each page, and each page must be written out separately as a result.
Also, there is no way to force the column address to wrap around early,
thus the column address must also be reset for each page to be accurate.
Add support for this addressing mode, with a flag to choose it. This
flag is designed to be set from the device info data structure, but
can be extended to be explicitly forced on through a device tree
property if such a need arises.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the same, but
the SH1106 doesn't support the horizontal or vertical address modes.
Add a compatible string for it.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd.
(http://www.sinowealth.com).
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The x86 MSI message data is 32 bits in total and is either in
compatibility or remappable format, see Intel Virtualization Technology
for Directed I/O, section 5.1.2.
Fixes: 6285aa50736 ("x86/msi: Provide msi message shadow structs")
Co-developed-by: Adrian-Ken Rueegsegger <[email protected]>
Signed-off-by: Adrian-Ken Rueegsegger <[email protected]>
Signed-off-by: Reto Buerki <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
This isn't included here any more since the removal of ww_mutex.h from
seqlock.h which causes a build break.
Signed-off-by: Christian König <[email protected]>
Acked-by: Shashank Sharma <[email protected]>
Fixes: e84815cbbc76 ("seqlock: drop seqcount_ww_mutex_t")
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Daniel pointed out that this series removes the last user of
seqcount_ww_mutex_t, so let's drop this.
Signed-off-by: Christian König <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Waiman Long <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: [email protected]
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This should be possible now since we don't have the distinction
between exclusive and shared fences any more.
The only possible pitfall is that a dma_fence would be reused during the
RCU grace period, but even that could be handled with a single extra check.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is now handled by the DMA-buf framework in the dma_resv obj.
Also remove the workaround inside VMWGFX to update the moving fence.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We have previously done that in the individual drivers but it is
more defensive to move that into the common code.
Dynamic attachments should wait for map operations to complete by themselves.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add an usage for submissions independent of implicit sync but still
interesting for memory management.
v2: cleanup the kerneldoc a bit
v3: separate amdgpu changes from this
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We only need to wait for kernel submissions here.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Always wait for kernel fences before kmap and not only for UVD kmaps.
Signed-off-by: Christian König <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Wait only for kernel fences before kmap or UVD direct submission.
This also makes sure that we always wait in amdgpu_bo_kmap() even when
returning a cached pointer.
Signed-off-by: Christian König <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add an usage for kernel submissions. Waiting for those are mandatory for
dynamic DMA-bufs.
As a precaution this patch also changes all occurrences where fences are
added as part of memory management in TTM, VMWGFX and i915 to use the
new value because it now becomes possible for drivers to ignore fences
with the WRITE usage.
v2: use "must" in documentation, fix whitespaces
v3: separate out some driver changes and better document why some
changes should still be part of this patch.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Rework the internals of the dma_resv object to allow adding more than one
write fence and remember for each fence what purpose it had.
This allows removing the workaround from amdgpu which used a container for
this instead.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
v3: fix a missing case in radeon
v4: rebase on nouveau changes, fix lockdep and temporary disable warning
v5: more documentation updates
v6: separate internal dma_resv changes from this patch, avoids to
disable warning temporary, rebase on upstream changes
v7: fix missed case in lima driver, minimize changes to i915_gem_busy_ioctl
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This change adds the dma_resv_usage enum and allows us to specify why a
dma_resv object is queried for its containing fences.
Additional to that a dma_resv_usage_rw() helper function is added to aid
retrieving the fences for a read or write userspace submission.
This is then deployed to the different query functions of the dma_resv
object and all of their users. When the write paratermer was previously
true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise.
v2: add KERNEL/OTHER in separate patch
v3: some kerneldoc suggestions by Daniel
v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in
the rebase pointed out by Bas.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When HS400 tuning is complete and HS400 is going to be activated, we
have to keep the current number of TAPs and should not overwrite them
with a hardcoded value. This was probably a copy&paste mistake when
upporting HS400 support from the BSP.
Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
Reported-by: Yoshihiro Shimoda <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Various spelling mistakes in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall <[email protected]>
Reviewed-by: Alain Volmat <[email protected]>
Signed-off-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Bernardo reported an error that Nathan bisected down to
(x86_64) defconfig+LTO_CLANG_FULL+X86_PMEM_LEGACY.
LTO vmlinux.o
ld.lld: error: <instantiation>:1:13: redefinition of 'found'
.set found, 0
^
<inline asm>:29:1: while in macro instantiation
extable_type_reg reg=%eax, type=(17 | ((0) << 16))
^
This appears to be another LTO specific issue similar to what was folded
into commit 4b5305decc84 ("x86/extable: Extend extable functionality"),
where the `.set found, 0` in DEFINE_EXTABLE_TYPE_REG in
arch/x86/include/asm/asm.h conflicts with the symbol for the static
function `found` in arch/x86/kernel/pmem.c.
Assembler .set directive declare symbols with global visibility, so the
assembler may not rename such symbols in the event of a conflict. LTO
could rename static functions if there was a conflict in C sources, but
it cannot see into symbols defined in inline asm.
The symbols are also retained in the symbol table, regardless of LTO.
Give the symbols .L prefixes making them locally visible, so that they
may be renamed for LTO to avoid conflicts, and to drop them from the
symbol table regardless of LTO.
Fixes: 4b5305decc84 ("x86/extable: Extend extable functionality")
Reported-by: Bernardo Meurer Costa <[email protected]>
Debugged-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Clang can inline emit_indirect_jump() and then folds constants, which
results in:
| vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x6a4: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40
| vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x67d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40
| vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x386: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20
| vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x35d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20
Suppress the optimization such that it must emit a code reference to
the __x86_indirect_thunk_array[] base.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
|
|
In other places of the driver the string hdmi_rejection_pll is
used instead of the truncated hdmi_rejec_pll, so use this string
instead to be consistent.
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't mark static functions as kernel-doc.
Prevents multiple kernel-doc build warnings:
drivers/gpu/drm/sti/sti_hdmi.c:187: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* HDMI interrupt handler threaded
drivers/gpu/drm/sti/sti_hdmi.c:219: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* HDMI interrupt handler
drivers/gpu/drm/sti/sti_hdmi.c:241: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Set hdmi active area depending on the drm display mode selected
drivers/gpu/drm/sti/sti_hdmi.c:262: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Overall hdmi configuration
drivers/gpu/drm/sti/sti_hdmi.c:340: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Helper to concatenate infoframe in 32 bits word
drivers/gpu/drm/sti/sti_hdmi.c:357: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Helper to write info frame
drivers/gpu/drm/sti/sti_hdmi.c:427: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Prepare and configure the AVI infoframe
drivers/gpu/drm/sti/sti_hdmi.c:470: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Prepare and configure the AUDIO infoframe
drivers/gpu/drm/sti/sti_hdmi.c:555: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Software reset of the hdmi subsystem
Fixes: 5402626c83a2 ("drm: sti: add HDMI driver")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Aditya Srivastava <[email protected]>
Cc: Benjamin Gaignard <[email protected]>
Cc: Alain Volmat <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Acked-by: Alain Volmat <[email protected]>
Signed-off-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The two bugs are here:
if (encoder) {
if (bridge && bridge->timings)
The list iterator value 'encoder/bridge' will *always* be set and
non-NULL by drm_for_each_encoder()/list_for_each_entry(), so it is
incorrect to assume that the iterator value will be NULL if the
list is empty or no element is found.
To fix the bug, use a new variable '*_iter' as the list iterator,
while use the old variable 'encoder/bridge' as a dedicated pointer
to point to the found element.
Cc: [email protected]
Fixes: 99e360442f223 ("drm/stm: Fix bus_flags handling")
Signed-off-by: Xiaomeng Tong <[email protected]>
Acked-by: Raphael Gallais-Pou <[email protected]>
Signed-off-by: Philippe Cornu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When a slip driver is detaching, the slip_close() will act to
cleanup necessary resources and sl->tty is set to NULL in
slip_close(). Meanwhile, the packet we transmit is blocked,
sl_tx_timeout() will be called. Although slip_close() and
sl_tx_timeout() use sl->lock to synchronize, we don`t judge
whether sl->tty equals to NULL in sl_tx_timeout() and the
null pointer dereference bug will happen.
(Thread 1) | (Thread 2)
| slip_close()
| spin_lock_bh(&sl->lock)
| ...
... | sl->tty = NULL //(1)
sl_tx_timeout() | spin_unlock_bh(&sl->lock)
spin_lock(&sl->lock); |
... | ...
tty_chars_in_buffer(sl->tty)|
if (tty->ops->..) //(2) |
... | synchronize_rcu()
We set NULL to sl->tty in position (1) and dereference sl->tty
in position (2).
This patch adds check in sl_tx_timeout(). If sl->tty equals to
NULL, sl_tx_timeout() will goto out.
Signed-off-by: Duoming Zhou <[email protected]>
Reviewed-by: Jiri Slaby <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Alexei Starovoitov says:
====================
pull-request: bpf 2022-04-06
We've added 8 non-merge commits during the last 8 day(s) which contain
a total of 9 files changed, 139 insertions(+), 36 deletions(-).
The main changes are:
1) rethook related fixes, from Jiri and Masami.
2) Fix the case when tracing bpf prog is attached to struct_ops, from Martin.
3) Support dual-stack sockets in bpf_tcp_check_syncookie, from Maxim.
* https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
bpf: Adjust bpf_tcp_check_syncookie selftest to test dual-stack sockets
bpf: Support dual-stack sockets in bpf_tcp_check_syncookie
bpf: selftests: Test fentry tracing a struct_ops program
bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT
rethook: Fix to use WRITE_ONCE() for rethook:: Handler
selftests/bpf: Fix warning comparing pointer to 0
bpf: Fix sparse warnings in kprobe_multi_resolve_syms
bpftool: Explicit errno handling in skeletons
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|