summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-31of: of_private.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31docs: dt: fix a broken reference to input.yamlMauro Carvalho Chehab
The old file was converted to yaml, but its reference was still pointing to the old one. Fixes: 7cef1079e3ad ("dt-bindings: input: Add common input binding in json-schema") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31docs: dt: fix references to ap806-system-controller.txtMauro Carvalho Chehab
ap806-system-controller.txt was renamed to ap80x-system-controller.txt. Update its references accordingly. Fixes: 2537831bbc19 ("dt-bindings: ap80x: replace AP806 with AP80x") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31docs: dt: fix references to m_can.txt fileMauro Carvalho Chehab
This file was converted to json and renamed. Update its references accordingly. Fixes: 824674b59f72 ("dt-bindings: net: can: Convert M_CAN to json-schema") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: pwm: renesas-tpu: Document more R-Car Gen2 supportGeert Uytterhoeven
All R-Car Gen2 SoCs have a Renesas Timer Pulse Unit. Document support for the missing variants. No driver change is needed due to the fallback compatible string. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: Add cros-ec Type C port driverPrashant Malani
Some Chrome OS devices with Embedded Controllers (EC) can read and modify Type C port state. Add an entry in the DT Bindings documentation that lists out the logical device and describes the relevant port information, to be used by the corresponding driver. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: leds: common: fix example for gpio-ledsJohan Jonker
The preferred form for gpio-leds compatible subnodes is: ^led-[0-9a-f]$ Fix example by changing led0 and led1 to led-0 and led-1. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: interrupt-controller: msi: Correct msi-controller@c's regBin Meng
The base address of msi-controller@c should be set to c. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: spi: Add interconnect binding for QSPIAkash Asthana
Add documentation for the interconnect and interconnect-names properties for QSPI. Signed-off-by: Akash Asthana <akashast@codeaurora.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: spi: Convert QSPI bindings to YAMLAkash Asthana
Convert QSPI bindings to DT schema format using json-schema. Signed-off-by: Akash Asthana <akashast@codeaurora.org> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: thermal: rcar-thermal: Convert bindings to json-schemaNiklas Söderlund
Convert Renesas R-Car Thermal bindings documentation to json-schema. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: phy: Convert phy-mmp3-usb to json-schemaLubomir Rintel
A rather straightforward conversion of the phy-mmp3-usb binding to DT schema format using json-schema. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> [robh: add additionalProperties] Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: Add "mrvl", a legacy vendor prefix for MarvellLubomir Rintel
While the preferred vendor prefix is "marvell", "mrvl" is used by many older bindings already. Add it, while also marking it deprecated. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: arm: mrvl: Add missing compatible stringsLubomir Rintel
Add compatible strings for the boards we have in tree. At the same time, fix the MMP3 compatible string: the preferred vendor name for Marvell is "marvell", not "mrvl", and indeed "marvell,mmp3" has been actively used, not "mrvl,mmp3". Fixes: 95aecb71b84e ("dt-bindings: arm: mrvl: Document MMP3 compatible string") Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: arm: l2x0: Tauros 3 is PL310 compatibleLubomir Rintel
The validation is unhappy about mmp3-dell-ariel declaring its marvell,tauros3-cache node to be compatible with arm,pl310-cache: mmp3-dell-ariel.dt.yaml: cache-controller@d0020000: compatible: Additional items are not allowed ('arm,pl310-cache' was unexpected) mmp3-dell-ariel.dt.yaml: cache-controller@d0020000: compatible: ['marvell,tauros3-cache', 'arm,pl310-cache'] is too long Let's allow this -- Tauros 3 is designed to be compatible with PL310. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> [robh: fixup indentation] Signed-off-by: Rob Herring <robh@kernel.org>
2020-03-31dt-bindings: Add missing 'additionalProperties: false'Rob Herring
Setting 'additionalProperties: false' is frequently omitted, but is important in order to check that there aren't extra undocumented properties in a binding. Ideally, we'd just add this automatically and make this the default, but there's some cases where it doesn't work. For example, if a common schema is referenced, then properties in the common schema aren't part of what's considered for 'additionalProperties'. Also, sometimes there are bus specific properties such as 'spi-max-frequency' that go into bus child nodes, but aren't defined in the child node's schema. So let's stick with the json-schema defined default and add 'additionalProperties: false' where needed. This will be a continual review comment and game of wack-a-mole. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Stephen Boyd <sboyd@kernel.org> # clock Acked-by: Lee Jones <lee.jones@linaro.org>
2020-03-31KVM: x86: Fix BUILD_BUG() in __cpuid_entry_get_reg() w/ CONFIG_UBSAN=ySean Christopherson
Take the target reg in __cpuid_entry_get_reg() instead of a pointer to a struct cpuid_reg. When building with -fsanitize=alignment (enabled by CONFIG_UBSAN=y), some versions of gcc get tripped up on the pointer and trigger the BUILD_BUG(). Reported-by: Randy Dunlap <rdunlap@infradead.org> Fixes: d8577a4c238f8 ("KVM: x86: Do host CPUID at load time to mask KVM cpu caps") Fixes: 4c61534aaae2a ("KVM: x86: Introduce cpuid_entry_{get,has}() accessors") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200325191259.23559-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: VMX: Add a trampoline to fix VMREAD error handlingSean Christopherson
Add a hand coded assembly trampoline to preserve volatile registers across vmread_error(), and to handle the calling convention differences between 64-bit and 32-bit due to asmlinkage on vmread_error(). Pass @field and @fault on the stack when invoking the trampoline to avoid clobbering volatile registers in the context of the inline assembly. Calling vmread_error() directly from inline assembly is partially broken on 64-bit, and completely broken on 32-bit. On 64-bit, it will clobber %rdi and %rsi (used to pass @field and @fault) and any volatile regs written by vmread_error(). On 32-bit, asmlinkage means vmread_error() expects the parameters to be passed on the stack, not via regs. Opportunistically zero out the result in the trampoline to save a few bytes of code for every VMREAD. A happy side effect of the trampoline is that the inline code footprint is reduced by three bytes on 64-bit due to PUSH/POP being more efficent (in terms of opcode bytes) than MOV. Fixes: 6e2020977e3e6 ("KVM: VMX: Add error handling to VMREAD helper") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200326160712.28803-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: SVM: Annotate svm_x86_ops as __initdataSean Christopherson
Tag svm_x86_ops with __initdata now the the struct is copied by value to a common x86 instance of kvm_x86_ops as part of kvm_init(). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-10-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: VMX: Annotate vmx_x86_ops as __initdataSean Christopherson
Tag vmx_x86_ops with __initdata now the the struct is copied by value to a common x86 instance of kvm_x86_ops as part of kvm_init(). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-9-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: x86: Drop __exit from kvm_x86_ops' hardware_unsetup()Sean Christopherson
Remove the __exit annotation from VMX hardware_unsetup(), the hook can be reached during kvm_init() by way of kvm_arch_hardware_unsetup() if failure occurs at various points during initialization. Removing the annotation also lets us annotate vmx_x86_ops and svm_x86_ops with __initdata; otherwise, objtool complains because it doesn't understand that the vendor specific __initdata is being copied by value to a non-__initdata instance. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-8-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: x86: Copy kvm_x86_ops by value to eliminate layer of indirectionSean Christopherson
Replace the kvm_x86_ops pointer in common x86 with an instance of the struct to save one pointer dereference when invoking functions. Copy the struct by value to set the ops during kvm_init(). Arbitrarily use kvm_x86_ops.hardware_enable to track whether or not the ops have been initialized, i.e. a vendor KVM module has been loaded. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-7-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: x86: Set kvm_x86_ops only after ->hardware_setup() completesSean Christopherson
Set kvm_x86_ops with the vendor's ops only after ->hardware_setup() completes to "prevent" using kvm_x86_ops before they are ready, i.e. to generate a null pointer fault instead of silently consuming unconfigured state. An alternative implementation would be to have ->hardware_setup() return the vendor's ops, but that would require non-trivial refactoring, and would arguably result in less readable code, e.g. ->hardware_setup() would need to use ERR_PTR() in multiple locations, and each vendor's declaration of the runtime ops would be less obvious. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-6-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: VMX: Configure runtime hooks using vmx_x86_opsSean Christopherson
Configure VMX's runtime hooks by modifying vmx_x86_ops directly instead of using the global kvm_x86_ops. This sets the stage for waiting until after ->hardware_setup() to set kvm_x86_ops with the vendor's implementation. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-5-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: VMX: Move hardware_setup() definition below vmx_x86_opsSean Christopherson
Move VMX's hardware_setup() below its vmx_x86_ops definition so that a future patch can refactor hardware_setup() to modify vmx_x86_ops directly instead of indirectly modifying the ops via the global kvm_x86_ops. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-4-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: x86: Move init-only kvm_x86_ops to separate structSean Christopherson
Move the kvm_x86_ops functions that are used only within the scope of kvm_init() into a separate struct, kvm_x86_init_ops. In addition to identifying the init-only functions without restorting to code comments, this also sets the stage for waiting until after ->hardware_setup() to set kvm_x86_ops. Setting kvm_x86_ops after ->hardware_setup() is desirable as many of the hooks are not usable until ->hardware_setup() completes. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-3-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31KVM: Pass kvm_init()'s opaque param to additional arch funcsSean Christopherson
Pass @opaque to kvm_arch_hardware_setup() and kvm_arch_check_processor_compat() to allow architecture specific code to reference @opaque without having to stash it away in a temporary global variable. This will enable x86 to separate its vendor specific callback ops, which are passed via @opaque, into "init" and "runtime" ops without having to stash away the "init" ops. No functional change intended. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Cornelia Huck <cohuck@redhat.com> #s390 Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Message-Id: <20200321202603.19355-2-sean.j.christopherson@intel.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-31io_uring: refactor file register/unregister/update handlingXiaoguang Wang
While diving into io_uring fileset register/unregister/update codes, we found one bug in the fileset update handling. io_uring fileset update use a percpu_ref variable to check whether we can put the previously registered file, only when the refcnt of the perfcpu_ref variable reaches zero, can we safely put these files. But this doesn't work so well. If applications always issue requests continually, this perfcpu_ref will never have an chance to reach zero, and it'll always be in atomic mode, also will defeat the gains introduced by fileset register/unresiger/update feature, which are used to reduce the atomic operation overhead of fput/fget. To fix this issue, while applications do IORING_REGISTER_FILES or IORING_REGISTER_FILES_UPDATE operations, we allocate a new percpu_ref and kill the old percpu_ref, new requests will use the new percpu_ref. Once all previous old requests complete, old percpu_refs will be dropped and registered files will be put safely. Link: https://lore.kernel.org/io-uring/5a8dac33-4ca2-4847-b091-f7dcd3ad0ff3@linux.alibaba.com/T/#t Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-31gpio: Avoid using pin ranges with !PINCTRLThierry Reding
Do not use the struct gpio_device's .pin_ranges field if the PINCTRL Kconfig symbol is not selected to avoid build failures. Fixes: 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200330090257.2332864-1-thierry.reding@gmail.com Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-31Merge tag 'kvm-ppc-next-5.7-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into HEAD KVM PPC update for 5.7 * Add a capability for enabling secure guests under the Protected Execution Framework ultravisor * Various bug fixes and cleanups.
2020-03-31Merge tag 'kvmarm-5.7' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm updates for Linux 5.7 - GICv4.1 support - 32bit host removal
2020-03-31pinctrl: qcom: fix compilation errorAnsuel Smith
pinctrl: qcom: use scm_call to route GPIO irq to Apps has a typo in the patch and introduced a compilation error. Fixes: 13bec8d4 pinctrl: qcom: use scm_call to route GPIO irq to Apps Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20200331134603.13513-1-ansuelsmth@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-31nvmet-fc: fix typo in commentJames Smart
Fix typo in comment: about should be abort Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chiatanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by: Himanshu Madhani <hmadhani@marvell.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
2020-03-31nvme-rdma: Replace comma with a semicolonIsrael Rukshin
Use a semicolon at the end of an assignment expression. Signed-off-by: Israel Rukshin <israelr@mellanox.com> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-03-31nvme-fcloop: fix deallocation of working contextJames Smart
There's been a longstanding bug of LS completions which freed ls ops, particularly the disconnect LS, while executing on a work context that is in the memory being free. Not a good thing to do. Rework LS handling to make callbacks in the rport context rather than the ls_request context. Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-03-31nvme: fix compat address handling in several ioctlsNick Bowler
On a 32-bit kernel, the upper bits of userspace addresses passed via various ioctls are silently ignored by the nvme driver. However on a 64-bit kernel running a compat task, these upper bits are not ignored and are in fact required to be zero for the ioctls to work. Unfortunately, this difference matters. 32-bit smartctl submits the NVME_IOCTL_ADMIN_CMD ioctl with garbage in these upper bits because it seems the pointer value it puts into the nvme_passthru_cmd structure is sign extended. This works fine on 32-bit kernels but fails on a 64-bit one because (at least on my setup) the addresses smartctl uses are consistently above 2G. For example: # smartctl -x /dev/nvme0n1 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.11] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Bad address Since changing 32-bit kernels to actually check all of the submitted address bits now would break existing userspace, this patch fixes the compat problem by explicitly zeroing the upper bits in the compat case. This enables 32-bit smartctl to work on a 64-bit kernel. Signed-off-by: Nick Bowler <nbowler@draconx.ca> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-03-31csky/ftrace: Fixup ftrace_modify_code deadlock without CPU_HAS_ICACHE_INSGuo Ren
If ICACHE_INS is not supported, we use IPI to sync icache on each core. But ftrace_modify_code is called from stop_machine from default implementation of arch_ftrace_update_code and stop_machine callback is irq_disabled. When you call ipi with irq_disabled, a deadlock will happen. We couldn't use icache_flush with irq_disabled, but startup make_nop is specific case and it needn't ipi other cores. Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
2020-03-31ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra ↵Andreas Steinmetz
endpoint descriptor The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra endpoint descriptor. The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00 As the code in snd_usbmidi_get_ms_info() looks only at the first extra descriptor to find USB_DT_CS_ENDPOINT the device as such is recognized but there is neither input nor output configured. The patch iterates through the extra descriptors to find the proper one. With this patch the device is correctly configured. Signed-off-by: Andreas Steinmetz <ast@domdv.de> Link: https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.camel@domdv.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-31Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h"Takashi Iwai
This reverts commit 645c08f17f477915f6d900b767e789852f150054 which was reported to break the build a program using this header. The original issue was addressed in the alsa-lib side recently, so we can make the header more self-contained again. Reported-by: Dmitry V. Levin <ldv@altlinux.org> Fixes: 645c08f17f47 ("ALSA: uapi: Drop asound.h inclusion from asoc.h") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200331090023.8112-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-31ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixupsThomas Hebb
patch_realtek.c has historically failed to properly configure the PC Beep Hidden Register for the ALC256 codec (among others). Depending on your kernel version, symptoms of this misconfiguration can range from chassis noise, picked up by a poorly-shielded PCBEEP trace, getting amplified and played on your internal speaker and/or headphones to loud feedback, which responds to the "Headphone Mic Boost" ALSA control, getting played through your headphones. For details of the problem, see the patch in this series titled "ALSA: hda/realtek - Set principled PC Beep configuration for ALC256", which fixes the configuration. These symptoms have been most noticed on the Dell XPS 13 9350 and 9360, popular laptops that use the ALC256. As a result, several model-specific fixups have been introduced to try and fix the problem, the most egregious of which locks the "Headphone Mic Boost" control as a hack to minimize noise from a feedback loop that shouldn't have been there in the first place. Now that the underlying issue has been fixed, remove all these fixups. Remaining fixups needed by the XPS 13 are all picked up by existing pin quirks. This change should, for the XPS 13 9350/9360 - Significantly increase volume and audio quality on headphones - Eliminate headphone popping on suspend/resume - Allow "Headphone Mic Boost" to be set again, making the headphone jack fully usable as a microphone jack too. Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3") Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360") Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant") Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360") Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-31ALSA: hda/realtek - Set principled PC Beep configuration for ALC256Thomas Hebb
The Realtek PC Beep Hidden Register[1] is currently set by patch_realtek.c in two different places: In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to non-beep input on 1Ah and no 1Ah loopback to either headphones or speakers. (Although, curiously, the loopback amp is still enabled.) This write was added fairly recently by commit e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") and is a safe default. However, it happens in the wrong place: alc_fill_eapd_coef() runs on module load and cold boot but not on S3 resume, meaning the register loses its value after suspend. Conversely, in alc256_init(), the register is updated to unset bit 13 (disable speaker loopback) and set bit 5 (set non-beep input on 1Ah). Although this write does run on S3 resume, it's not quite enough to fix up the register's default value of 0x3717. What's missing is a set of bit 14 to disable headphone loopback. Without that, we end up with a feedback loop where the headphone jack is being driven by amplified samples of itself[2]. This change eliminates the update in alc256_init() and replaces it with the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is supposed to be the codec's default value, so using it will make debugging easier for Realtek. Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs. [1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst [2] Setting the "Headphone Mic Boost" control from userspace changes this feedback loop and has been a widely-shared workaround for headphone noise on laptops like the Dell XPS 13 9350. This commit eliminates the feedback loop and makes the workaround unnecessary. Fixes: e1e8c1fdce8b ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-31ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256Thomas Hebb
This codec (among others) has a hidden set of audio routes, apparently designed to allow PC Beep output without a mixer widget on the output path, which are controlled by an undocumented Realtek vendor register. The default configuration of these routes means that certain inputs aren't accessible, necessitating driver control of the register. However, Realtek has provided no documentation of the register, instead opting to fix issues by providing magic numbers, most of which have been at least somewhat erroneous. These magic numbers then get copied by others into model-specific fixups, leading to a fragmented and buggy set of configurations. To get out of this situation, I've reverse engineered the register by flipping bits and observing how the codec's behavior changes. This commit documents my findings. It does not change any code. Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-31PCI: endpoint: Fix clearing start entry in configfsKunihiko Hayashi
After an endpoint is started through configfs, if 0 is written to the configfs entry 'start', the controller stops but the epc_group->start value remains 1. A subsequent unlinking of the function from the controller would trigger a spurious WARN_ON_ONCE() in pci_epc_epf_unlink() despite right behavior. Fix it by setting epc_group->start = 0 when a controller is stopped using configfs. Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com>
2020-03-31PCI: tegra: Add support for PCIe endpoint mode in Tegra194Vidya Sagar
Add support for the endpoint mode of Synopsys DesignWare core based dual mode PCIe controllers present in Tegra194 SoC. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thierry Reding <treding@nvidia.com>
2020-03-31fbcon: fix null-ptr-deref in fbcon_switchQiujun Huang
Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated. syzkaller report: https://lkml.org/lkml/2020/3/27/403 general protection fault, probably for non-canonical address 0xdffffc000000006c: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367] RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260 Call Trace: redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295 fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219 visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062 do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542 do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122 do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588 fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259 do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline] register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832 dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735 usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374 accessing vc_cons[logo_shown].d->vc_top causes the bug. Reported-by: syzbot+732528bae351682f1f27@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200329085647.25133-1-hqjagain@gmail.com
2020-03-31Merge tag 'drm-msm-next-2020-03-22' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next A bit smaller this time around.. there are still a couple uabi additions for vulkan waiting in the wings, but I punted on them this cycle due to running low on time. (They should be easy enough to rebase, and if it is a problem for anyone I can push a next+uabi branch so that tu work can proceed.) The bigger change is refactoring dpu resource manager and moving dpu to use atomic global state. Other than that, it is mostly cleanups and fixes. From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGuf1R4Xz-t9Z7_cwx9jD=b4wUvvwfqA5cHR8fCSXSd5XQ@mail.gmail.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-03-31Merge v5.6 into drm-nextDave Airlie
msm needed rc6, so I just went and merged release (msm has been in drm-next outside of this tree) Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-03-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
2020-03-30f2fs: compress: add .{init,destroy}_decompress_ctx callbackChao Yu
Add below two callback interfaces in struct f2fs_compress_ops: int (*init_decompress_ctx)(struct decompress_io_ctx *dic); void (*destroy_decompress_ctx)(struct decompress_io_ctx *dic); Which will be used by zstd compress algorithm later. In addition, this patch adds callback function pointer check, so that specified algorithm can avoid defining unneeded functions. Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2020-03-30f2fs: compress: fix to call missing destroy_compress_ctx()Chao Yu
Otherwise, it will cause memory leak. Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-14 23:26:45 +0000