aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-02-11locking: Enable RT_MUTEXES by default on PREEMPT_RT.Sebastian Andrzej Siewior1-0/+1
The CONFIG_RT_MUTEXES option is enabled by CONFIG_FUTEX and CONFIG_I2C. If both are disabled then a CONFIG_PREEMPT_RT build fails to compile. It is not possible to have a PREEMPT_RT kernel without RT_MUTEX support because RT_MUTEX based locking is always used. Enable CONFIG_RT_MUTEXES by default on PREEMPT_RT builds. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YgKmhjkcuqWXdUjQ@linutronix.de
2022-02-11locking/local_lock: Make the empty local_lock_*() function a macro.Sebastian Andrzej Siewior1-3/+3
It has been said that local_lock() does not add any overhead compared to preempt_disable() in a !LOCKDEP configuration. A micro benchmark showed an unexpected result which can be reduced to the fact that local_lock() was not entirely optimized away. In the !LOCKDEP configuration local_lock_acquire() is an empty static inline function. On x86 the this_cpu_ptr() argument of that function is fully evaluated leading to an additional mov+add instructions which are not needed and not used. Replace the static inline function with a macro. The typecheck() macro ensures that the argument is of proper type while the resulting disassembly shows no traces of this_cpu_ptr(). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Waiman Long <longman@redhat.com> Link: https://lkml.kernel.org/r/YgKjciR60fZft2l4@linutronix.de
2022-02-11atomics: Fix atomic64_{read_acquire,set_release} fallbacksMark Rutland3-7/+49
Arnd reports that on 32-bit architectures, the fallbacks for atomic64_read_acquire() and atomic64_set_release() are broken as they use smp_load_acquire() and smp_store_release() respectively, which do not work on types larger than the native word size. Since those contain compiletime_assert_atomic_type(), any attempt to use those fallbacks will result in a build-time error. e.g. with the following added to arch/arm/kernel/setup.c: | void test_atomic64(atomic64_t *v) | { | atomic64_set_release(v, 5); | atomic64_read_acquire(v); | } The compiler will complain as follows: | In file included from <command-line>: | In function 'arch_atomic64_set_release', | inlined from 'test_atomic64' at ./include/linux/atomic/atomic-instrumented.h:669:2: | ././include/linux/compiler_types.h:346:38: error: call to '__compiletime_assert_9' declared with attribute error: Need native word sized stores/loads for atomicity. | 346 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | | ^ | ././include/linux/compiler_types.h:327:4: note: in definition of macro '__compiletime_assert' | 327 | prefix ## suffix(); \ | | ^~~~~~ | ././include/linux/compiler_types.h:346:2: note: in expansion of macro '_compiletime_assert' | 346 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | | ^~~~~~~~~~~~~~~~~~~ | ././include/linux/compiler_types.h:349:2: note: in expansion of macro 'compiletime_assert' | 349 | compiletime_assert(__native_word(t), \ | | ^~~~~~~~~~~~~~~~~~ | ./include/asm-generic/barrier.h:133:2: note: in expansion of macro 'compiletime_assert_atomic_type' | 133 | compiletime_assert_atomic_type(*p); \ | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ./include/asm-generic/barrier.h:164:55: note: in expansion of macro '__smp_store_release' | 164 | #define smp_store_release(p, v) do { kcsan_release(); __smp_store_release(p, v); } while (0) | | ^~~~~~~~~~~~~~~~~~~ | ./include/linux/atomic/atomic-arch-fallback.h:1270:2: note: in expansion of macro 'smp_store_release' | 1270 | smp_store_release(&(v)->counter, i); | | ^~~~~~~~~~~~~~~~~ | make[2]: *** [scripts/Makefile.build:288: arch/arm/kernel/setup.o] Error 1 | make[1]: *** [scripts/Makefile.build:550: arch/arm/kernel] Error 2 | make: *** [Makefile:1831: arch/arm] Error 2 Fix this by only using smp_load_acquire() and smp_store_release() for native atomic types, and otherwise falling back to the regular barriers necessary for acquire/release semantics, as we do in the more generic acquire and release fallbacks. Since the fallback templates are used to generate the atomic64_*() and atomic_*() operations, the __native_word() check is added to both. For the atomic_*() operations, which are always 32-bit, the __native_word() check is redundant but not harmful, as it is always true. For the example above this works as expected on 32-bit, e.g. for arm multi_v7_defconfig: | <test_atomic64>: | push {r4, r5} | dmb ish | pldw [r0] | mov r2, #5 | mov r3, #0 | ldrexd r4, [r0] | strexd r4, r2, [r0] | teq r4, #0 | bne 484 <test_atomic64+0x14> | ldrexd r2, [r0] | dmb ish | pop {r4, r5} | bx lr ... and also on 64-bit, e.g. for arm64 defconfig: | <test_atomic64>: | bti c | paciasp | mov x1, #0x5 | stlr x1, [x0] | ldar x0, [x0] | autiasp | ret Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20220207101943.439825-1-mark.rutland@arm.com
2022-02-11locking: Add missing __sched attributesMinchan Kim2-3/+4
This patch adds __sched attributes to a few missing places to show blocked function rather than locking function in get_wchan. Signed-off-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220115231657.84828-1-minchan@kernel.org
2022-02-11iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTLMathias Krause1-3/+11
If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error. Fixes: f73f7f4da581 ("iio: buffer: add ioctl() to support opening extra buffers for IIO device") Cc: stable@kernel.org Cc: Jonathan Cameron <jic23@kernel.org> Cc: Alexandru Ardelean <ardeleanalex@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Nuno Sa <Nuno.Sa@analog.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mathias Krause <minipli@grsecurity.net> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11drm/i915: remove leftover i915_gem_pm.h declarations from i915_drv.hJani Nikula2-3/+1
Remove the duplicates. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/48f5ace6393533372da5d13df3de0203c8db11b3.1644507885.git.jani.nikula@intel.com
2022-02-11dt-bindings: net: dsa: realtek: convert to YAML schema, add MDIOLuiz Angelo Daros de Luca2-240/+394
Schema changes: - support for mdio-connected switches (mdio driver), recognized by checking the presence of property "reg" - new compatible strings for rtl8367s and rtl8367rb - "interrupt-controller" was not added as a required property. It might still work polling the ports when missing. Examples changes: - renamed "switch_intc" to make it unique between examples - removed "dsa-mdio" from mdio compatible property - renamed phy@0 to ethernet-phy@0 (not tested with real HW) phy@ requires #phy-cells Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-11net/smc: Avoid overwriting the copies of clcsock callback functionsWen Gu1-3/+7
The callback functions of clcsock will be saved and replaced during the fallback. But if the fallback happens more than once, then the copies of these callback functions will be overwritten incorrectly, resulting in a loop call issue: clcsk->sk_error_report |- smc_fback_error_report() <------------------------------| |- smc_fback_forward_wakeup() | (loop) |- clcsock_callback() (incorrectly overwritten) | |- smc->clcsk_error_report() ------------------| So this patch fixes the issue by saving these function pointers only once in the fallback and avoiding overwriting. Reported-by: syzbot+4de3c0e8a263e1e499bc@syzkaller.appspotmail.com Fixes: 341adeec9ada ("net/smc: Forward wakeup to smc socket waitqueue after fallback") Link: https://lore.kernel.org/r/0000000000006d045e05d78776f6@google.com Signed-off-by: Wen Gu <guwen@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-11dt-bindings: serial: fsl-lpuart: Remove i.MX8QM from enumAbel Vesa1-1/+0
i.MX8QM lpuart is backwards compatible with i.MX8QXP, so lets remove the single match from enum. This will force nodes to have both compatible strings, since there is already an 'items' entry for that. Reviewed-by: Peng Fan <peng.fan@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Link: https://lore.kernel.org/r/20220210201407.567860-2-abel.vesa@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11dt-bindings: serial: fsl-lpuart: Drop i.MX8QXP backwards compatibilityAbel Vesa1-3/+2
Drop the i.MX8QXP backwards compatibility with i.MX7ULP since they differ from clocks handling point of view. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Link: https://lore.kernel.org/r/20220210201407.567860-1-abel.vesa@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11tty: serial: imx: Add fast path when rs485 delays are 0Harald Seiler1-4/+14
Right now, even when `delay_rts_before_send` and `delay_rts_after_send` are 0, the hrtimer is triggered (with timeout 0) which can introduce a few 100us of additional overhead on slower i.MX platforms. Implement a fast path when the delays are 0, where the RTS signal is toggled immediately instead of going through an hrtimer. This fast path behaves identical to the code before delay support was implemented. Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Harald Seiler <hws@denx.de> Link: https://lore.kernel.org/r/20220119145204.238767-1-hws@denx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11KVM: arm64: vgic: Read HW interrupt pending state from the HWMarc Zyngier1-0/+2
It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always result in the pending interrupts being accurately reported if they are mapped to a HW interrupt. This is particularily visible when acking the timer interrupt and reading the GICR_ISPENDR1 register immediately after, for example (the interrupt appears as not-pending while it really is...). This is because a HW interrupt has its 'active and pending state' kept in the *physical* distributor, and not in the virtual one, as mandated by the spec (this is what allows the direct deactivation). The virtual distributor only caries the pending and active *states* (note the plural, as these are two independent and non-overlapping states). Fix it by reading the HW state back, either from the timer itself or from the distributor if necessary. Reported-by: Ricardo Koller <ricarkol@google.com> Tested-by: Ricardo Koller <ricarkol@google.com> Reviewed-by: Ricardo Koller <ricarkol@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.org
2022-02-11arm64: dts: qcom: sc7280: Set the default dr_mode for usb2Souradeep Chowdhury1-0/+4
Set the default dr_mode for usb2 node to "otg" to enable role-switch for EUD(Embedded USB Debugger) connector node. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/22fb3bbc16f3a0ae894068e4420e08ea86389817.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11arm64: dts: qcom: sc7280: Add EUD dt node and dwc3 connectorSouradeep Chowdhury1-0/+36
Add the Embedded USB Debugger(EUD) device tree node. The node contains EUD base register region and EUD mode manager register regions along with the interrupt entry. Also add the typec connector node for EUD which is attached to EUD node via port. EUD is also attached to DWC3 node via port. Also add the role-switch property to dwc3 node. Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/b2b6bdf0e7589a7b6a6f9b390b227339636e0da9.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)Souradeep Chowdhury4-0/+271
Add support for control peripheral of EUD (Embedded USB Debugger) to listen to events such as USB attach/detach, pet EUD to indicate software is functional.Reusing the platform device kobj, sysfs entry 'enable' is created to enable or disable EUD. To enable the eud the following needs to be done echo 1 > /sys/bus/platform/.../enable To disable eud, following is the command echo 0 > /sys/bus/platform/.../enable Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/0ac5c2b2c8e4ce4f4f342a08b48cfc61aeaf7ee8.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11bindings: usb: dwc3: Update dwc3 properties for EUD connectorSouradeep Chowdhury1-0/+6
Add the ports property for dwc3 node. This port can be used by the Embedded USB Debugger for role switching the controller from device to host mode and vice versa. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/7308170ce13a96c2ff9cbb22316f46c814c42ef1.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11dt-bindings: Add the yaml bindings for EUDSouradeep Chowdhury1-0/+77
Documentation for Embedded USB Debugger(EUD) device tree bindings in yaml format. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/e6a490c5eab9750decd5204d284b9b163b9be187.1644339918.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: typec: rt1719: Add support for Richtek RT1719ChiYuan Huang3-0/+974
Richtek RT1719 is a sink-only Type-C PD controller it complies with latest USB Type-C and PD standards. It integrates the physical layer of USB power delivery protocol to allow up to 100W of power. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1644421362-32104-3-git-send-email-u0084500@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11dt-bindings: usb: rt1719: Add binding for Richtek RT1719ChiYuan Huang1-0/+85
Add binding for Richtek RT1719. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1644421362-32104-2-git-send-email-u0084500@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11drm/i915: split out i915_gem_internal.h from i915_drv.hJani Nikula31-16/+67
We already have the i915_gem_internal.c file. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6715d1f3232c445990630bb3aac00f279f516fee.1644507885.git.jani.nikula@intel.com
2022-02-11firmware: arm_scmi: Remove space in MODULE_ALIAS nameAlyssa Ross1-1/+1
modprobe can't handle spaces in aliases. Get rid of it to fix the issue. Link: https://lore.kernel.org/r/20220211102704.128354-1-sudeep.holla@arm.com Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI") Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Alyssa Ross <hi@alyssa.is> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-02-11ASoC: SOF: compr: Mark snd_compress_ops staticDaniel Baluta1-13/+13
Functions won't be directly used outside of compress.c file so mark them as static. This will also fix warnings reported by kernel test robot: >> sound/soc/sof/compress.c:91:5: warning: no previous prototype for function 'sof_compr_open' [-Wmissing-prototypes] int sof_compr_open(struct snd_soc_component *component, ^ sound/soc/sof/compress.c:91:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int sof_compr_open(struct snd_soc_component *component, Fixes: 6324cf901e14 ("SoC: SOF: compr: Add compress ops implementation") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20220211082631.179735-1-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-11ASoC: Intel: bytcr_wm5102: use GFP_KERNELJulia Lawall1-1/+1
Platform_driver probe functions aren't called with locks held and thus don't need GFP_ATOMIC. Use GFP_KERNEL instead. Problem found with Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220210204223.104181-4-Julia.Lawall@inria.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-11ASoC: wm_adsp: Add trace caps to speaker protection FWVlad Karpovich1-2/+7
Enable access to the speaker protection firmware debug stream using compress stream API and lower minimum fragment size to 16 words. Signed-off-by: Vlad Karpovich <Vlad.Karpovich@cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220210172053.22782-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-11ASoC: wm_adsp: Make compressed buffers optionalCharles Keepax1-21/+33
Newer firmwares will support compressed buffers that may or may not exist, for example debugging streams. Update the driver to make a compressed stream optional. A warning will still be generated at DSP boot time and opening the stream will fail if the compressed buffer in question does not exist, however the DSP can still be booted and other features used. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220210172053.22782-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-11drm/syncobj: flatten dma_fence_chains on transferChristian König1-5/+56
It is illegal to add a dma_fence_chain as timeline point. Flatten out the fences into a dma_fence_array instead. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Cc: <stable@vger.kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220209182600.434803-1-christian.koenig@amd.com
2022-02-11video: fbdev: udlfb: replace snprintf in show functions with sysfs_emitJing Yao1-4/+4
Use sysfs_emit instead of scnprintf, snprintf or sprintf. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Jing Yao <yao.jing2@zte.com.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2022-02-11video: fbdev: omapfb: panel-tpo-td043mtea1: Use sysfs_emit() instead of snprintf()Jing Yao1-2/+2
Use sysfs_emit instead of scnprintf, snprintf or sprintf. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Jing Yao <yao.jing2@zte.com.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2022-02-11video: fbdev: omapfb: panel-dsi-cm: Use sysfs_emit() instead of snprintf()Jing Yao1-4/+4
Use sysfs_emit instead of scnprintf, snprintf or sprintf. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Jing Yao <yao.jing2@zte.com.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2022-02-11usb: xhci-mtk: add support ip-sleep wakeup for mt8195Chunfeng Yun1-0/+37
Add support ip-sleep wakeup for mt8195, it's a specific revision for each USB controller, and not following IPM rule. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20220128062902.26273-2-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11dt-bindings: usb: mtk-xhci: add support ip-sleep for mt8195Chunfeng Yun1-1/+5
There are 4 USB controllers on MT8195, each controller's wakeup control is different, add some specific versions for them. Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20220128062902.26273-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11arm64: dts: agilex: use the compatible "intel,socfpga-agilex-hsotg"Dinh Nguyen1-2/+2
The DWC2 USB controller on the Agilex platform does not support clock gating, so use the chip specific "intel,socfpga-agilex-hsotg" compatible. Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20220125161821.1951906-3-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: dwc2: Add platform specific data for Intel's AgilexDinh Nguyen1-0/+10
The DWC2 IP on the Agilex platform does not support clock-gating. Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20220125161821.1951906-2-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11dt-bindings: usb: dwc2: add compatible "intel,socfpga-agilex-hsotg"Dinh Nguyen1-0/+1
Add the compatible "intel,socfpga-agilex-hsotg" to the DWC2 implementation, because the Agilex DWC2 implementation does not support clock gating. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20220125161821.1951906-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11video: fbdev: omapfb: Use sysfs_emit() instead of snprintf()Guo Zhengkui1-6/+7
Use sysfs_emit() instead of snprintf(). Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-02-11USB: usbfs: Use a spinlock instead of atomic accesses to tally used memory.Ingo Rohloff1-10/+22
While the existing code code imposes a limit on the used memory, it might be over pessimistic (even if this is unlikely). Example scenario: 8 threads running in parallel, all entering "usbfs_increase_memory_usage()" at the same time. The atomic accesses in "usbfs_increase_memory_usage()" could be serialized like this: 8 x "atomic64_add" 8 x "atomic64_read" If the 8 x "atomic64_add" raise "usbfs_memory_usage" above the limit, then all 8 calls of "usbfs_increase_memory_usage()" will return with -ENOMEM. If you instead serialize over the whole access to "usbfs_memory_usage" by using a spinlock, some of these calls will succeed. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ingo Rohloff <ingo.rohloff@lauterbach.com> Link: https://lore.kernel.org/r/20220209123303.103340-2-ingo.rohloff@lauterbach.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: dwc2: drd: fix soft connect when gadget is unconfiguredFabrice Gasnier1-2/+4
When the gadget driver hasn't been (yet) configured, and the cable is connected to a HOST, the SFTDISCON gets cleared unconditionally, so the HOST tries to enumerate it. At the host side, this can result in a stuck USB port or worse. When getting lucky, some dmesg can be observed at the host side: new high-speed USB device number ... device descriptor read/64, error -110 Fix it in drd, by checking the enabled flag before calling dwc2_hsotg_core_connect(). It will be called later, once configured, by the normal flow: - udc_bind_to_driver - usb_gadget_connect - dwc2_hsotg_pullup - dwc2_hsotg_core_connect Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support") Cc: stable@kernel.org Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/1644423353-17859-1-git-send-email-fabrice.gasnier@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: gadget: rndis: check size of RNDIS_MSG_SET commandGreg Kroah-Hartman1-3/+6
Check the size of the RNDIS_MSG_SET command given to us before attempting to respond to an invalid message size. Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com> Cc: stable@kernel.org Tested-by: Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11USB: gadget: validate interface OS descriptor requestsSzymon Heidrich1-0/+3
Stall the control endpoint in case provided index exceeds array size of MAX_CONFIG_INTERFACES or when the retrieved function pointer is null. Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11usb: core: Unregister device on component_add() failureFabio M. De Francesco1-3/+6
Commit 8c67d06f3fd9 ("usb: Link the ports to the connectors they are attached to") creates a link to the USB Type-C connector for every new port that is added when possible. If component_add() fails, usb_hub_create_port_device() prints a warning but does not unregister the device and does not return errors to the callers. Syzbot reported a "WARNING in component_del()". Fix this issue in usb_hub_create_port_device by calling device_unregister() and returning the errors from component_add(). Fixes: 8c67d06f3fd9 ("usb: Link the ports to the connectors they are attached to") Reported-and-tested-by: syzbot+60df062e1c41940cae0f@syzkaller.appspotmail.com Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20220209164500.8769-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixupJann Horn1-28/+38
ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver") Cc: stable@kernel.org Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-11platform/x86: intel_cht_int33fe: Move to intel directoryHans de Goede5-24/+22
Now that there is only 1 c-file left of the intel_cht_int33fe code, move it to the intel directory instead of it having its own int33fe sub-directory. Note this also renames the module from intel_cht_int33fe_typec to intel_chtwc_int33fe, to better match the names of other PMIC related modules like the intel_chtdc_ti_pwrbtn module. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-4-hdegoede@redhat.com
2022-02-11platform/x86: intel_cht_int33fe: Drop Lenovo Yogabook YB1-X9x codeHans de Goede4-118/+35
Move the Lenovo Yogabook YB1-X9x fuel-gauge instantiation code over to the x86-android-tablets module, which already deals with this for various other devices. This removes the need to have a special intel_cht_int33fe_microb module just for Lenovo Yogabook YB1-X9x laptops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-3-hdegoede@redhat.com
2022-02-11platform/x86: intel_cht_int33fe: Switch to DMI modalias based loadingHans de Goede5-171/+111
The intel_cht_int33fe driver is intended to deal with ACPI INT33FE firmware-nodes on Cherry Trail devices with a Whiskey Cove PMIC. The original version of the driver only dealt with the GPD win and GPD pocket boards where the WC PMIC is connected to a TI BQ24292i charger, paired with a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller + a PI3USB30532 USB switch, for a fully functional Type-C port. Later it was split into a Type-C and a Micro-B variant to deal with the Lenovo Yoga Book YB1-X90 / Lenovo Yoga Book YB1-X91 boards where the ACPI INT33FE firmware-node only describes the TI BQ27542 fuelgauge. Currently the driver differentiates between these 2 models by counting the number of I2cSerialBus resources in the firmware-node. There are a number of problems with this approach: 1. The driver autoloads based on the acpi:INT33FE modalias causing it to get loaded on almost all Bay Trail and Cherry Trail devices. It checks for the presence of a WC PMIC, so it won't bind but the loading still wastes time and memory. 2. Both code paths in the driver are really only designed for a single board and have harcoded various assumptions about these boards, if another design matching the current checks ever shows up the driver may end up doing something completely wrong. Avoid both issues by switching to using DMI based autoloading of the module, which has neither of these problems. Note this splits the previous intel_cht_int33fe kernel module into two modules: intel_cht_int33fe_typec and intel_cht_int33fe_microb, one for each model. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-2-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Minor charger / fuel-gauge improvementsHans de Goede1-24/+23
Minor charger / fuel-gauge improvements: 1. Make some of the names of charger / fuel-gauge related globals more generic in preparation for also using them on other boards. 2. Update the dev_name on the Asus ME176C and TF103C to reflect that these are using the bq24297 variant of the bq24190 family. 3. During review of the ug3105 driver the "upi,rsns-microohm" property was renamed to "upisemi,rsns-microohm" as "upisemi" is the correct vendor prefix, update the ug3105 properties accordingly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220206220220.88491-1-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Add Nextbook Ares 8 dataHans de Goede1-1/+87
The Nextbook Ares 8 is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there, causing various resource conflicts. Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Add support for manually instantiating the I2C devices which are actually present on this tablet by adding the necessary device info to the x86-android-tablets module. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-6-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Add IRQ to Asus ME176C accelerometer infoHans de Goede1-0/+6
Add the IRQ for the accelerometer to the Asus ME176C board info. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-5-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Add lid-switch gpio-keys pdev to Asus ME176C + TF103CHans de Goede1-4/+53
The Asus ME176C + TF103C both have a lid-switch (for a cover in the ME176C case), add a gpio-keys platform-device and platform-data describing the lid-switch on both. Note the "intel-int3496" in the asus_me176c_tf103c_pdevs[] array is not new / not a change. This was already present in the generic int3496_pdevs[] array, to which pdev_info pointed before. The int3496_pdevs[] array contains just this entry for boards which only need that single pdev. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-4-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Add x86_android_tablet_get_gpiod() helperHans de Goede1-12/+23
Factor the code to go from a gpiochip label + pin-numer to a gpio_desc out of x86_acpi_irq_helper_get() and make it into a new x86_android_tablet_get_gpiod() helper, as this will be necessary in some x86_dev_info.init() functions too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-3-hdegoede@redhat.com
2022-02-11platform/x86: x86-android-tablets: Add Asus ME176C/TF103C charger and fuelgauge propsHans de Goede1-11/+84
Add properties describing the battery on the Asus ME176C / TF103C tablets. The max constant charge volt / current settings were taken from the factory Android image on these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220205191356.225505-2-hdegoede@redhat.com