On Mon, Nov 4, 2019 at 11:41 AM Rajat Jain wrote:
>
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted to a
From: Jason Gunthorpe
Replace the internal interval tree based mmu notifier with the new common
mmu_interval_notifier_insert() API. This removes a lot of code and fixes a
deadlock that can be triggered in ODP:
zap_page_range()
mmu_notifier_invalidate_range_start()
[..]
On Mon, Nov 11, 2019 at 04:06:45PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_interval_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that
On Tue, 12 Nov 2019, Daniel Vetter wrote:
On Tue, Nov 12, 2019 at 08:09:09PM +0300, Wambui Karuga wrote:
Add the DRM_DEV_WARN helper macro for printing warnings
that use device pointers in their log output format.
DRM_DEV_WARN can replace the use of dev_warn in such cases.
Signed-off-by:
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid == true
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 95
ping
On 2019/10/31 21:41, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function vmw_hw_surface_destroy:
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:335:22: warning: variable srf set but
> not used [-Wunused-but-set-variable]
>
>
ADV7511 support sample rates up to 192kHz. CTS and N parameters should
be computed accordingly so this commit extend the list up to maximum
supported sample rate.
Signed-off-by: Bogdan Togorean
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12
1 file changed, 12
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_interval_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
On Tue, Nov 12, 2019 at 01:10:13PM +0100, Torsten Duwe wrote:
> On Tue, Nov 12, 2019 at 10:22:39AM +0100, Maxime Ripard wrote:
> > Hi Thorsten,
> >
> > On Mon, Nov 11, 2019 at 11:53:20PM +0800, kbuild test robot wrote:
> > >
> > >drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:48:20: error:
Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
support"), command-mode panels began throwing the following errors:
msm fd90.mdss: pp done time out, lm=0
Let's fix this by enabling the autorefresh feature that's available in
the MDP starting at version 1.0. This
On Tue, Nov 12, 2019 at 3:49 AM Brian Masney wrote:
>
> Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
> support"), command-mode panels began throwing the following errors:
>
> msm fd90.mdss: pp done time out, lm=0
>
> Let's fix this by enabling the autorefresh
From: Jason Gunthorpe
This converts one of the two users of mmu_notifiers to use the new API.
The conversion is fairly straightforward, however the existing use of
notifiers here seems to be racey.
Tested-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
---
On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote:
> On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
> >
> > On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> > ...
> > >> -}
> > >> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags |
> > >> FOLL_LONGTERM,
> > >>
On Mon, Nov 11, 2019 at 04:06:48PM -0800, John Hubbard wrote:
> @@ -542,7 +541,7 @@ static int ib_umem_odp_map_dma_single_page(
> }
>
> out:
> - put_user_page(page);
> + put_page(page);
>
> if (remove_existing_mapping) {
>
On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote:
> Hi,
>
> The cover letter is long, so the more important stuff is first:
>
> * Jason, if you or someone could look at the the VFIO cleanup (patch 8)
> and conversion to FOLL_PIN (patch 18), to make sure it's use of
> remote and
Hi Thorsten,
On Mon, Nov 11, 2019 at 11:53:20PM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> head: 6aa192698089b450b06d609355fc9c82c07856d2
> commit: 6aa192698089b450b06d609355fc9c82c07856d2 [5/5] drm/bridge: Add
> Analogix anx6345
On Tue, Nov 12, 2019 at 10:22:39AM +0100, Maxime Ripard wrote:
> Hi Thorsten,
>
> On Mon, Nov 11, 2019 at 11:53:20PM +0800, kbuild test robot wrote:
> >
> >drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:48:20: error: field
> > 'bridge' has incomplete type
> > struct drm_bridge
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_interval_notifier
Add the DRM_DEV_WARN helper macro for printing warnings
that use device pointers in their log output format.
DRM_DEV_WARN can replace the use of dev_warn in such cases.
Signed-off-by: Wambui Karuga
---
include/drm/drm_print.h | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_interval_notifier_insert())
support overlapping ranges directly. Simply delete all this code.
Since this
ADV7511 support I2S or SPDIF as audio input interfaces. This commit
enable support for SPDIF.
Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
The driver assumes that the platform uses the device tree, and thus relies
on some fields (of_node) being declared in some structures (drm_bridge).
This isn't true for all platforms, so make sure we can only compile the
ANX6345 on platforms where DT support is selected.
Cc: Torsten Duwe
Fixes:
Hi folks,
What do you think about:
> For the sysfs approach, I'm assuming the upstream vendors still need
> to provide a pair of UMD and KMD, and this ioctl to label the BO is
> kept as driver private ioctl. Then will each driver just define their
> own set of "label"s and the KMD will only
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Tested-by: Ralph Campbell
On Mon, Nov 11, 2019 at 07:51:22AM -0700, Jeffrey Hugo wrote:
> On Mon, Nov 11, 2019 at 4:38 AM Brian Masney wrote:
> >
> > On Sun, Nov 10, 2019 at 10:37:33AM -0700, Jeffrey Hugo wrote:
> > > On Sun, Nov 10, 2019 at 6:53 AM Brian Masney
> > > wrote:
> > > >
> > > > On Fri, Nov 08, 2019 at
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind
From: Jason Gunthorpe
gntdev simply wants to monitor a specific VMA for any notifier events,
this can be done straightforwardly using mmu_interval_notifier_insert()
over the VMA's VA range.
The notifier should be attached until the original VMA is destroyed.
It is unclear if any of this is
Fix the warnings that show up with W=1.
They are all about unused but set variables.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_dp_mst_topology.c | 50 +--
1 file changed, 19 insertions(+), 31 deletions(-)
diff --git
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell
On Tue, Nov 12, 2019 at 5:40 PM Daniel Vetter wrote:
>
> On Sat, Nov 09, 2019 at 03:54:17PM +0800, Chuhong Yuan wrote:
> > drm_put_dev also calls drm_dev_unregister, so dev will be unregistered
> > twice.
> > Replace it with drm_dev_put to fix it.
> >
> > Signed-off-by: Chuhong Yuan
>
> Nice
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c: In function
fiji_populate_smc_boot_level:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:1605:6: warning:
variable result set but not used [-Wunused-but-set-variable]
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
Hi,
> > > I guess ... but kinda awkward to leave this issue in here, it's really
> > > surprising if you call the pte shootdown function, and it doesn't work as
> > > advertised.
> >
> > I was mainly wondering how this worked for us and how to hit it not
> > working to test fixing it.
> >
> >
On Wed, Nov 13, 2019 at 8:27 AM Christoph Hellwig wrote:
>
> On Tue, Nov 12, 2019 at 10:24:23PM +, Luis Chamberlain wrote:
> > I think this would be possible if we could flop ioremap_nocache() to UC
> > instead of UC- on x86. Otherwise, I can't see how we can remove this by
> > still not
Hi,
> > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > >> These changes should be transparent.
> > > >
> > > > There's still the issue that for dma-buf mmap vs drm mmap you use
> > > > different f_mapping, which means ttm's pte shootdown won't work
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=112254
Andre Klapper changed:
What|Removed |Added
Product|DRI |Spam
Version|XOrg git
add compute/gfx dispatch hang test for gfx9
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 12 +++
tests/amdgpu/amdgpu_test.h| 1 +
tests/amdgpu/basic_tests.c| 67 ---
tests/amdgpu/deadlock_tests.c | 14
4 files changed, 81
for gfx9
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 6 +
tests/amdgpu/amdgpu_test.h| 2 +
tests/amdgpu/basic_tests.c| 239 --
tests/amdgpu/deadlock_tests.c | 18 +++
4 files changed, 251 insertions(+), 14 deletions(-)
diff --git
add gfx/compute bad slow dispatch test for gfx9
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 12 ++
tests/amdgpu/amdgpu_test.h| 1 +
tests/amdgpu/basic_tests.c| 229 +-
tests/amdgpu/deadlock_tests.c | 14 +++
4 files changed, 255
for gfx9
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 5 +
tests/amdgpu/amdgpu_test.h| 3 ++-
tests/amdgpu/basic_tests.c| 41 ---
tests/amdgpu/deadlock_tests.c | 20 +
4 files changed, 55 insertions(+), 14
On 11/12/19 8:26 PM, John Hubbard wrote:
> OK, here we go. Any VFIO and Infiniband runtime testing from anyone, is
> especially welcome here.
>
Oh, and to make that easier, there is a git repo and branch, here:
g...@github.com:johnhubbard/linux.git pin_user_pages_tracking_v4
thanks,
--
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented.
The pin_longterm*() variants also set FOLL_LONGTERM, in addition
to FOLL_PIN:
pin_user_pages()
Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
have been converted to pin_longterm_pages(), lock it down:
1) Add an assertion to get_user_pages(), preventing callers from
passing FOLL_LONGTERM (in addition to the existing assertion that
prevents FOLL_PIN).
2) Remove the
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Signed-off-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git
OK, here we go. Any VFIO and Infiniband runtime testing from anyone, is
especially welcome here.
Changes since v3:
* VFIO fix (patch 8): applied further cleanup: removed a pre-existing,
unnecessary release and reacquire of mmap_sem. Moved the DAX vma
checks from the vfio call site, to gup
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages().
Note that this effectively changes the
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.4-rc7 next-20191112]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use
On Mon, 4 Nov 2019 02:39:32 +0100, =?UTF-8?q?Andreas=20F=C3=A4rber?= wrote:
> Define a compatible string for Realtek RTD1619 SoC family.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied,
On Mon, 4 Nov 2019 02:39:27 +0100, =?UTF-8?q?Andreas=20F=C3=A4rber?= wrote:
> Define a compatible string for Realtek RTD1295 SoC family.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied,
On 11/12/19 5:35 PM, Dan Williams wrote:
> On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>>
>> On 11/12/19 4:58 PM, Dan Williams wrote:
>> ...
> It's not redundant relative to upstream which does not do anything the
> FOLL_LONGTERM in the gup-slow path... but I have not looked at
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
On Fri, Nov 08, 2019 at 04:09:54PM +, Ayan Halder wrote:
> On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz wrote:
> > There are afbc helpers available.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > ---
> > .../arm/display/komeda/komeda_format_caps.h | 1 -
> >
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Randy Dunlap
[ Upstream commit aae3394ef0ef90cf00a21133357448385f13a5d4 ]
The framebuffer options and devices menu is unintentionally split
or broken because some items in it do not depend on FB (including
several under omap and mmp).
Fix this by moving FB_CMDLINE, FB_NOTIFY, and
From: Sam Ravnborg
[ Upstream commit 60e5e48dba72c6b59a7a9c7686ba320766913368 ]
When a device tree set a display-timing using native-mode
then according to the bindings doc this should:
native-mode:
The native mode for the display, in case multiple
modes are provided.
When
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Jordan Crouse
[ Upstream commit 32aa27e15c28d3898ed6f9b3c98f95f34a81eab2 ]
The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU
On Tue, Nov 12, 2019 at 07:24:16PM +0100, Daniel Vetter wrote:
> On Tue, Nov 12, 2019 at 2:00 PM Mihail Atanassov
> wrote:
> >
> > On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> > > On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > > > It's possible to get
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.h
between commit:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
from Linus' tree and commits:
c113236718e8
On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>
> On 11/12/19 4:58 PM, Dan Williams wrote:
> ...
> >>> It's not redundant relative to upstream which does not do anything the
> >>> FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
> >>> 1-7 to see if something there made
Fix the build errors lead by
'commit 4039f0293bbd ("drm/komeda: Add option to print WARN- and INFO-level IRQ
events")'
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
1d85a299c4db ("drm/i915: Lower RM timeout to avoid DSI hard hangs")
from Linus' tree and commit:
41286861b4c9 ("drm/i915/tgl: Add DC3CO counter in i915_dmc_info")
from
On 11/12/19 4:58 PM, Dan Williams wrote:
...
It's not redundant relative to upstream which does not do anything the
FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
1-7 to see if something there made it redundant.
Oh, the hunk John had below for get_user_pages_remote()
On Tue, Nov 12, 2019 at 3:43 PM Jason Gunthorpe wrote:
>
> On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote:
> > On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
> > >
> > > On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> > > ...
> > > >> -}
> > > >> +ret =
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.c
between commits:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
2f216a850715 ("drm/i915: update rawclk also on resume")
from Linus' tree and commits:
5bcd53aa39f3
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_gt_pm.c
between commit:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
from Linus' tree and commit:
3e7abf814193 ("drm/i915: Extract GT render power state management")
from
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_types.h
between commit:
311a50e76a33 ("drm/i915: Add support for mandatory cmdparsing")
from Linus' tree and commits:
cdb736fa8b8b ("drm/i915: Use engine relative LRIs on context
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_context.c
between commit:
f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps")
from Linus' tree and commit:
a4e7ccdac38e ("drm/i915: Move context management under GEM")
1 - 100 of 247 matches
Mail list logo
