summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-09drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simpleTobias Schramm
This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple driver. The panel is used by the pine64 Pinebook Pro. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109112952.2620-2-t.schramm@manjaro.org
2020-01-09dt-bindings: display: add BOE 14" panelSam Ravnborg
Add bindings for the BOE NV140FHM-N49 14" 1920x1080 panel. The panel is used by the pine64 Pinebook Pro. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Tobias Schramm <t.schramm@manjaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109140742.GA12940@ravnborg.org
2020-01-09Merge drm/drm-next into drm-intel-next-queuedJani Nikula
Sync with drm-next to get the new logging macros, among other things. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-01-09drm/i915/gen9: Clear residual context state on context switchAkeem G Abodunrin
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Intel GPU Hardware prior to Gen11 does not clear EU state during a context switch. This can result in information leakage between contexts. For Gen8 and Gen9, hardware provides a mechanism for fast cleardown of the EU state, by issuing a PIPE_CONTROL with bit 27 set. We can use this in a context batch buffer to explicitly cleardown the state on every context switch. As this workaround is already in place for gen8, we can borrow the code verbatim for Gen9. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Kumar Valsan Prathap <prathap.kumar.valsan@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Balestrieri Francesco <francesco.balestrieri@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Cc: Dutt Sudeep <sudeep.dutt@intel.com>
2020-01-09fs: move guard_bio_eod() after bio_set_op_attrsMing Lei
Commit 85a8ce62c2ea ("block: add bio_truncate to fix guard_bio_eod") adds bio_truncate() for handling bio EOD. However, bio_truncate() doesn't use the passed 'op' parameter from guard_bio_eod's callers. So bio_trunacate() may retrieve wrong 'op', and zering pages may not be done for READ bio. Fixes this issue by moving guard_bio_eod() after bio_set_op_attrs() in submit_bh_wbc() so that bio_truncate() can always retrieve correct op info. Meantime remove the 'op' parameter from guard_bio_eod() because it isn't used any more. Cc: Carlos Maiolino <cmaiolino@redhat.com> Cc: linux-fsdevel@vger.kernel.org Fixes: 85a8ce62c2ea ("block: add bio_truncate to fix guard_bio_eod") Signed-off-by: Ming Lei <ming.lei@redhat.com> Fold in kerneldoc and bio_op() change. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-01-09drm/i915: use true,false for bool variable in intel_crt.cMa Feng
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ma Feng <mafeng.ma@huawei.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-4-git-send-email-mafeng.ma@huawei.com
2020-01-09drm/i915/dp: use true,false for bool variable in intel_dp.cMa Feng
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ma Feng <mafeng.ma@huawei.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-3-git-send-email-mafeng.ma@huawei.com
2020-01-09drm/i915: use true,false for bool variable in i915_debugfs.cMa Feng
Fixes coccicheck warning: drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ma Feng <mafeng.ma@huawei.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-2-git-send-email-mafeng.ma@huawei.com
2020-01-09drm/panel: Add driver for Sony ACX424AKP panelLinus Walleij
The Sony ACX424AKP is a command/videomode DSI panel for mobile devices. It is used on the ST-Ericsson HREF520 reference design. We support video mode by default, but it is possible to switch the panel into command mode by using the bool property "dsi-command-mode". Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109072815.334867-1-linus.walleij@linaro.org
2020-01-09drm/udl: Make udl driver depend on CONFIG_USBThomas Zimmermann
The udl driver for DisplayLink devices depends on support for host-side USB controllers, which is enabled with CONFIG_USB. Plain USB support as given by CONFIG_USB_SUPPORT is not sufficient. This patch changes dependencies for udl to depend on CONFIG_USB, instead of CONFIG_USB_SUPPORT. Users will have to enable CONFIG_USB and select a USB host controller. With this change udl dependencies work the same way as dependencies for PCI drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106141016.9562-1-tzimmermann@suse.de
2020-01-09drm/i915/gt: runtime-pm is no longer required for ce->ops->pin()Chris Wilson
Now that we have moved the runtime-pm management out of intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no explicit runtime pm wakeref is required in intel_context_pin(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-3-chris@chris-wilson.co.uk
2020-01-09drm/i915/gt: Pull context activation into central intel_context_pin()Chris Wilson
While this is encroaching on midlayer territory, having already made the state allocation a previous step in pinning, we can now pull the common intel_context_active_acquire() into intel_context_pin() itself. This is a prelude to make the activation a separate step inside pinning, outside of the ce->pin_mutex Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-2-chris@chris-wilson.co.uk
2020-01-09drm/i915/gt: Push context state allocation earlierChris Wilson
Allow for knowledgeable users to preallocate the context state, and to separate the allocation step from the pinning step during intel_context_pin() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-1-chris@chris-wilson.co.uk
2020-01-09drm/i915: Pin the context as we work on itChris Wilson
Since we now allow the intel_context_unpin() to run unserialised, we risk our operations under the intel_context_lock_pinned() being run as the context is unpinned (and thus invalidating our state). We can atomically acquire the pin, testing to see if it is pinned in the process, thus ensuring that the state remains consistent during the course of the whole operation. Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085142.871563-1-chris@chris-wilson.co.uk
2020-01-09futex: Fix kernel-doc notation warningRandy Dunlap
Fix a kernel-doc warning in kernel/futex.c by adding notation for @ret. ../kernel/futex.c:1187: warning: Function parameter or member 'ret' not described in 'wait_for_owner_exiting' Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/223be78c-f3c8-52df-836d-c5fb8e7907e9@infradead.org
2020-01-09drm/i915: Revert "drm/i915/tgl: Wa_1607138340"Tvrtko Ursulin
This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352. For some yet unexplained reason not having this improves stability of some media workloads. Promise is that the media hang will be root caused properly and in the meantime absence of this workaround is unlikely to cause problems. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Sudeep Dutt <sudeep.dutt@intel.com> Cc: Francesco Balestrieri <francesco.balestrieri@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tony Ye <tony.ye@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108161954.29739-1-tvrtko.ursulin@linux.intel.com
2020-01-09ARM: dts: imx7: Fix Toradex Colibri iMX7S 256MB NAND flash supportMarcel Ziswiler
Turns out when introducing the eMMC version the gpmi node required for NAND flash support got enabled exclusively on Colibri iMX7D 512MB. Fixes: f928a4a377e4 ("ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sll-evk: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 96a9169cf621 ("ARM: dts: imx6sll-evk: Assign corresponding power supply for vdd3p0") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sl-evk: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 3feea8805d6f ("ARM: dts: imx6sl-evk: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sx-sdb: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 37a4bdead109 ("ARM: dts: imx6sx-sdb: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6qdl-sabresd: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 93385546ba36 ("ARM: dts: imx6qdl-sabresd: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09HID: steam: Fix input device disappearingRodrigo Rivas Costa
The `connected` value for wired devices was not properly initialized, it must be set to `true` upon creation, because wired devices do not generate connection events. When a raw client (the Steam Client) uses the device, the input device is destroyed. Then, when the raw client finishes, it must be recreated. But since the `connected` variable was false this never happended. Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-09drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CECHans Verkuil
Add a missing 'depends on DRM' for the DRM_DP_CEC config option. Without that enabling DRM_DP_CEC will force CEC_CORE to =y instead of =m if DRM=m as well. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/489bdaae-9b05-2d70-12e1-4fda7899dfc1@xs4all.nl
2020-01-09drm/i915: Reduce warning for i915_vma_pin_iomap() without runtime-pmChris Wilson
Access through the GGTT (iomap) into the vma does require the device to be awake. However, we often take the i915_vma_pin_iomap() as an early preparatory step that is long before we use the iomap. Asserting that the device is awake at pin time does not protect us, and is merely a nuisance. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108153550.3803446-2-chris@chris-wilson.co.uk
2020-01-09drm/i915: Early return for no-op i915_vma_pin_fence()Chris Wilson
If we have no fence and desire no fence on the vma, return before we try and take the vm->mutex. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108153550.3803446-1-chris@chris-wilson.co.uk
2020-01-09drm/i915/gt: Drop a defunct timeline assertionChris Wilson
intel_timeline_enter() has been decoupled from intel_timeline_pin() and both enter/exit & pin/unpin are allowed [read expected] to run concurrently with one another. The assertion that they had better not is stale. Closes: https://gitlab.freedesktop.org/drm/intel/issues/940 References: a6edbca74b30 ("drm/i915/gt: Close race between engine_park and intel_gt_retire_requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200107143826.3298401-1-chris@chris-wilson.co.uk
2020-01-09ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DLJagan Teki
The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on the 1.5 version of the i.Core MX6 cpu module. The 1.5 version differs from the original one for a few details, including the ethernet PHY interface clock provider. With this commit, the ethernet interface works properly: SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver While before using the 1.5 version, ethernet failed to startup do to un-clocked PHY interface: fec 2188000.ethernet eth0: could not attach to PHY Similar fix has merged for i.Core MX6Q but missed to update for DL. Fixes: a8039f2dd089 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support") Cc: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01DPaul Cercueil
Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD panel, and remove the old sharp,ls020b1dd01d.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109003000.119516-2-paul@crapouillou.net
2020-01-09dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0Paul Cercueil
Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD panel, and remove the old giantplus,gpm740b0.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109003000.119516-1-paul@crapouillou.net
2020-01-09crypto: hisilicon/sec2 - Use atomics instead of __syncArnd Bergmann
The use of __sync functions for atomic memory access is not supported in the kernel, and can result in a link error depending on configuration: ERROR: "__tsan_atomic32_compare_exchange_strong" [drivers/crypto/hisilicon/sec2/hisi_sec2.ko] undefined! ERROR: "__tsan_atomic64_fetch_add" [drivers/crypto/hisilicon/sec2/hisi_sec2.ko] undefined! Use the kernel's own atomic interfaces instead. This way the debugfs interface actually reads the counter atomically. Fixes: 416d82204df4 ("crypto: hisilicon - add HiSilicon SEC V2 driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-01-09Merge tag 'amd-drm-fixes-5.5-2020-01-08' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.5-2020-01-08: amdgpu: - Stability fix for raven - Reduce pixel encoding to if max clock is exceeded on HDMI to allow additional high res modes UAPI: - enable DRIVER_SYNCOBJ_TIMELINE for amdgpu Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108213649.5485-1-alexander.deucher@amd.com
2020-01-09Merge tag 'drm-misc-fixes-2020-01-08' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes mst: Fix NO_STOP_BIT bit offset (Wayne) sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu) fb_helper: Fix bits_per_pixel param set behavior to round up (Geert) Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200108205949.GA233273@art_vandelay
2020-01-09drm/mediatek: apply CMDQ control flowBibby Hsieh
In some Mediatek SoC, there is no "shadow" registers for performaing an atomic video mode set or page flip at vblank/vsync. The CMDQ (Commend Queue) is used to help update all relevant display controller registers with critical time limation. Signed-off-by: YT Shen <yt.shen@mediatek.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2020-01-09drm/mediatek: support CMDQ interface in ddp componentBibby Hsieh
The CMDQ (Command Queue) in some Mediatek SoC is used to help update all relevant display controller registers with critical time limation. This patch add cmdq interface in ddp_comp interface, let all ddp_comp interface can support cpu/cmdq function at the same time. Signed-off-by: YT Shen <yt.shen@mediatek.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2020-01-09Merge tag 'v5.5-next-cmdq-stable' of ↵CK Hu
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux cmdq patches needed by drm driver to use cmdq interface
2020-01-09drm/lima: use drm_sched_fault for error task handlingQiang Yu
drm_sched_job_timedout works with drm_sched_stop as a pair, so we'd better use the drm_sched_fault helper to make the error and timeout handling go the same path. This also fixes application hang when task error. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200101103831.22429-1-yuq825@gmail.com
2020-01-08pstore/ram: Regularize prz label allocation lifetimeKees Cook
In my attempt to fix a memory leak, I introduced a double-free in the pstore error path. Instead of trying to manage the allocation lifetime between persistent_ram_new() and its callers, adjust the logic so persistent_ram_new() always takes a kstrdup() copy, and leaves the caller's allocation lifetime up to the caller. Therefore callers are _always_ responsible for freeing their label. Before, it only needed freeing when the prz itself failed to allocate, and not in any of the other prz failure cases, which callers would have no visibility into, which is the root design problem that lead to both the leak and now double-free bugs. Reported-by: Cengiz Can <cengiz@kernel.wtf> Link: https://lore.kernel.org/lkml/d4ec59002ede4aaf9928c7f7526da87c@kernel.wtf Fixes: 8df955a32a73 ("pstore/ram: Fix error-path memory leak in persistent_ram_new() callers") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2020-01-09Merge tag 'drm-misc-next-2020-01-07' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.6: UAPI Changes: - Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n. Cross-subsystem Changes: - fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST. - Use devm_platform_ioremap_resource in fbdev drivers. - Various small fbdev fixes. Core Changes: - Support scanline alignment for dumb buffers. - Add atomic_check() hook to bridge ops, to support bus format negotiation. - Add gem_create_object() to vram helpers. Driver Changes: - Rockchip: Add support for PX30. - Use generic fbdev code and dumb helpers in hisilicon/hibmc. - Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272. - Clock fixes for atmel-hlcdc. - Various smaller fixes to all drivers. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8eff1e3f-ef0a-2dd9-9a14-6273b1d6f963@linux.intel.com
2020-01-09drm: of: Fix linking when CONFIG_OF is not setLaurent Pinchart
The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in commit 6529007522de has a fallback stub when CONFIG_OF is not set, but the stub is declared in drm_of.h without a static inline. This causes multiple definitions of the function to be linked when the CONFIG_OF option isn't set. Fix it by making the stub static inline. Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191219103703.8547-1-laurent.pinchart+renesas@ideasonboard.com
2020-01-09drm/panel: Add support for AUO B116XAK01 panelRob Clark
Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200108235356.918189-2-robdclark@gmail.com
2020-01-09dt-bindings: display: panel: Add AUO B116XAK01 panel bindingsRob Clark
Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200108235356.918189-1-robdclark@gmail.com
2020-01-08tipc: fix wrong connect() return codeTuong Lien
The current 'tipc_wait_for_connect()' function does a wait-loop for the condition 'sk->sk_state != TIPC_CONNECTING' to conclude if the socket connecting has done. However, when the condition is met, it returns '0' even in the case the connecting is actually failed, the socket state is set to 'TIPC_DISCONNECTING' (e.g. when the server socket has closed..). This results in a wrong return code for the 'connect()' call from user, making it believe that the connection is established and go ahead with building, sending a message, etc. but finally failed e.g. '-EPIPE'. This commit fixes the issue by changing the wait condition to the 'tipc_sk_connected(sk)', so the function will return '0' only when the connection is really established. Otherwise, either the socket 'sk_err' if any or '-ETIMEDOUT'/'-EINTR' will be returned correspondingly. Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-08tipc: fix link overflow issue at socket shutdownTuong Lien
When a socket is suddenly shutdown or released, it will reject all the unreceived messages in its receive queue. This applies to a connected socket too, whereas there is only one 'FIN' message required to be sent back to its peer in this case. In case there are many messages in the queue and/or some connections with such messages are shutdown at the same time, the link layer will easily get overflowed at the 'TIPC_SYSTEM_IMPORTANCE' backlog level because of the message rejections. As a result, the link will be taken down. Moreover, immediately when the link is re-established, the socket layer can continue to reject the messages and the same issue happens... The commit refactors the '__tipc_shutdown()' function to only send one 'FIN' in the situation mentioned above. For the connectionless case, it is unavoidable but usually there is no rejections for such socket messages because they are 'dest-droppable' by default. In addition, the new code makes the other socket states clear (e.g.'TIPC_LISTEN') and treats as a separate case to avoid misbehaving. Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Missing netns context in arp_tables, from Florian Westphal. 2) Underflow in flowtable reference counter, from wenxu. 3) Fix incorrect ethernet destination address in flowtable offload, from wenxu. 4) Check for status of neighbour entry, from wenxu. 5) Fix NAT port mangling, from wenxu. 6) Unbind callbacks from destroy path to cleanup hardware properly on flowtable removal. 7) Fix missing casting statistics timestamp, add nf_flowtable_time_stamp and use it. 8) NULL pointer exception when timeout argument is null in conntrack dccp and sctp protocol helpers, from Florian Westphal. 9) Possible nul-dereference in ipset with IPSET_ATTR_LINENO, also from Florian. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-08netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is presentFlorian Westphal
The set uadt functions assume lineno is never NULL, but it is in case of ip_set_utest(). syzkaller managed to generate a netlink message that calls this with LINENO attr present: general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:hash_mac4_uadt+0x1bc/0x470 net/netfilter/ipset/ip_set_hash_mac.c:104 Call Trace: ip_set_utest+0x55b/0x890 net/netfilter/ipset/ip_set_core.c:1867 nfnetlink_rcv_msg+0xcf2/0xfb0 net/netfilter/nfnetlink.c:229 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 nfnetlink_rcv+0x1ba/0x460 net/netfilter/nfnetlink.c:563 pass a dummy lineno storage, its easier than patching all set implementations. This seems to be a day-0 bug. Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Reported-by: syzbot+34bd2369d38707f3f4a7@syzkaller.appspotmail.com Fixes: a7b4f989a6294 ("netfilter: ipset: IP set core support") Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-01-08netfilter: conntrack: dccp, sctp: handle null timeout argumentFlorian Westphal
The timeout pointer can be NULL which means we should modify the per-nets timeout instead. All do this, except sctp and dccp which instead give: general protection fault: 0000 [#1] PREEMPT SMP KASAN net/netfilter/nf_conntrack_proto_dccp.c:682 ctnl_timeout_parse_policy+0x150/0x1d0 net/netfilter/nfnetlink_cttimeout.c:67 cttimeout_default_set+0x150/0x1c0 net/netfilter/nfnetlink_cttimeout.c:368 nfnetlink_rcv_msg+0xcf2/0xfb0 net/netfilter/nfnetlink.c:229 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 Reported-by: syzbot+46a4ad33f345d1dd346e@syzkaller.appspotmail.com Fixes: c779e849608a8 ("netfilter: conntrack: remove get_timeout() indirection") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-01-08atm: eni: fix uninitialized variable warningArnd Bergmann
With -O3, gcc has found an actual unintialized variable stored into an mmio register in two instances: drivers/atm/eni.c: In function 'discard': drivers/atm/eni.c:465:13: error: 'dma[1]' is used uninitialized in this function [-Werror=uninitialized] writel(dma[i*2+1],eni_dev->rx_dma+dma_wr*8+4); ^ drivers/atm/eni.c:465:13: error: 'dma[3]' is used uninitialized in this function [-Werror=uninitialized] Change the code to always write zeroes instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-08dt-bindings: Add vendor prefix for SatozMiquel Raynal
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200106151827.31511-1-miquel.raynal@bootlin.com
2020-01-08dt-bindings: one binding file for all simple panelsSam Ravnborg
There is an increasing number of new simple panels. Common for many of these simple panels are that they have one mandatory power-supply and some of them have backlight and / or an enable gpio. The binding file to describe these panels adds overhead that really do not add value. The binding are known and there is nothing gained from a dedicated binding file nor for any dedicated example. The following patch introduces a single panel-simple.yaml and converts two ampire bindings over to the new file. The conversion - if applied will have following effects: - The maintainer for the individual file will change There is no need for many different maintainers for a simple binding. We have the same situation with the panel-simple driver in the kernel. - The license will change to (GPL-2.0-only OR BSD-2-Clause) There is usually only a single line copied from the original file, a line that is often copied from a datasheet. This license change should be acceptable considered what little is copied. If the license change is not OK we can use a dedicated binding file in these cases. This is a follow-up on Rob's big patch converting a lot of panel bindings to individual files: "dt-bindings: display: Convert a bunch of panels to DT schema" https://patchwork.ozlabs.org/patch/1197683/ The objectives with one file for the relevant simple panels are: - Make it simpler to add bindings for simple panels - Keep the number of bindings file lower and thus easier to find a relevant file to copy from when adding new panels. - Keep the binding documentation for simple panels more consistent - Make it simpler to add support for new panels v3: - Whitespace fix (checkpatch) - Indent compatible (Rob h) - Indent comments to give compatible more visibility (Rob h) v2: - spelling fixes (imirkin via irc, Rob) - updated description (Rob) - list properires in alphabetical order - added power-supply to example (Rob) - updated title - reworded changelog a little Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: devicetree@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200102101712.5085-2-sam@ravnborg.org
2020-01-08macvlan: do not assume mac_header is set in macvlan_broadcast()Eric Dumazet
Use of eth_hdr() in tx path is error prone. Many drivers call skb_reset_mac_header() before using it, but others do not. Commit 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") attempted to fix this generically, but commit d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option") brought back the macvlan bug. Lets add a new helper, so that tx paths no longer have to call skb_reset_mac_header() only to get a pointer to skb->data. Hopefully we will be able to revert 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") and save few cycles in transmit fast path. BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline] BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579 CPU: 0 PID: 9579 Comm: syz-executor947 Not tainted 5.5.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:145 __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] mc_hash drivers/net/macvlan.c:251 [inline] macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 macvlan_queue_xmit drivers/net/macvlan.c:520 [inline] macvlan_start_xmit+0x402/0x77f drivers/net/macvlan.c:559 __netdev_start_xmit include/linux/netdevice.h:4447 [inline] netdev_start_xmit include/linux/netdevice.h:4461 [inline] dev_direct_xmit+0x419/0x630 net/core/dev.c:4079 packet_direct_xmit+0x1a9/0x250 net/packet/af_packet.c:240 packet_snd net/packet/af_packet.c:2966 [inline] packet_sendmsg+0x260d/0x6220 net/packet/af_packet.c:2991 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 __sys_sendto+0x262/0x380 net/socket.c:1985 __do_sys_sendto net/socket.c:1997 [inline] __se_sys_sendto net/socket.c:1993 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1993 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x442639 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffc13549e08 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000442639 RDX: 000000000000000e RSI: 0000000020000080 RDI: 0000000000000003 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000403bb0 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc mm/kasan/common.c:513 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527 __do_kmalloc mm/slab.c:3656 [inline] __kmalloc+0x163/0x770 mm/slab.c:3665 kmalloc include/linux/slab.h:561 [inline] tomoyo_realpath_from_path+0xc5/0x660 security/tomoyo/realpath.c:252 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:335 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x2c0 mm/slab.c:3757 tomoyo_realpath_from_path+0x1a7/0x660 security/tomoyo/realpath.c:289 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a4932000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 1025 bytes inside of 4096-byte region [ffff8880a4932000, ffff8880a4933000) The buggy address belongs to the page: page:ffffea0002924c80 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0 raw: 00fffe0000010200 ffffea0002846208 ffffea00028f3888 ffff8880aa402000 raw: 0000000000000000 ffff8880a4932000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a4932300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880a4932400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880a4932480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-22 23:03:49 +0000