Maxime Ripard [Thu, 17 May 2018 13:37:59 +0000 (15:37 +0200)]
drm/vc4: plane: Expand the lower bits by repeating the higher bits
The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.
This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we can't check the display output in a reliable way by doing a
software composition and an hardware one and compare both.
To prevent this, force the same behaviour so that we can do such things.
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id -> 1c8f422059ae ("mm: change return type to
vm_fault_t")
Eric Anholt [Wed, 9 May 2018 00:14:25 +0000 (17:14 -0700)]
drm: Fix render node numbering regression from control node removal.
drm_minor_alloc() does multiplication on this enum, so the removal
ended up moving render nodes down from 128 base to 64. This caused
Mesa's surfaceless backend to be unable to open the render nodes,
since it was still looking up at 128.
Shashank Sharma [Tue, 8 May 2018 11:09:45 +0000 (16:39 +0530)]
drm: Add and handle new aspect ratios in DRM layer
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.
The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Shashank Sharma [Tue, 8 May 2018 11:09:44 +0000 (16:39 +0530)]
drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Lin, Jia <lin.a.jia@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Ankit Nautiyal [Tue, 8 May 2018 11:09:43 +0000 (16:39 +0530)]
drm: Expose modes with aspect ratio, only if requested
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio information, from the
drm_mode_get_connector modelist supplied to the user, if the
user-space has not set the aspect ratio DRM client cap. However if
such a mode is unique in the list, it is kept in the list, with
aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
the list of exposed modes.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
instead only flags bits of user mode are reset (if aspect-ratio
is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
logic to correctly identify and prune modes with aspect-ratio,
if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
drm_mode_display to traverse the list of exposed modes and
avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the
pruning logic to avoid any dependency in the order of mode with
aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Tue, 8 May 2018 11:09:42 +0000 (16:39 +0530)]
drm: Handle aspect ratio info in legacy modeset path
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.
This patch:
1. rejects the modes with aspect-ratio info, during modeset, if the
user does not support aspect ratio.
2. does not load the aspect-ratio info in user-mode structure, if
aspect ratio is not supported.
3. adds helper functions for determining if aspect-ratio is expected
in user-mode and for allowing/disallowing the aspect-ratio, if its
not expected.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
V10: Modified the commit-message
V11: rebase
V12: Merged the patch for adding aspect-ratio helper functions
with this patch.
V13: Minor modifications as suggested by Ville.
V14: Removed helper functions, as they were used only once in legacy
modeset path, as suggested by Daniel Vetter.
Ankit Nautiyal [Tue, 8 May 2018 11:09:41 +0000 (16:39 +0530)]
drm: Add DRM client cap for aspect-ratio
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a new drm client cap is required to enable a non-atomic
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.
This patch adds the client cap for aspect-ratio.
Since no atomic-userspaces blow up on receiving aspect-ratio
information, the client cap for aspect-ratio is always enabled
for atomic clients.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: As suggested by Daniel Vetter and Ville Syrjala,
always enable aspect-ratio client cap for atomic userspaces,
if no atomic userspace breaks on aspect-ratio bits.
V13: rebase
V14: rebase
Ville Syrjälä [Tue, 8 May 2018 11:09:39 +0000 (16:39 +0530)]
drm/edid: Don't send bogus aspect ratios in AVI infoframes
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:38 +0000 (16:39 +0530)]
drm/edid: Fix cea mode aspect ratio handling
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.
Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:37 +0000 (16:39 +0530)]
drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.
Matt Atwood [Fri, 4 May 2018 22:18:00 +0000 (15:18 -0700)]
drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address 0000eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch
v10: DPCD_REV_XX to DP_DPCD_REV_XX
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180508092739.GB661@mwanda
Ezequiel Garcia [Fri, 4 May 2018 18:00:37 +0000 (15:00 -0300)]
dma-buf: Remove unneeded stubs around sync_debug interfaces
The sync_debug.h header is internal, and only used by
sw_sync.c. Therefore, SW_SYNC is always defined and there
is no need for the stubs. Remove them and make the code
simpler.
drm/i915: Do not adjust scale when out of bounds, v2.
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where the screen didn't show what was requested, and now
instead we reject it outright. This simplifies check_sprite_plane a lot.
Changes since v1:
- Set crtc_h to the height correctly.
- Reject < 3x3 rectangles instead of making them invisible for <gen9.
For gen9+ skl_update_scaler_plane will reject them.
drm/rect: Handle rounding errors in drm_rect_clip_scaled, v3.
Instead of relying on a scale which may increase rounding errors,
clip src by doing: src * (dst - clip) / dst and rounding the result
away from 1, so the new coordinates get closer to 1. We won't need
to fix up with a magic macro afterwards, because our scaling factor
will never go to the other side of 1.
Changes since v1:
- Adjust dst immediately, else drm_rect_width/height on dst gives bogus
results.
Change since v2:
- Get rid of macros and use 64-bits math.
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Jia-Ju Bai [Wed, 11 Apr 2018 08:33:42 +0000 (16:33 +0800)]
gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe
adv7511_probe() is never called in atomic context.
This function is only set as ".probe" in struct i2c_driver.
Despite never getting called from atomic context, adv7511_probe()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Dave Airlie [Fri, 4 May 2018 00:31:10 +0000 (10:31 +1000)]
Merge tag 'drm-intel-next-2018-04-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
First drm/i915 feature batch heading for v4.18:
- drm-next backmerge to fix build (Rodrigo)
- GPU documentation improvements (Kevin)
- GuC and HuC refactoring, host/GuC communication, logging, fixes, and more
(mostly Michal and Michał, also Jackie, Michel and Piotr)
- PSR and PSR2 enabling and fixes (DK, José, Rodrigo and Chris)
- Selftest updates (Chris, Daniele)
- DPLL management refactoring (Lucas)
- DP MST fixes (Lyude and DK)
- Watermark refactoring and changes to support NV12 (Mahesh)
- NV12 prep work (Chandra)
- Icelake Combo PHY enablers (Manasi)
- Perf OA refactoring and ICL enabling (Lionel)
- ICL enabling (Oscar, Paulo, Nabendu, Mika, Kelvin, Michel)
- Workarounds refactoring (Oscar)
- HDCP fixes and improvements (Ramalingam, Radhakrishna)
- Power management fixes (Imre)
- Various display fixes (Maarten, Ville, Vidya, Jani, Gaurav)
- debugfs for FIFO underrun clearing (Maarten)
- Execlist improvements (Chris)
- Reset improvements (Chris)
- Plenty of things here and there I overlooked and/or didn't understand... (Everyone)
Eric Anholt [Mon, 30 Apr 2018 18:10:58 +0000 (11:10 -0700)]
drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+
This driver will be used to support Mesa on the Broadcom 7268 and 7278
platforms.
V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
complicated CL/shader validation scheme. This massively changes the
GEM behavior, so I've forked off to a new driver.
v2: Mark SUBMIT_CL as needing DRM_AUTH. coccinelle fixes from kbuild
test robot. Drop personal git link from MAINTAINERS. Don't
double-map dma-buf imported BOs. Add kerneldoc about needing MMU
eviction. Drop prime vmap/unmap stubs. Delay mmap offset setup
to mmap time. Use drm_dev_init instead of _alloc. Use
ktime_get() for wait_bo timeouts. Drop drm_can_sleep() usage,
since we don't modeset. Switch page tables back to WC (debug
change to coherent had slipped in). Switch
drm_gem_object_unreference_unlocked() to
drm_gem_object_put_unlocked(). Simplify overflow mem handling by
not sharing overflow mem between jobs.
v3: no changes
v4: align submit_cl to 64 bits (review by airlied), check zero flags in
other ioctls.
Eric Anholt [Mon, 30 Apr 2018 23:59:27 +0000 (16:59 -0700)]
drm/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.
I had originally asked Stefan Schake to drop the pad field from the
syncobj changes that just landed, because I couldn't come up with a
reason to align to 64 bits.
Talking with Dave Airlie about the new v3d driver's submit ioctl, we
came up with a reason: sizeof() on 64-bit platforms may align to 64
bits, in which case the userspace will be submitting the aligned size
and the final 32 bits won't be zero-padded by the kernel. If
userspace doesn't zero-fill, then a future ABI change adding a 32-bit
field at the end could potentially cause the kernel to read undefined
data from old userspace (our userspace happens to use structure
initialization that zero-fills, but as a general rule we try not to
rely on that in the kernel).
Linus Walleij [Thu, 3 May 2018 14:04:31 +0000 (16:04 +0200)]
drm/pl111: Fix module probe bug
Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
Added a second module using the builtin_platform_driver() call,
which works fine as long as you do not try to build the PL111
driver as a module, because a module can only have one initcall
and cause the following build bug:
(...) multiple definition of `init_module' (...)
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Eric Anholt <eric@anholt.net> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180503140431.5798-1-linus.walleij@linaro.org
Daniel Vetter [Fri, 20 Apr 2018 06:51:59 +0000 (08:51 +0200)]
drm: remove all control node code
With the ioctl and driver prep done, we can remove everything else.
Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-4-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 3 May 2018 09:31:07 +0000 (11:31 +0200)]
drm/msm: Don't setup control node debugfs files
It's going away.
v2: Try harder to find them all.
Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Nicolas Dechesne <nicolas.dechesne@linaro.org> Cc: Archit Taneja <architt@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180503093107.25955-1-daniel.vetter@ffwll.ch
drm/atomic: Handling the case when setting old crtc for plane
In the func drm_atomic_set_crtc_for_plane, with the current code,
if crtc of the plane_state and crtc passed as argument to the func
are same, entire func will executed in vein.
It will get state of crtc and clear and set the bits in plane_mask.
All these steps are not required for same old crtc.
Ideally, we should do nothing in this case, this patch handles the same,
and causes the program to return without doing anything in such scenario.
I shouldn't have pushed this, CI was right - I failed to remove the
BUG_ON(!ops->wait);
Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
dma-buf/fence: add fence_wait_any_timeout function v2
there was a restriction added that this only works if the dma-fence
uses the dma_fence_default_wait hook. Which works for amdgpu, which is
the only caller. Well, until you share some buffers with e.g. i915,
then you get an -EINVAL.
But there's really no reason for this, because all drivers must
support callbacks. The special ->wait hook is only as an optimization;
if the driver needs to create a worker thread for an active callback,
then it can avoid to do that if it knows that there's a process
context available already. So ->wait is just an optimization, just
using the logic in dma_fence_default_wait() should work for all
drivers.
Let's remove this restriction.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180427061724.28497-5-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 27 Apr 2018 06:17:10 +0000 (08:17 +0200)]
dma-fence: Make ->enable_signaling optional
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
Daniel Vetter [Wed, 2 May 2018 08:23:59 +0000 (10:23 +0200)]
dma-fence: remove fill_driver_data callback
Noticed while I was typing docs. Entirely unused.
v2: Remove reference in @timeline_value_str too. While at it clarify
why timeline_value_str has a fence parameter - we don't have an
explicit timeline structure unfortunately.
drm: Add fake controlD* symlinks for backwards compat
Since then Keith has also added real control nodes with a
proper&useable uapi in the form of drm leases.
It's time to remove the control node leftovers.
Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-1-daniel.vetter@ffwll.ch
Ville Syrjälä [Thu, 26 Apr 2018 14:16:31 +0000 (17:16 +0300)]
drm/rect: Fix drm_rect_rotation_inv() docs
An overeager sed has corrupted the drm_rect_rotation_inv()
documentation. Fix it up.
Looks like it wasn't entirely correct before the sed fail
either. We were missing _rect_ from the function names, which
also explains why the sed hit these by accident.
Linus Walleij [Wed, 2 May 2018 13:47:19 +0000 (15:47 +0200)]
drm/pl111: Enable device-specific assigned memory
The Versatile Express has 8 MB of dedicated video RAM (VRAM)
on the motherboard, which is what we should be using for the
PL111 if available. On this platform, the memory backplane
is constructed so that only this memory will work properly
with the CLCD on the motherboard, using any other memory
area just gives random snow on the display.
The CA9 Versatile Express also has a PL111 instance on its
core tile that can address all memory, and this does not
have the restriction.
The memory is assigned to the device using the memory-region
device tree property and a "shared-dma-pool" reserved
memory pool like this:
Linus Walleij [Wed, 2 May 2018 13:47:18 +0000 (15:47 +0200)]
drm/pl111: Support the Versatile Express
The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) display controller instances out to the single
SiI9022 bridge.
Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then parse the device
tree to see if there is a CLCD or HDLCD instance on the core
tile (also known as the daughterboard) by looking in the
root of the device tree for compatible nodes.
- If there is a HDLCD on the core tile, and there is a driver
for it, we exit probe and deactivate the motherboard CLCD.
We do not touch the DVI mux in this case, to make sure we
don't break HDLCD.
- If there is a CLCD on both the motherboard and the core tile
(only the CA9 has this) the core tile CLCD takes precedence
and get muxed to the DVI connector.
- Only if there is no working graphics on the core tile, the
motherboard CLCD is probed and muxed to the DVI connector.
Core tile graphics should always take precedence as it can
address all memory and is also faster, however the motherboard
CLCD is good to have around for diagnostics and testing.
It is possible to test the motherboard CLCD by setting the
status = "disabled" property on the core tile CLCD or
HDLCD.
Scale down the Versatile Express to 16BPP so we can support a
1024x768 display despite the bus bandwidth restrictions on this
platform. (The motherboard CLCD supports slightly lower
resolution.)
Blending win0 with the background color doesn't seem to work
correctly. We only get the background color, no matter the contents of
the win0 framebuffer. However, blending pre-multiplied color with the
default opaque black default background color is a no-op, so we can
just disable blending to get the correct result.
Sparse complains with following warning:
drivers/gpu/drm/vc4/vc4_v3d.c:222:1: warning: symbol
'vc4_allocate_bin_bo' was not declared. Should it be static?
Make vc4_allocate_bin static as it is not used outside of
vc4_v3d.c.
Tom Callaway [Mon, 23 Apr 2018 16:16:39 +0000 (12:16 -0400)]
drm/tinydrm/mi0283qt: Always set rotation value
The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a result, we need to always apply the
rotation value regardless of the display "on/off" state.
Moved the rotation setting code below out_enable:.
Dave Airlie [Sun, 29 Apr 2018 23:32:34 +0000 (09:32 +1000)]
Merge tag 'drm-misc-next-2018-04-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.18:
UAPI Changes:
- Add support for a generic plane alpha property to sun4i, rcar-du and atmel-hclcdc. (Maxime)
Core Changes:
- Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
- mode_valid return type fixes. (Luc)
- Handle zpos normalization in the core. (Peter)
Driver Changes:
- Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
- Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, Douglas)
- Add support for MIPI DSI to sun4i. (Maxime)
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"Another set of x86 related updates:
- Fix the long broken x32 version of the IPC user space headers which
was noticed by Arnd Bergman in course of his ongoing y2038 work.
GLIBC seems to have non broken private copies of these headers so
this went unnoticed.
- Two microcode fixlets which address some more fallout from the
recent modifications in that area:
- Unconditionally save the microcode patch, which was only saved
when CPU_HOTPLUG was enabled causing failures in the late
loading mechanism
- Make the later loader synchronization finally work under all
circumstances. It was exiting early and causing timeout failures
due to a missing synchronization point.
- Do not use mwait_play_dead() on AMD systems to prevent excessive
power consumption as the CPU cannot go into deep power states from
there.
- Address an annoying sparse warning due to lost type qualifiers of
the vmemmap and vmalloc base address constants.
- Prevent reserving crash kernel region on Xen PV as this leads to
the wrong perception that crash kernels actually work there which
is not the case. Xen PV has its own crash mechanism handled by the
hypervisor.
- Add missing TLB cpuid values to the table to make the printout on
certain machines correct.
- Enumerate the new CLDEMOTE instruction
- Fix an incorrect SPDX identifier
- Remove stale macros"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds
x86/setup: Do not reserve a crash kernel region if booted on Xen PV
x86/cpu/intel: Add missing TLB cpuid values
x86/smpboot: Don't use mwait_play_dead() on AMD systems
x86/mm: Make vmemmap and vmalloc base address constants unsigned long
x86/vector: Remove the unused macro FPU_IRQ
x86/vector: Remove the macro VECTOR_OFFSET_START
x86/cpufeatures: Enumerate cldemote instruction
x86/microcode: Do not exit early from __reload_late()
x86/microcode/intel: Save microcode patch unconditionally
x86/jailhouse: Fix incorrect SPDX identifier
Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 pti fixes from Thomas Gleixner:
"A set of updates for the x86/pti related code:
- Preserve r8-r11 in int $0x80. r8-r11 need to be preserved, but the
int$80 entry code removed that quite some time ago. Make it correct
again.
- A set of fixes for the Global Bit work which went into 4.17 and
caused a bunch of interesting regressions:
- Triggering a BUG in the page attribute code due to a missing
check for early boot stage
- Warnings in the page attribute code about holes in the kernel
text mapping which are caused by the freeing of the init code.
Handle such holes gracefully.
- Reduce the amount of kernel memory which is set global to the
actual text and do not incidentally overlap with data.
- Disable the global bit when RANDSTRUCT is enabled as it
partially defeats the hardening.
- Make the page protection setup correct for vma->page_prot
population again. The adjustment of the protections fell through
the crack during the Global bit rework and triggers warnings on
machines which do not support certain features, e.g. NX"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/entry/64/compat: Preserve r8-r11 in int $0x80
x86/pti: Filter at vma->vm_page_prot population
x86/pti: Disallow global kernel text with RANDSTRUCT
x86/pti: Reduce amount of kernel text allowed to be Global
x86/pti: Fix boot warning from Global-bit setting
x86/pti: Fix boot problems from Global-bit setting
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner:
"Two fixes from the timer departement:
- Fix a long standing issue in the NOHZ tick code which causes RB
tree corruption, delayed timers and other malfunctions. The cause
for this is code which modifies the expiry time of an enqueued
hrtimer.
- Revert the CLOCK_MONOTONIC/CLOCK_BOOTTIME unification due to
regression reports. Seems userspace _is_ relying on the documented
behaviour despite our hope that it wont"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME
tick/sched: Do not mess with an enqueued hrtimer
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Thomas Gleixner:
"The perf update contains the following bits:
x86:
- Prevent setting freeze_on_smi on PerfMon V1 CPUs to avoid #GP
perf stat:
- Keep the '/' event modifier separator in fallback, for example when
fallbacking from 'cpu/cpu-cycles/' to user level only, where it
should become 'cpu/cpu-cycles/u' and not 'cpu/cpu-cycles/:u' (Jiri
Olsa)
- Disable write_backward and other event attributes for !group events
in a group, fixing, for instance this group: '{cycles,msr/aperf/}:S'
that has leader sampling (:S) and where just the 'cycles', the
leader event, should have the write_backward attribute set, in this
case it all fails because the PMU where 'msr/aperf/' lives doesn't
accepts write_backward style sampling (Jiri Olsa)
- Only fall back group read for leader (Kan Liang)
- Fix core PMU alias list for x86 platform (Kan Liang)
- Print out hint for mixed PMU group error (Kan Liang)
- Fix duplicate PMU name for interval print (Kan Liang)
Core:
- Set main kernel end address properly when reading kernel and module
maps (Namhyung Kim)
perf mem:
- Fix incorrect entries and add missing man options (Sangwon Hong)
s/390:
- Remove s390 specific strcmp_cpuid_cmp function (Thomas Richter)
- Adapt 'perf test' case record+probe_libc_inet_pton.sh for s390
- Fix s390 undefined record__auxtrace_init() return value in 'perf
record' (Thomas Richter)"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1
perf stat: Fix duplicate PMU name for interval print
perf evsel: Only fall back group read for leader
perf stat: Print out hint for mixed PMU group error
perf pmu: Fix core PMU alias list for X86 platform
perf record: Fix s390 undefined record__auxtrace_init() return value
perf mem: Document incorrect and missing options
perf evsel: Disable write_backward for leader sampling group events
perf pmu: Fix pmu events parsing rule
perf stat: Keep the / modifier separator in fallback
perf test: Adapt test case record+probe_libc_inet_pton.sh for s390
perf list: Remove s390 specific strcmp_cpuid_cmp function
perf machine: Set main kernel end address properly
Merge tag 'for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Fix misc bugs and a regression for ext4"
* tag 'for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: add MODULE_SOFTDEP to ensure crc32c is included in the initramfs
ext4: fix bitmap position validation
ext4: set h_journal if there is a failure starting a reserved handle
ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS
Amir Goldstein [Mon, 5 Feb 2018 17:32:18 +0000 (19:32 +0200)]
<linux/stringhash.h>: fix end_name_hash() for 64bit long
The comment claims that this helper will try not to loose bits, but for
64bit long it looses the high bits before hashing 64bit long into 32bit
int. Use the helper hash_long() to do the right thing for 64bit long.
For 32bit long, there is no change.
All the callers of end_name_hash() either assign the result to
qstr->hash, which is u32 or return the result as an int value (e.g.
full_name_hash()). Change the helper return type to int to conform to
its users.
[ It took me a while to apply this, because my initial reaction to it
was - incorrectly - that it could make for slower code.
After having looked more at it, I take back all my complaints about
the patch, Amir was right and I was mis-reading things or just being
stupid.
I also don't worry too much about the possible performance impact of
this on 64-bit, since most architectures that actually care about
performance end up not using this very much (the dcache code is the
most performance-critical, but the word-at-a-time case uses its own
hashing anyway).
So this ends up being mostly used for filesystems that do their own
degraded hashing (usually because they want a case-insensitive
comparison function).
A _tiny_ worry remains, in that not everybody uses DCACHE_WORD_ACCESS,
and then this potentially makes things more expensive on 64-bit
architectures with slow or lacking multipliers even for the normal
case.
That said, realistically the only such architecture I can think of is
PA-RISC. Nobody really cares about performance on that, it's more of a
"look ma, I've got warts^W an odd machine" platform.
So the patch is fine, and all my initial worries were just misplaced
from not looking at this properly. - Linus ]
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Sterba [Sat, 28 Apr 2018 17:05:04 +0000 (19:05 +0200)]
MAINTAINERS: add myself as maintainer of AFFS
The AFFS filesystem is still in use by m68k community (Link #2), but as
there was no code activity and no maintainer, the filesystem appeared on
the list of candidates for staging/removal (Link #1).
I volunteer to act as a maintainer of AFFS to collect any fixes that
might show up and to guard fs/affs/ against another spring cleaning.
Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- two driver fixes
- better parameter check for the core
- Documentation updates
- part of a tree-wide HAS_DMA cleanup
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: sprd: Fix the i2c count issue
i2c: sprd: Prevent i2c accesses after suspend is called
i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()
Documentation/i2c: adopt kernel commenting style in examples
Documentation/i2c: sync docs with current state of i2c-tools
Documentation/i2c: whitespace cleanup
i2c: Remove depends on HAS_DMA in case of platform dependency
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
- crypto API regression that may cause sporadic alloc failures
- double-free bug in drbg
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: drbg - set freed buffers to NULL
crypto: api - fix finding algorithm currently being tested
Merge tag '4.17-rc2-smb3' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"A few security related fixes for SMB3, most importantly for SMB3.11
encryption"
* tag '4.17-rc2-smb3' of git://git.samba.org/sfrench/cifs-2.6:
cifs: smbd: Avoid allocating iov on the stack
cifs: smbd: Don't use RDMA read/write when signing is used
SMB311: Fix reconnect
SMB3: Fix 3.11 encryption to Windows and handle encrypted smb3 tcon
CIFS: set *resp_buf_type to NO_BUFFER on error
Merge tag 'powerpc-4.17-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"A bunch of fixes, mostly for existing code and going to stable.
Our memory hot-unplug path wasn't flushing the cache before removing
memory. That is a problem now that we are doing memory hotplug on bare
metal.
Three fixes for the NPU code that supports devices connected via
NVLink (ie. GPUs). The main one tweaks the TLB flush algorithm to
avoid soft lockups for large flushes.
A fix for our memory error handling where we would loop infinitely,
returning back to the bad access and hard lockup the CPU.
Fixes for the OPAL RTC driver, which wasn't handling some error cases
correctly.
A fix for a hardlockup in the powernv cpufreq driver.
And finally two fixes to our smp_send_stop(), required due to a recent
change to use it on shutdown.
Thanks to: Alistair Popple, Balbir Singh, Laurentiu Tudor, Mahesh
Salgaonkar, Mark Hairgrove, Nicholas Piggin, Rashmica Gupta, Shilpasri
G Bhat"
* tag 'powerpc-4.17-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/kvm/booke: Fix altivec related build break
powerpc: Fix deadlock with multiple calls to smp_send_stop
cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interrupt
powerpc: Fix smp_send_stop NMI IPI handling
rtc: opal: Fix OPAL RTC driver OPAL_BUSY loops
powerpc/mce: Fix a bug where mce loops on memory UE.
powerpc/powernv/npu: Do a PID GPU TLB flush when invalidating a large address range
powerpc/powernv/npu: Prevent overwriting of pnv_npu2_init_contex() callback parameters
powerpc/powernv/npu: Add lock to prevent race in concurrent context init/destroy
powerpc/powernv/memtrace: Let the arch hotunplug code flush cache
powerpc/mm: Flush cache on memory hot(un)plug
rMerge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Radim Krčmář:
"ARM:
- PSCI selection API, a leftover from 4.16 (for stable)
- Kick vcpu on active interrupt affinity change
- Plug a VMID allocation race on oversubscribed systems
- Silence debug messages
- Update Christoffer's email address (linaro -> arm)
x86:
- Expose userspace-relevant bits of a newly added feature
- Fix TLB flushing on VMX with VPID, but without EPT"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
x86/headers/UAPI: Move DISABLE_EXITS KVM capability bits to the UAPI
kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use
arm/arm64: KVM: Add PSCI version selection API
KVM: arm/arm64: vgic: Kick new VCPU on interrupt migration
arm64: KVM: Demote SVE and LORegion warnings to debug only
MAINTAINERS: Update e-mail address for Christoffer Dall
KVM: arm/arm64: Close VMID generation race
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Nothing too bad, but the spectre updates to smatch identified a few
places that may need sanitising so we've got those covered.
Details:
- Close some potential spectre-v1 vulnerabilities found by smatch
- Add missing list sentinel for CPUs that don't require KPTI
- Removal of unused 'addr' parameter for I/D cache coherency
- Removal of redundant set_fs(KERNEL_DS) calls in ptrace
- Fix single-stepping state machine handling in response to kernel
traps
- Clang support for 128-bit integers
- Avoid instrumenting our out-of-line atomics in preparation for
enabling LSE atomics by default in 4.18"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: avoid instrumenting atomic_ll_sc.o
KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_mmio_read_apr()
KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()
arm64: fix possible spectre-v1 in ptrace_hbp_get_event()
arm64: support __int128 with clang
arm64: only advance singlestep for user instruction traps
arm64/kernel: rename module_emit_adrp_veneer->module_emit_veneer_for_adrp
arm64: ptrace: remove addr_limit manipulation
arm64: mm: drop addr parameter from sync icache and dcache
arm64: add sentinel to kpti_safe_list
Merge tag 'ceph-for-4.17-rc3' of git://github.com/ceph/ceph-client
Pull ceph fixes from Ilya Dryomov:
"A CephFS quota follow-up and fixes for two older issues in the
messenger layer, marked for stable"
* tag 'ceph-for-4.17-rc3' of git://github.com/ceph/ceph-client:
libceph: validate con->state at the top of try_write()
libceph: reschedule a tick in finish_hunting()
libceph: un-backoff on tick when we have a authenticated session
ceph: check if mds create snaprealm when setting quota
Merge tag 'char-misc-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small char and misc driver fixes for 4.17-rc3
A variety of small things that have fallen out after 4.17-rc1 was out.
Some vboxguest fixes for systems with lots of memory, amba bus fixes,
some MAINTAINERS updates, uio_hv_generic driver fixes, and a few other
minor things that resolve problems that people reported.
The amba bus fixes took twice to get right, the first time I messed up
applying the patches in the wrong order, hence the revert and later
addition again with the correct fix, sorry about that.
All of these have been in linux-next with no reported issues"
* tag 'char-misc-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
ARM: amba: Fix race condition with driver_override
ARM: amba: Make driver_override output consistent with other buses
Revert "ARM: amba: Fix race condition with driver_override"
ARM: amba: Don't read past the end of sysfs "driver_override" buffer
ARM: amba: Fix race condition with driver_override
virt: vbox: Log an error when we fail to get the host version
virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory
virt: vbox: Add vbg_req_free() helper function
virt: vbox: Move declarations of vboxguest private functions to private header
slimbus: Fix out-of-bounds access in slim_slicesize()
MAINTAINERS: add dri-devel&linaro-mm for Android ION
fpga-manager: altera-ps-spi: preserve nCONFIG state
MAINTAINERS: update my email address
uio_hv_generic: fix subchannel ring mmap
uio_hv_generic: use correct channel in isr
uio_hv_generic: make ring buffer attribute for primary channel
uio_hv_generic: set size of ring buffer attribute
ANDROID: binder: prevent transactions into own process.
Merge tag 'driver-core-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg Kroah-Hartman:
"Here are some small driver core and firmware fixes for 4.17-rc3
There's a kobject WARN() removal to make syzkaller a lot happier about
some "normal" error paths that it keeps hitting, which should reduce
the number of false-positives we have been getting recently.
There's also some fimware test and documentation fixes, and the
coredump() function signature change that needed to happen after -rc1
before drivers started to take advantage of it.
All of these have been in linux-next with no reported issues"
* tag 'driver-core-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
firmware: some documentation fixes
selftests:firmware: fixes a call to a wrong function name
kobject: don't use WARN for registration failures
firmware: Fix firmware documentation for recent file renames
test_firmware: fix setting old custom fw path back on exit, second try
test_firmware: Install all scripts
drivers: change struct device_driver::coredump() return type to void
Merge tag 'tty-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some tty and serial driver fixes for reported issues for
4.17-rc3.
Nothing major, but a number of small things:
- device tree fixes/updates for serial ports
- earlycon fixes
- n_gsm fixes
- tty core change reverted to help resolve syszkaller reports
- other serial driver small fixes
All of these have been in linux-next with no reported issues"
* tag 'tty-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: Use __GFP_NOFAIL for tty_ldisc_get()
tty: serial: xuartps: Setup early console when uartclk is also passed
tty: Don't call panic() at tty_ldisc_init()
tty: Avoid possible error pointer dereference at tty_ldisc_restore().
dt-bindings: mvebu-uart: DT fix s/interrupts-names/interrupt-names/
tty: serial: qcom_geni_serial: Use signed variable to get IRQ
earlycon: Use a pointer table to fix __earlycon_table stride
serial: sh-sci: Document r8a77470 bindings
dt-bindings: meson-uart: DT fix s/clocks-names/clock-names/
serial: imx: fix cached UCR2 read on software reset
serial: imx: warn user when using unsupported configuration
serial: mvebu-uart: Fix local flags handling on termios update
tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set
tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
Merge tag 'staging-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging fixes from Greg KH:
"Here are two staging driver fixups for 4.17-rc3.
The first is the remaining stragglers of the irda code removal that
you pointed out during the merge window. The second is a fix for the
wilc1000 driver due to a patch that got merged in 4.17-rc1.
Both of these have been in linux-next for a while with no reported
issues"
* tag 'staging-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: wilc1000: fix NULL pointer exception in host_int_parse_assoc_resp_info()
staging: irda: remove remaining remants of irda code removal
Merge tag 'usb-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a number of USB driver fixes for reported problems for
4.17-rc3.
The "largest" here is a number of phy core changes for reported
problems with the -rc1 release. There's also the usual musb and xhci
fixes, as well as new device id updates. There are also some usbip
fixes for reported problems as more people start to use that code with
containers.
All of these have been in linux-next with no reported issues, except
the last few new device ids, which are "obviously correct" :)"
* tag 'usb-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (26 commits)
USB: musb: dsps: drop duplicate phy initialisation
USB: musb: host: prevent core phy initialisation
usb: core: phy: add the SPDX-License-Identifier and include guard
xhci: Fix Kernel oops in xhci dbgtty
usb: select USB_COMMON for usb role switch config
usb: core: phy: add missing forward declaration for "struct device"
usb: core: phy: make it a no-op if CONFIG_GENERIC_PHY is disabled
usb: core: use phy_exit during suspend if wake up is not supported
usb: core: split usb_phy_roothub_{init,alloc}
usb: core: phy: fix return value of usb_phy_roothub_exit()
usb: typec: ucsi: Increase command completion timeout value
Revert "xhci: plat: Register shutdown for xhci_plat"
usb: core: Add quirk for HP v222w 16GB Mini
Documentation: typec.rst: Use literal-block element with ascii art
usb: typec: ucsi: fix tracepoint related build error
usbip: usbip_event: fix to not print kernel pointer address
usbip: usbip_host: fix to hold parent lock for device_attach() calls
usbip: vhci_hcd: Fix usb device and sockfd leaks
usbip: vhci_hcd: check rhport before using in vhci_hub_control()
USB: Increment wakeup count on remote wakeup.
...
* tag 'sound-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (35 commits)
ALSA: dice: fix error path to destroy initialized stream data
ALSA: hda - Skip jack and others for non-existing PCM streams
ALSA: hda/realtek - change the location for one of two front mics
ALSA: rme9652: Hardening for potential Spectre v1
ALSA: hdspm: Hardening for potential Spectre v1
ALSA: asihpi: Hardening for potential Spectre v1
ALSA: opl3: Hardening for potential Spectre v1
ALSA: hda: Hardening for potential Spectre v1
ALSA: control: Hardening for potential Spectre v1
ALSA: seq: oss: Hardening for potential Spectre v1
ALSA: seq: oss: Fix unbalanced use lock for synth MIDI device
ALSA: hda/realtek - Update ALC255 depop optimize
ALSA: hda/realtek - Add some fixes for ALC233
ALSA: pcm: Change return type to vm_fault_t
ALSA: usx2y: Change return type to vm_fault_t
ALSA: usb-audio: ADC3: Fix channel mapping conversion for ADC3.
ALSA: dice: fix OUI for TC group
ALSA: usb-audio: Skip broken EU on Dell dock USB-audio
ALSA: usb-audio: Fix missing endian conversion
ALSA: usb-audio: Fix forgotten conversion of control query functions
...
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"This round of fixes has two larger changes that came in last week:
- a couple of patches all intended to finally turn on USB support on
various Amlogic SoC based boards. The respective driver were not
finalized until very late before the merge window and the DT
portion is the last bit now.
- a defconfig update for gemini that had repeatedly missed the cut
but that is required to actually boot any real machines with the
default build.
The rest are the usual small changes:
- a fix for a nasty build regression on the OMAP memory drivers
- a fix for a boot problem on Intel/Altera SocFPGA
- a MAINTAINER file update
- a couple of fixes for issues found by automated testing (kernelci,
coverity, sparse, ...)
- a few incorrect DT entries are updated to match the hardware"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: defconfig: Update Gemini defconfig
ARM: s3c24xx: jive: Fix some GPIO names
HISI LPC: Add Kconfig MFD_CORE dependency
ARM: dts: Fix NAS4220B pin config
MAINTAINERS: Remove myself as maintainer
arm64: dts: correct SATA addresses for Stingray
ARM64: dts: meson-gxm-khadas-vim2: enable the USB controller
ARM64: dts: meson-gxl-nexbox-a95x: enable the USB controller
ARM64: dts: meson-gxl-s905x-libretech-cc: enable the USB controller
ARM64: dts: meson-gx-p23x-q20x: enable the USB controller
ARM64: dts: meson-gxl-s905x-p212: enable the USB controller
ARM64: dts: meson-gxm: add GXM specific USB host configuration
ARM64: dts: meson-gxl: add USB host support
ARM: OMAP2+: Fix build when using split object directories
soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure
soc: bcm: raspberrypi-power: Fix use of __packed
ARM: dts: Fix cm2 and prm sizes for omap4
ARM: socfpga_defconfig: Remove QSPI Sector 4K size force
firmware: arm_scmi: remove redundant null check on array
arm64: dts: juno: drop unnecessary address-cells and size-cells properties
* tag 'drm-fixes-for-v4.17-rc3' of git://people.freedesktop.org/~airlied/linux: (27 commits)
drm/edid: Reset more of the display info
drm/virtio: fix vq wait_event condition
qxl: keep separate release_bo pointer
qxl: fix qxl_release_{map,unmap}
Revert "drm/sun4i: add lvds mode_valid function"
drm/amd/display: Check dc_sink every time in MST hotplug
drm/amd/display: Update MST edid property every time
drm/amd/display: Don't read EDID in atomic_check
drm/amd/display: Disallow enabling CRTC without primary plane with FB
drm/amd/display: Fix deadlock when flushing irq
drm/i915/fbdev: Enable late fbdev initial configuration
drm/i915: Use ktime on wait_for
drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders
drm/amdkfd: fix build, select MMU_NOTIFIER
drm/amdkfd: fix clock counter retrieval for node without GPU
drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()
drm/amdkfd: kfd_dev_is_large_bar() can be static
drm/i915: Enable display WA#1183 from its correct spot
drm/i915/audio: set minimum CD clock to twice the BCLK
drm/msm: don't deref error pointer in the msm_fbdev_create error path
...
kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use
Currently, KVM flushes the TLB after a change to the APIC access page
address or the APIC mode when EPT mode is enabled. However, even in
shadow paging mode, a TLB flush is needed if VPIDs are being used, as
specified in the Intel SDM Section 29.4.5.
So replace vmx_flush_tlb_ept_only() with vmx_flush_tlb(), which will
flush if either EPT or VPIDs are in use.
Andy Lutomirski [Tue, 17 Apr 2018 14:36:36 +0000 (07:36 -0700)]
x86/entry/64/compat: Preserve r8-r11 in int $0x80
32-bit user code that uses int $80 doesn't care about r8-r11. There is,
however, some 64-bit user code that intentionally uses int $0x80 to invoke
32-bit system calls. From what I've seen, basically all such code assumes
that r8-r15 are all preserved, but the kernel clobbers r8-r11. Since I
doubt that there's any code that depends on int $0x80 zeroing r8-r11,
change the kernel to preserve them.
I suspect that very little user code is broken by the old clobber, since
r8-r11 are only rarely allocated by gcc, and they're clobbered by function
calls, so they only way we'd see a problem is if the same function that
invokes int $0x80 also spills something important to one of these
registers.
The current behavior seems to date back to the historical commit
"[PATCH] x86-64 merge for 2.6.4". Before that, all regs were
preserved. I can't find any explanation of why this change was made.
Update the test_syscall_vdso_32 testcase as well to verify the new
behavior, and it strengthens the test to make sure that the kernel doesn't
accidentally permute r8..r15.
x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds
A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout
(as seen from user space) a few years ago: Originally, __BITS_PER_LONG
was defined as 64 on x32, so we did not have padding after the 64-bit
__kernel_time_t fields, After __BITS_PER_LONG got changed to 32,
applications would observe extra padding.
In other parts of the uapi headers we seem to have a mix of those
expecting either 32 or 64 on x32 applications, so we can't easily revert
the path that broke these two structures.
Instead, this patch decouples x32 from the other architectures and moves
it back into arch specific headers, partially reverting the even older
commit 73a2d096fdf2 ("x86: remove all now-duplicate header files").
It's not clear whether this ever made any difference, since at least
glibc carries its own (correct) copy of both of these header files,
so possibly no application has ever observed the definitions here.
Based on a suggestion from H.J. Lu, I tried out the tool from
https://github.com/hjl-tools/linux-header to find other such
bugs, which pointed out the same bug in statfs(), which also has
a separate (correct) copy in glibc.
Fixes: f4b4aae18288 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: "H . J . Lu" <hjl.tools@gmail.com> Cc: Jeffrey Walton <noloader@gmail.com> Cc: stable@vger.kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lkml.kernel.org/r/20180424212013.3967461-1-arnd@arndb.de
Petr Tesarik [Wed, 25 Apr 2018 10:08:35 +0000 (12:08 +0200)]
x86/setup: Do not reserve a crash kernel region if booted on Xen PV
Xen PV domains cannot shut down and start a crash kernel. Instead,
the crashing kernel makes a SCHEDOP_shutdown hypercall with the
reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
arch/x86/xen/enlighten_pv.c.
A crash kernel reservation is merely a waste of RAM in this case. It
may also confuse users of kexec_load(2) and/or kexec_file_load(2).
When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
respectively, these syscalls return success, which is technically
correct, but the crash kexec image will never be actually used.
Signed-off-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Juergen Gross <jgross@suse.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: xen-devel@lists.xenproject.org Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Borislav Petkov <bp@suse.de> Cc: Jean Delvare <jdelvare@suse.de> Link: https://lkml.kernel.org/r/20180425120835.23cef60c@ezekiel.suse.cz
drm/dp: Rename the edp_sdp_header as dp_sdp_header
No functional changes in this patch.
The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the comment to indicate the same.
Baolin Wang [Mon, 9 Apr 2018 06:40:55 +0000 (14:40 +0800)]
i2c: sprd: Fix the i2c count issue
We found the I2C controller count register is unreliable sometimes,
that will cause I2C to lose data. Thus we can read the data count
from 'i2c_dev->count' instead of the I2C controller count register.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Baolin Wang [Mon, 9 Apr 2018 06:40:54 +0000 (14:40 +0800)]
i2c: sprd: Prevent i2c accesses after suspend is called
Add one flag to indicate if the i2c controller has been in suspend state,
which can prevent i2c accesses after i2c controller is suspended following
system suspend.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Alexander Popov [Thu, 19 Apr 2018 12:29:22 +0000 (15:29 +0300)]
i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()
i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which
returns ZERO_SIZE_PTR if i2c_msg.len is zero.
Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case
of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in
case of zero len.
Let's check the len against zero before dereferencing buf pointer.
This issue was triggered by syzkaller.
Signed-off-by: Alexander Popov <alex.popov@linux.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[wsa: use '< 1' instead of '!' for easier readability] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Mark Rutland [Fri, 27 Apr 2018 10:50:36 +0000 (11:50 +0100)]
arm64: avoid instrumenting atomic_ll_sc.o
Our out-of-line atomics are built with a special calling convention,
preventing pointless stack spilling, and allowing us to patch call sites
with ARMv8.1 atomic instructions.
Instrumentation inserted by the compiler may result in calls to
functions not following this special calling convention, resulting in
registers being unexpectedly clobbered, and various problems resulting
from this.
For example, if a kernel is built with KCOV and ARM64_LSE_ATOMICS, the
compiler inserts calls to __sanitizer_cov_trace_pc in the prologues of
the atomic functions. This has been observed to result in spurious
cmpxchg failures, leading to a hang early on in the boot process.
This patch avoids such issues by preventing instrumentation of our
out-of-line atomics.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
projects / mirror_ubuntu-eoan-kernel.git / log