summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-18of: property: fw_devlink: Add support for "phy-handle" propertySaravana Kannan1-0/+2
Allows tracking dependencies between Ethernet PHYs and their consumers. Cc: Andrew Lunn <andrew@lunn.ch> Cc: netdev@vger.kernel.org Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210818021717.3268255-1-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-18Merge tag 'for-5.14-rc6-tag' of ↵Linus Torvalds1-2/+8
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "One more fix for cross-rename, adding a missing check for directory and subvolume, this could lead to a crash" * tag 'for-5.14-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: prevent rename2 from exchanging a subvol with a directory from different parents
2021-08-18Merge tag 'sound-5.14-rc7' of ↵Linus Torvalds7-9/+35
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Only a few regression fixes and trivial device quirks" * tag 'sound-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/via: Apply runtime PM workaround for ASUS B23E ALSA: hda: Fix hang during shutdown due to link reset ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9510 laptop ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWire ALSA: hda - fix the 'Capture Switch' value change notifications
2021-08-18Merge tag 'cfi-v5.14-rc7' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull clang cfi fix from Kees Cook: - Use rcu_read_{un}lock_sched_notrace to avoid recursion (Elliot Berman) * tag 'cfi-v5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: cfi: Use rcu_read_{un}lock_sched_notrace
2021-08-18drm/mgag200: Fix uninitialized variable deltaColin Ian King1-0/+1
The variable delta is not initialized and this will cause unexpected behaviour with the comparison of tmpdelta < delta. Fix this by setting it to 0xffffffff. This matches the behaviour as in the similar function mgag200_pixpll_compute_g200se_04. v2: * move fix up by one line to align style with other functions * add additional tags from similar patch Signed-off-by: Colin Ian King <colin.king@canonical.com> Fixes: 2545ac960364 ("drm/mgag200: Abstract pixel PLL via struct mgag200_pll") Addresses-Coverity: ("Uninitialized scalar variable") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210817163204.494166-1-colin.king@canonical.com
2021-08-18pipe: avoid unnecessary EPOLLET wakeups under normal loadsLinus Torvalds2-6/+11
I had forgotten just how sensitive hackbench is to extra pipe wakeups, and commit 3a34b13a88ca ("pipe: make pipe writes always wake up readers") ended up causing a quite noticeable regression on larger machines. Now, hackbench isn't necessarily a hugely meaningful benchmark, and it's not clear that this matters in real life all that much, but as Mel points out, it's used often enough when comparing kernels and so the performance regression shows up like a sore thumb. It's easy enough to fix at least for the common cases where pipes are used purely for data transfer, and you never have any exciting poll usage at all. So set a special 'poll_usage' flag when there is polling activity, and make the ugly "EPOLLET has crazy legacy expectations" semantics explicit to only that case. I would love to limit it to just the broken EPOLLET case, but the pipe code can't see the difference between epoll and regular select/poll, so any non-read/write waiting will trigger the extra wakeup behavior. That is sufficient for at least the hackbench case. Apart from making the odd extra wakeup cases more explicitly about EPOLLET, this also makes the extra wakeup be at the _end_ of the pipe write, not at the first write chunk. That is actually much saner semantics (as much as you can call any of the legacy edge-triggered expectations for EPOLLET "sane") since it means that you know the wakeup will happen once the write is done, rather than possibly in the middle of one. [ For stable people: I'm putting a "Fixes" tag on this, but I leave it up to you to decide whether you actually want to backport it or not. It likely has no impact outside of synthetic benchmarks - Linus ] Link: https://lore.kernel.org/lkml/20210802024945.GA8372@xsang-OptiPlex-9020/ Fixes: 3a34b13a88ca ("pipe: make pipe writes always wake up readers") Reported-by: kernel test robot <oliver.sang@intel.com> Tested-by: Sandeep Patil <sspatil@android.com> Tested-by: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-18platform/x86: gigabyte-wmi: add support for B450M S2H V2Thomas Weißschuh1-0/+1
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-901207693 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210818164435.99821-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-18batman-adv: bcast: remove remaining skb-copy callsLinus Lüssing1-2/+10
We currently have two code paths for broadcast packets: A) self-generated, via batadv_interface_tx()-> batadv_send_bcast_packet(). B) received/forwarded, via batadv_recv_bcast_packet()-> batadv_forw_bcast_packet(). For A), self-generated broadcast packets: The only modifications to the skb data is the ethernet header which is added/pushed to the skb in batadv_send_broadcast_skb()->batadv_send_skb_packet(). However before doing so, batadv_skb_head_push() is called which calls skb_cow_head() to unshare the space for the to be pushed ethernet header. So for this case, it is safe to use skb clones. For B), received/forwarded packets: The same applies as in A) for the to be forwarded packets. Only the ethernet header is added. However after (queueing for) forwarding the packet in batadv_recv_bcast_packet()->batadv_forw_bcast_packet(), a packet is additionally decapsulated and is sent up the stack through batadv_recv_bcast_packet()->batadv_interface_rx(). Protocols higher up the stack are already required to check if the packet is shared and create a copy for further modifications. When the next (protocol) layer works correctly, it cannot happen that it tries to operate on the data behind the skb clone which is still queued up for forwarding. Co-authored-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
2021-08-18erofs: add fiemap support with iomapGao Xiang5-1/+59
This adds fiemap support for both uncompressed files and compressed files by using iomap infrastructure. Link: https://lore.kernel.org/r/20210813052931.203280-3-hsiangkao@linux.alibaba.com Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2021-08-18erofs: add support for the full decompressed lengthGao Xiang2-8/+92
Previously, there is no need to get the full decompressed length since EROFS supports partial decompression. However for some other cases such as fiemap, the full decompressed length is necessary for iomap to make it work properly. This patch adds a way to get the full decompressed length. Note that it takes more metadata overhead and it'd be avoided if possible in the performance sensitive scenario. Link: https://lore.kernel.org/r/20210818152231.243691-1-hsiangkao@linux.alibaba.com Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2021-08-18dt-bindings: thermal: Add dt binding for QCOM LMhThara Gopinath1-0/+82
Add dt binding documentation to describe Qualcomm Limits Management Hardware node. Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210809191605.3742979-8-thara.gopinath@linaro.org
2021-08-18libbpf: Rename libbpf documentation index fileGrant Seltzer2-1/+9
This patch renames a documentation libbpf.rst to index.rst. In order for readthedocs.org to pick this file up and properly build the documentation site. It also changes the title type of the ABI subsection in the naming convention doc. This is so that readthedocs.org doesn't treat this section as a separate document. Signed-off-by: Grant Seltzer <grantseltzer@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210818151313.49992-1-grantseltzer@gmail.com
2021-08-18usb: gadget: mv_u3d: request_irq() after initializing UDCNadezda Lutovinova1-9/+10
If IRQ occurs between calling request_irq() and mv_u3d_eps_init(), then null pointer dereference occurs since u3d->eps[] wasn't initialized yet but used in mv_u3d_nuke(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18dma-mapping: add a dma_init_global_coherent helperChristoph Hellwig2-19/+15
Add a new helper to initialize the global coherent pool. This both cleans up the existing initialization which indirects through the reserved_mem_ops that are normally only used for struct device, and also allows using the global pool for non-devicetree architectures. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18dma-mapping: simplify dma_init_coherent_memoryChristoph Hellwig1-45/+33
Return the allocated dma_coherent_mem structure, set the use_dma_pfn_offset and print the failure warning inside of dma_init_coherent_memory instead of leaving that to the callers. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18dma-mapping: allow using the global coherent pool for !ARMChristoph Hellwig1-0/+2
Switch an ifdef so that the global coherent pool is initialized for any architecture that selects the DMA_GLOBAL_POOL symbol insted of hardcoding ARM. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18ARM/nommu: use the generic dma-direct code for non-coherent devicesChristoph Hellwig2-169/+9
Select the right options to just use the generic dma-direct code instead of reimplementing it. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18dma-direct: add support for dma_coherent_default_memoryChristoph Hellwig2-0/+19
Add an option to allocate uncached memory for dma_alloc_coherent from the global dma_coherent_default_memory. This will allow to move arm-nommu (and eventually other platforms) to use generic code for allocating uncached memory from a pre-populated pool. Note that this is a different pool from the one that platforms that can remap at runtime use for GFP_ATOMIC allocations for now, although there might be opportunities to eventually end up with a common codebase for the two use cases. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Dillon Min <dillon.minfei@gmail.com>
2021-08-18Merge branch 'restrict-digest-alg-v8' into next-integrityMimi Zohar7-35/+268
Taken from the cover letter "IMA: restrict the accepted digest algorithms for the security.ima xattr": Provide users the ability to restrict the algorithms accepted by their system, both when writing/updating xattrs, and when appraising files, while retaining a permissive behavior by default to preserve backward compatibility. To provide these features, alter the behavior of setxattr to only accept hashes built in the kernel, instead of any hash listed in the kernel (complete list crypto/hash_info.c). In addition, the user can define in his IMA policy the list of digest algorithms allowed for writing to the security.ima xattr. In that case, only algorithms present in that list are accepted for writing. In addition, users may opt-in to allowlist hash algorithms for appraising thanks to the new 'appraise_algos' IMA policy option. By default IMA will keep accepting any hash algorithm, but specifying that option will make appraisal of files hashed with another algorithm fail. Link: https://lore.kernel.org/linux-integrity/20210816081056.24530-1-Simon.THOBY@viveris.fr/
2021-08-18driver core: platform: Remove platform_device_add_properties()Heikki Krogerus2-20/+2
There are no more users for it. The last place where it's called is in platform_device_register_full(). Replacing that call with device_create_managed_software_node() and removing the function. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210817102449.39994-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18ARM: tegra: paz00: Handle device properties with software node APIHeikki Krogerus1-1/+1
The old device property API is going to be removed. Replacing the device_add_properties() call with the software node API equivalent, device_create_managed_software_node(). Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210817102449.39994-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18tty: serial: fsl_lpuart: check dma_tx_in_progress in tx dma callbackFugang Duan1-0/+4
There have a corner case that tx DMA .callback() is coming after .flush_buffer(), then .callback() should check dma_tx_in_progress flag and return in directly. Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20210817100203.21300-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18firmware: raspberrypi: Fix a leak in 'rpi_firmware_get()'Christophe JAILLET1-2/+8
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the normal and error handling paths. Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e17e5409b934cd08bf6f9279c73be5c1cb11cce.1628232242.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: typec: tcpm: Fix VDMs sometimes not being forwarded to alt-mode driversHans de Goede1-6/+7
Commit a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo"), stops tcpm_pd_data_request() calling tcpm_handle_vdm_request() when port->nr_snk_vdo is not set. But the VDM might be intended for an altmode-driver, in which case nr_snk_vdo does not matter. This change breaks the forwarding of connector hotplug (HPD) events for displayport altmode on devices which don't set nr_snk_vdo. tcpm_pd_data_request() is the only caller of tcpm_handle_vdm_request(), so we can move the nr_snk_vdo check to inside it, at which point we have already looked up the altmode device so we can check for this too. Doing this check here also ensures that vdm_state gets set to VDM_STATE_DONE if it was VDM_STATE_BUSY, even if we end up with responding with PD_MSG_CTRL_NOT_SUPP later. Note that tcpm_handle_vdm_request() was already sending PD_MSG_CTRL_NOT_SUPP in some circumstances, after moving the nr_snk_vdo check the same error-path is now taken when that check fails. So that we have only one error-path for this and not two. Replace the tcpm_queue_message(PD_MSG_CTRL_NOT_SUPP) used by the existing error-path with the more robust tcpm_pd_handle_msg() from the (now removed) second error-path. Fixes: a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo") Cc: stable <stable@vger.kernel.org> Cc: Kyle Tso <kyletso@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Kyle Tso <kyletso@google.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210816154632.381968-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18powerpc/xive: Do not mark xive_request_ipi() as __initNathan Chancellor1-1/+1
Compiling ppc64le_defconfig with clang-14 shows a modpost warning: WARNING: modpost: vmlinux.o(.text+0xa74e0): Section mismatch in reference from the function xive_setup_cpu_ipi() to the function .init.text:xive_request_ipi() The function xive_setup_cpu_ipi() references the function __init xive_request_ipi(). This is often because xive_setup_cpu_ipi lacks a __init annotation or the annotation of xive_request_ipi is wrong. xive_request_ipi() is called from xive_setup_cpu_ipi(), which is not __init, so xive_request_ipi() should not be marked __init. Remove the attribute so there is no more warning. Fixes: cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210816185711.21563-1-nathan@kernel.org
2021-08-18powerpc/32: Remove unneccessary calculations in load_up_{fpu/altivec}Christophe Leroy2-5/+2
No need to re-read SPRN_THREAD, we can calculate thread address from current (r2). And remove a reload of value 1 into r4 as r4 is already 1. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/c04cce578b97a76a9e69a096698b1d89f721768a.1629276437.git.christophe.leroy@csgroup.eu
2021-08-18Merge tag 'ixp4xx-del-boardfiles-v5.15' of ↵Arnd Bergmann25-3888/+0
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into arm/soc This deletes the following IXP4xx boardfiles: - NSLU2 - NAS100D - D-Link DSM-G600 - Omicron - Gateway WG302v2 - Arcom Vulcan - Avila - Intel reference designs - Coyote and IXDPG425 - GTW5715 - Freecom FSG-3 In each case except Omicron, the board has been replaced by a corresponding device tree and tested where someone volunteered: Marc Zyngier has tested Arcom Vulcan and Freecom FSG-3 and I have tested NSLU2 and Avila for example. All that were tested boot to prompt, some devices may need some more massage before working perfectly. We can just as well delete these board files because we are confident that we will fix them to a working state if people are able to test patches. I am holding back the following boards for now: - Gateway 7001 - because Zoltan is working on this board and needs more time. He might need to test things with the board file so let's allow him time for that. - Goramo MLR - the consensus is to replace this with a dry coded device tree, but the bindings for that tree need some more time to make so we keep the boardfile around until we can merge a complete device tree for it. After these two (target v5.16) we can delete the remaining board files and the old mach structure along with the old PCI driver. * tag 'ixp4xx-del-boardfiles-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik: ARM: ixp4xx: Delete the Freecom FSG-3 boardfiles ARM: ixp4xx: Delete GTWX5715 board files ARM: ixp4xx: Delete Coyote and IXDPG425 boardfiles ARM: ixp4xx: Delete Intel reference design boardfiles ARM: ixp4xx: Delete Avila boardfiles ARM: ixp4xx: Delete the Arcom Vulcan boardfiles ARM: ixp4xx: Delete Gateway WG302v2 boardfiles ARM: ixp4xx: Delete Omicron boardfiles ARM: ixp4xx: Delete the D-Link DSM-G600 boardfiles ARM: ixp4xx: Delete NAS100D boardfiles ARM: ixp4xx: Delete NSLU2 boardfiles Link: https://lore.kernel.org/r/CACRpkdY=sPDkzmbmm+0UQnJi7BXZKH14GLmyVwKC+4cLCJpmdA@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'qcom-drivers-for-5.15' of ↵Arnd Bergmann21-148/+269
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers Qualcomm driver updates for v5.15 This fixes the "shared memory state machine" (SMSM) interrupt logic to avoid missing transitions happening while the interrupts are masked. SM6115 support is added to smd-rpm and rpmpd. The Qualcomm SCM firmware driver is once again made possible to compile and load as a kernel module. An out-of-bounds error related to the cooling devices of the AOSS driver is corrected. The binding is converted to YAML and a generic compatible is introduced to reduce the driver churn. The GENI wrapper gains a helper function used in I2C and SPI for switching the serial engine hardware to use the wrapper's DMA-engine. Lastly it contains a number of cleanups and smaller fixes for rpmhpd, socinfo, CPR, mdt_loader and the GENI DT binding. * tag 'qcom-drivers-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: smsm: Fix missed interrupts if state changes while masked soc: qcom: smsm: Implement support for get_irqchip_state soc: qcom: mdt_loader: be more informative on errors dt-bindings: qcom: geni-se: document iommus soc: qcom: smd-rpm: Add SM6115 compatible soc: qcom: geni: Add support for gpi dma soc: qcom: geni: move GENI_IF_DISABLE_RO to common header PM: AVS: qcom-cpr: Use nvmem_cell_read_variable_le_u32() drivers: soc: qcom: rpmpd: Add SM6115 RPM Power Domains dt-bindings: power: rpmpd: Add SM6115 to rpmpd binding dt-bindings: soc: qcom: smd-rpm: Add SM6115 compatible soc: qcom: aoss: Fix the out of bound usage of cooling_devs firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module soc: qcom: socinfo: Don't print anything if nothing found soc: qcom: rpmhpd: Use corner in power_off soc: qcom: aoss: Add generic compatible dt-bindings: soc: qcom: aoss: Convert to YAML dt-bindings: soc: qcom: aoss: Add SC8180X and generic compatible firmware: qcom_scm: remove a duplicative condition firmware: qcom_scm: Mark string array const Link: https://lore.kernel.org/r/20210816214840.581244-1-bjorn.andersson@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18usb: gadget: f_uac1: fixing inconsistent indentingPavel Hofman1-6/+6
Fixing inconsistent indenting identified by kernel test robot. Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com> Acked-By: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20210817100555.4437-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: remove reference to deleted config STB03xxxLukas Bulwahn1-1/+1
Commit 7583b63c343c ("powerpc/40x: Remove STB03xxx") removes the config STB03xxx, but left a reference in ./drivers/usb/Kconfig behind. Hence, ./scripts/checkkconfigsymbols.py warns: STB03xxx Referencing files: drivers/usb/Kconfig Remove this reference to the deleted config. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-4-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: host: remove line for obsolete config USB_HWA_HCDLukas Bulwahn1-1/+0
Commit 71ed79b0e4be ("USB: Move wusbcore and UWB to staging as it is obsolete") misses to adjust some part in ./drivers/usb/host/Makefile. Hence, ./scripts/checkkconfigsymbols.py warns: USB_HWA_HCD Referencing files: drivers/usb/Makefile Remove the missing piece of this code removal. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-3-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: host: remove dead EHCI support for on-chip PMC MSP71xx USB controllerLukas Bulwahn3-342/+0
Commit 1b00767fd8e1 ("MIPS: Remove PMC MSP71xx platform") deletes ./arch/mips/pmcs-msp71xx/Kconfig, including its config MSP_HAS_USB. Hence, since then, the corresponding EHCI support for on-chip PMC MSP71xx USB controller is dead code. Remove this dead driver. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-2-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18Merge tag 'renesas-drivers-for-v5.15-tag2' of ↵Arnd Bergmann2-4/+8
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers Renesas driver updates for v5.15 (take two) - Prefer memcpy() over strcpy(). * tag 'renesas-drivers-for-v5.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: Prefer memcpy() over strcpy() Link: https://lore.kernel.org/r/cover.1628849625.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18usb: dwc3: Decouple USB 2.0 L1 & L2 eventsJack Pham2-2/+12
On DWC_usb3 revisions 3.00a and newer (including DWC_usb31 and DWC_usb32) the GUCTL1 register gained the DEV_DECOUPLE_L1L2_EVT field (bit 31) which when enabled allows the controller in device mode to treat USB 2.0 L1 LPM & L2 events separately. After commit d1d90dd27254 ("usb: dwc3: gadget: Enable suspend events") the controller will now receive events (and therefore interrupts) for every state change when entering/exiting either L1 or L2 states. Since L1 is handled entirely by the hardware and requires no software intervention, there is no need to even enable these events and unnecessarily notify the gadget driver. Enable the aforementioned bit to help reduce the overall interrupt count for these L1 events that don't need to be handled while retaining the events for full L2 suspend/wakeup. Tested-by: Jun Li <jun.li@nxp.com> Tested-by: Amit Pundir <amit.pundir@linaro.org> # for RB5 (sm8250) Tested-by: John Stultz <john.stultz@linaro.org> # for HiKey960 & db845c Reviewed-by: Jun Li <jun.li@nxp.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210812082635.12924-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18Merge tag 'nvme-5.15-2021-08-18' of git://git.infradead.org/nvme into ↵Jens Axboe17-123/+295
for-5.15/drivers Pull NVMe updates from Christoph: "nvme updates for Linux 5.15. - suspend improvements for devices with an HMB (Keith Busch) - handle double completions more gacefull (Sagi Grimberg) - cleanup the selects for the nvme core code a bit (Sagi Grimberg) - don't update queue count when failing to set io queues (Ruozhu Li) - various nvmet connect fixes (Amit Engel) - cleanup lightnvm leftovers (Keith Busch, me) - small cleanups (Colin Ian King, Hou Pu) - add tracing for the Set Features command (Hou Pu) - CMB sysfs cleanups (Keith Busch) - add a mutex_destroy call (Keith Busch)" * tag 'nvme-5.15-2021-08-18' of git://git.infradead.org/nvme: (21 commits) nvme: remove the unused NVME_NS_* enum nvme: remove nvm_ndev from ns nvme: Have NVME_FABRICS select NVME_CORE instead of transport drivers nvmet: check that host sqsize does not exceed ctrl MQES nvmet: avoid duplicate qid in connect cmd nvmet: pass back cntlid on successful completion nvme-rdma: don't update queue count when failing to set io queues nvme-tcp: don't update queue count when failing to set io queues nvme-tcp: pair send_mutex init with destroy nvme: allow user toggling hmb usage nvme-pci: disable hmb on idle suspend nvmet: remove redundant assignments of variable status nvmet: add set feature tracing support nvme: add set feature tracing support nvme-fabrics: remove superfluous nvmf_host_put in nvmf_parse_options nvme-pci: cmb sysfs: one file, one value nvme-pci: use attribute group for cmb sysfs nvme: code command_id with a genctr for use-after-free validation nvme-tcp: don't check blk_mq_tag_to_rq when receiving pdu data nvme-pci: limit maximum queue depth to 4095 ...
2021-08-18Merge tag 'tegra-for-5.15-soc' of ↵Arnd Bergmann10-20/+100
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers soc/tegra: Changes for v5.15-rc1 Implements runtime PM support for the FUSE block and prepares the driver to work better in conjunction with the CPUIDLE driver. * tag 'tegra-for-5.15-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: fuse: Enable fuse clock on suspend for Tegra124 soc/tegra: fuse: Add runtime PM support soc/tegra: fuse: Clear fuse->clk on driver probe failure soc/tegra: pmc: Prevent racing with cpuilde driver soc/tegra: bpmp: Remove unused including <linux/version.h> Link: https://lore.kernel.org/r/20210813162157.2820913-3-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18block: fix default IO priority handlingDamien Le Moal4-7/+13
The default IO priority is the best effort (BE) class with the normal priority level IOPRIO_NORM (4). However, get_task_ioprio() returns IOPRIO_CLASS_NONE/IOPRIO_NORM as the default priority and get_current_ioprio() returns IOPRIO_CLASS_NONE/0. Let's be consistent with the defined default and have both of these functions return the default priority IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_NORM) when the user did not define another default IO priority for the task. In include/uapi/linux/ioprio.h, introduce the IOPRIO_BE_NORM macro as an alias to IOPRIO_NORM to clarify that this default level applies to the BE priotity class. In include/linux/ioprio.h, define the macro IOPRIO_DEFAULT as IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_BE_NORM) and use this new macro when setting a priority to the default. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210811033702.368488-7-damien.lemoal@wdc.com [axboe: drop unnecessary lightnvm change] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18Merge tag 'tegra-for-5.15-firmware' of ↵Arnd Bergmann1-11/+47
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers firmware: tegra: Changes for v5.15-rc1 This contains a single fix to stop a slight abuse of the seq_buf API. * tag 'tegra-for-5.15-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: firmware: tegra: Stop using seq_get_buf() Link: https://lore.kernel.org/r/20210813162157.2820913-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18block: Introduce IOPRIO_NR_LEVELSDamien Le Moal6-14/+14
The BFQ scheduler and ioprio_check_cap() both assume that the RT priority class (IOPRIO_CLASS_RT) can have up to 8 different priority levels, similarly to the BE class (IOPRIO_CLASS_iBE). This is controlled using the IOPRIO_BE_NR macro , which is badly named as the number of levels also applies to the RT class. Introduce the class independent IOPRIO_NR_LEVELS macro, defined to 8, to make things clear. Keep the old IOPRIO_BE_NR macro definition as an alias for IOPRIO_NR_LEVELS. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210811033702.368488-6-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18block: fix IOPRIO_PRIO_CLASS() and IOPRIO_PRIO_VALUE() macrosDamien Le Moal1-4/+8
The ki_ioprio field of struct kiocb is 16-bits (u16) but often handled as an int in the block layer. E.g. ioprio_check_cap() takes an int as argument. With such implicit int casting function calls, the upper 16-bits of the int argument may be left uninitialized by the compiler, resulting in invalid values for the IOPRIO_PRIO_CLASS() macro (garbage upper bits) and in an error return for functions such as ioprio_check_cap(). Fix this by masking the result of the shift by IOPRIO_CLASS_SHIFT bits in the IOPRIO_PRIO_CLASS() macro. The new macro IOPRIO_CLASS_MASK defines the 3-bits mask for the priority class. Similarly, apply the IOPRIO_PRIO_MASK mask to the data argument of the IOPRIO_PRIO_VALUE() macro to ignore the upper bits of the data value. The IOPRIO_CLASS_MASK mask is also applied to the class argument of this macro before shifting the result by IOPRIO_CLASS_SHIFT bits. While at it, also change the argument name of the IOPRIO_PRIO_CLASS() and IOPRIO_PRIO_DATA() macros from "mask" to "ioprio" to reflect the fact that a priority value should be passed rather than a mask. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210811033702.368488-5-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18block: change ioprio_valid() to an inline functionDamien Le Moal2-2/+10
Change the ioprio_valid() macro in include/usapi/linux/ioprio.h to an inline function declared on the kernel side in include/linux/ioprio.h. Also improve checks on the class value by checking the upper bound value. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210811033702.368488-4-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18block: improve ioprio class description commentDamien Le Moal1-4/+6
In include/usapi/linux/ioprio.h, change the ioprio class enum comment to remove the outdated reference to CFQ and mention BFQ and mq-deadline instead. Also document the high priority NCQ command use for RT class IOs directed at ATA drives that support NCQ priority. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210811033702.368488-3-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18block: bfq: fix bfq_set_next_ioprio_data()Damien Le Moal1-1/+1
For a request that has a priority level equal to or larger than IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This is not consistent with the warning and the allowed values for priority levels. Fix this by setting the request new_ioprio field to IOPRIO_BE_NR - 1, the lowest priority level allowed. Cc: <stable@vger.kernel.org> Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210811033702.368488-2-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18docs: sysfs-block-device: document ncq_prio_supportedDamien Le Moal1-1/+24
Add documentation for the new device attribute file ncq_prio_supported, and its SAS HBA equivalent sas_ncq_prio_supported. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-12-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18docs: sysfs-block-device: improve ncq_prio_enable documentationNiklas Cassel1-3/+17
NCQ priority is an optional feature of the NCQ feature set and should not be confused with the NCQ feature set itself. Clarify the description of the ncq_prio_enable attribute to avoid this confusion. Also add the missing documentation for the equivalent sas_ncq_prio_enable attribute. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-11-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18libata: Introduce ncq_prio_supported sysfs sttributeDamien Le Moal3-0/+27
Currently, the only way a user can determine if a SATA device supports NCQ priority is to try to enable the use of this feature using the ncq_prio_enable sysfs device attribute. If enabling the feature fails, it is because the device does not support NCQ priority. Otherwise, the feature is enabled and success indicates that the device supports NCQ priority. Improve this odd interface by introducing the read-only ncq_prio_supported sysfs device attribute to indicate if a SATA device supports NCQ priority. The value of this attribute reflects the status of device flag ATA_DFLAG_NCQ_PRIO, which is set only for devices supporting NCQ priority. Add this new sysfs attribute to the device attributes group of libahci and libata-sata. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210816014456.2191776-10-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18libata: print feature list on device scanDamien Le Moal2-0/+21
Print a list of features supported by a drive when it is configured in ata_dev_configure() using the new function ata_dev_print_features(). The features printed are not already advertized and are: trusted send-recev support, device attention support, device sleep support, NCQ send-recv support and NCQ priority support. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-9-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18libata: fix ata_read_log_page() warningDamien Le Moal1-34/+13
Support for the READ LOG PAGE DMA EXT command is indicated by words 119 and 120 of a device identify data. This is tested in ata_read_log_page() with ata_id_has_read_log_dma_ext() and the READ LOG PAGE DMA command used if the device reports supports for it. However, some devices lie about this support and using the DMA version of the command fails, generating the warning message "READ LOG DMA EXT failed, trying PIO". Since READ LOG PAGE DMA EXT is an optional command, this warning is not at all important but may be scary for the user. Change ata_read_log_page() to suppres this warning and to print an error message if both DMA and PIO attempts failed. With this change, there is no need to print again an error message when ata_read_log_page() returns an error. So simplify the users of this function. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-8-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18libata: cleanup NCQ priority handlingDamien Le Moal2-43/+26
The ata device flag ATA_DFLAG_NCQ_PRIO indicates if a device supports the NCQ Priority feature while the ATA_DFLAG_NCQ_PRIO_ENABLE device flag indicates if the feature is enabled. Enabling NCQ priority use is controlled by the user through the device sysfs attribute ncq_prio_enable. As a result, the ATA_DFLAG_NCQ_PRIO flag should not be cleared when ATA_DFLAG_NCQ_PRIO_ENABLE is not set as the device still supports the feature even after the user disables it. This leads to the following cleanups: - In ata_build_rw_tf(), set a command high priority bit based on the ATA_DFLAG_NCQ_PRIO_ENABLE flag, not on the ATA_DFLAG_NCQ flag. That is, set a command high priority only if the user enabled NCQ priority use. - In ata_dev_config_ncq_prio(), ATA_DFLAG_NCQ_PRIO should not be cleared if ATA_DFLAG_NCQ_PRIO_ENABLE is not set. If the device does not support NCQ priority, both ATA_DFLAG_NCQ_PRIO and ATA_DFLAG_NCQ_PRIO_ENABLE must be cleared. With the above ata_dev_config_ncq_prio() change, ATA_DFLAG_NCQ_PRIO flag is set on device scan and revalidation. There is no need to trigger a device revalidation in ata_ncq_prio_enable_store() when the user enables the use of NCQ priority. Remove the revalidation code from that funciton to simplify it. Also change the return value from -EIO to -EINVAL when a user tries to enable NCQ priority for a device that does not support this feature. While at it, also simplify ata_ncq_prio_enable_show(). Overall, there is no functional change introduced by this patch. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-7-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-18libata: cleanup ata_dev_configure()Damien Le Moal1-56/+75
Introduce the helper functions ata_dev_config_lba() and ata_dev_config_chs() to configure the addressing capabilities of a device. To control message printing in these new helpers, as well as in ata_dev_configure() and in ata_hpa_resize(), add the helper function ata_dev_print_info() to avoid open coding for the eh context ATA_EHI_PRINTINFO flag in multiple functions. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-6-damien.lemoal@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>