aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-08-06cxl/core: Move pmem functionalityDan Williams4-202/+225
Refactor the pmem / nvdimm-bridge functionality from core/bus.c to core/pmem.c. Introduce drivers/core/core.h to communicate data structures and helpers between the core bus and other functionality that registers devices on the bus. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/162792538899.368511.3881663908293411300.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-08-06cxl/core: Improve CXL core kernel docsBen Widawsky1-2/+9
Now that CXL core's role is well understood, the documentation should reflect that information. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/162792538379.368511.9055351193841619781.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-08-06cxl: Move cxl_core to new directoryBen Widawsky6-7/+10
CXL core is growing, and it's already arguably unmanageable. To support future growth, move core functionality to a new directory and rename the file to represent just bus support. Future work will remove non-bus functionality. Note that mem.h is renamed to cxlmem.h to avoid a namespace collision with the global ARCH=um mem.h header. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/162792537866.368511.8915631504621088321.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-08-06soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routingEnric Balletbo i Serra1-0/+4
The UFOE (data compression engine) component needs to be enabled to have the imgtec gpu driver working. If we don't enable it we see a black screen. Looks like when we switched to use and array for setting the routing registers in commit 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") we missed to add this component in the new routing table, it was present before that commit, so fix it by adding this component in the mt8173 routing table. Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Eizan Miyamoto <eizan@chromium.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210625062448.3462177-1-enric.balletbo@collabora.com [mb: taking into account mask value] Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-08-06soc: mediatek: mmsys: add MT8365 supportFabien Parent2-0/+71
Add DSI mmsys connections for the MT8365 SoC. Signed-off-by: Fabien Parent <fparent@baylibre.com> Link: https://lore.kernel.org/r/20210519161847.3747352-3-fparent@baylibre.com [mb: take the mask field into account] Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-08-06dmaengine: idxd: make I/O interrupt handler one shotDave Jiang1-51/+8
The interrupt thread handler currently loops forever to process outstanding completions. This causes either an "irq X: nobody cared" kernel splat or the NMI watchdog kicks in due to running too long in the function. The irq thread handler is expected to run again after exiting if there are interrupts fired while the thread handler is running. So the handler code can process all the completed I/O in a single pass and exit without losing the follow on completed I/O. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/162802977005.3084234.11836261157026497585.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: idxd: clear block on fault flag when clear wqDave Jiang1-0/+1
The block on fault flag is not cleared when we disable or reset wq. This causes it to remain set if the user does not clear it on the next configuration load. Add clear of flag in dxd_wq_disable_cleanup() routine. Fixes: da32b28c95a7 ("dmaengine: idxd: cleanup workqueue config after disabling") Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/162803023553.3086015.8158952172068868803.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: idxd: add capability check for 'block on fault' attributeDave Jiang1-0/+3
The device general capability has a bit that indicate whether 'block on fault' is supported. Add check to wq sysfs knob to check if cap exists before allowing user to toggle. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/162802992615.3084999.12539468940404102898.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: xilinx: Add empty device_config functionMarek Vasut1-0/+12
Various DMA users call the dmaengine_slave_config() and expect it to succeed, but that can only succeed if .device_config is implemented. Add empty device_config function rather than patching all the places which use dmaengine_slave_config(). Signed-off-by: Marek Vasut <marex@denx.de> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Kedareswara rao Appana <appana.durga.rao@xilinx.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210804195140.61396-1-marex@denx.de Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: dw: Simplify DT property parserAndy Shevchenko1-28/+16
Since we converted internal data types to match DT, there is no need to have an intermediate conversion layer, hence drop a few conditionals and for loops for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20210802184355.49879-3-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: dw: Remove error message from DT parsing codeAndy Shevchenko1-5/+0
Users are a bit frightened of the harmless message that tells that DT is missed on ACPI-based platforms. Remove it for good, it will simplify the future conversion to fwnode and device property APIs. Fixes: a9ddb575d6d6 ("dmaengine: dw_dmac: Enhance device tree support") Depends-on: f5e84eae7956 ("dmaengine: dw: platform: Split OF helpers to separate module") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199379 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20210802184355.49879-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06dmaengine: idxd: Remove unused status variable in irq_process_work_list()Nathan Chancellor1-2/+0
status is no longer used within this block: drivers/dma/idxd/irq.c:255:6: warning: unused variable 'status' [-Wunused-variable] u8 status = desc->completion->status & DSA_COMP_STATUS_MASK; ^ 1 warning generated. Fixes: b60bb6e2bfc1 ("dmaengine: idxd: fix abort status check") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20210802175820.3153920-1-nathan@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06nvmem: core: fix error handling while validating keepout regionsSrinivas Kandagatla1-2/+5
Current error path on failure of validating keepout regions is calling put_device, eventhough the device is not even registered at that point. Fix this by adding proper error handling of freeing ida and nvmem. Fixes: fd3bb8f54a88 ("nvmem: core: Add support for keepout regions") Cc: <stable@vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210806085947.22682-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06nvmem: qfprom: sc7280: Handle the additional power-domains voteRajendra Nayak1-0/+25
On sc7280, to reliably blow fuses, we need an additional vote on max performance state of 'MX' power-domain. Add support for power-domain performance state voting in the driver. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210806085947.22682-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06nvmem: qfprom: Fix up qfprom_disable_fuse_blowing() orderingRajendra Nayak1-3/+3
qfprom_disable_fuse_blowing() disables a bunch of resources, and then does a few register writes in the 'conf' address space. It works perhaps because the resources are needed only for the 'raw' register space writes, and that the 'conf' space allows read/writes regardless. However that makes the code look confusing, so just move the register writes before turning off the resources in the function. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210806085947.22682-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06firmware: xilinx: Fix incorrect names in kernel-docMichal Simek1-3/+3
There are some c&p issues reported by kernel-doc as: drivers/firmware/xilinx/zynqmp.c:676: warning: expecting prototype for zynqmp_pm_write_ggs(). Prototype was for zynqmp_pm_read_ggs() instead drivers/firmware/xilinx/zynqmp.c:710: warning: expecting prototype for zynqmp_pm_write_pggs(). Prototype was for zynqmp_pm_read_pggs() instead drivers/firmware/xilinx/zynqmp.c:1023: warning: expecting prototype for zynqmp_pm_aes(). Prototype was for zynqmp_pm_aes_engine() instead Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/a81edd4fc6cff4bd7e4984fceda941b9e9ab01bf.1628245954.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-06phy: qcom-qmp: add USB3 PHY support for IPQ6018Baruch Siach1-0/+3
Initialization is identical to the IPQ8074 USB3 PHY. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/6eec7ef4ecd1e8360ebe8e425151121684e997ed.1628085910.git.baruch@tkos.co.il Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06Bluetooth: btusb: Fix fall-through warningsmark-yw.chen1-0/+1
Fix fall-through warnings: drivers/bluetooth/btusb.c: In function ‘btusb_recv_acl_mtk’: drivers/bluetooth/btusb.c:4033:3: warning: this statement may fall through [-Wimplicit-fallthrough=] 4033 | usb_disable_autosuspend(data->udev); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btusb.c:4034:2: note: here 4034 | case 0x05ff: /* Firmware debug logging 1 */ | ^~~~ Signed-off-by: mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-08-06phy: renesas: phy-rcar-gen3-usb2: Add USB2.0 PHY support for RZ/G2LBiju Das1-24/+73
This patch adds USB2.0 PHY support for RZ/G2L SoC. We need to use a different compatible string due to some differences with R-Car Gen3 USB2.0 PHY. It uses line ctrl register for OTG_ID pin changes and different OTG-BC interrupt bit for device recognition. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> # on R-Car Link: https://lore.kernel.org/r/20210727185527.19907-4-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06phy: qcom: qmp: Add SC8180x USB/DP comboBjorn Andersson1-0/+47
The two USB QMPs are USB/DP compbo PHYs, add the compatible for this combination to allow DP output. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210721225630.3035861-2-bjorn.andersson@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06platform/x86: pcengines-apuv2: Add missing terminating entries to gpio-lookup tablesHans de Goede1-0/+2
The gpiod_lookup_table.table passed to gpiod_add_lookup_table() must be terminated with an empty entry, add this. Note we have likely been getting away with this not being present because the GPIO lookup code first matches on the dev_id, causing most lookups to skip checking the table and the lookups which do check the table will find a matching entry before reaching the end. With that said, terminating these tables properly still is obviously the correct thing to do. Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210806115515.12184-1-hdegoede@redhat.com
2021-08-06platform/x86/intel: Move Intel PMT drivers to new subfolderDavid E. Box10-42/+57
Move all Intel Platform Monitoring Technology drivers to drivers/platform/x86/intel/pmt. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210727164928.3171521-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-06platform/x86: Make dual_accel_detect() KIOX010A + KIOX020A detect more robustHans de Goede1-1/+2
360 degree hinges devices with dual KIOX010A + KIOX020A accelerometers always have both a KIOX010A and a KIOX020A ACPI device (one for each accel). Theoretical some vendor may re-use some DSDT for a non-convertible stripping out just the KIOX020A ACPI device from the DSDT. Check that both ACPI devices are present to make the check more robust. Fixes: 153cca9caa81 ("platform/x86: Add and use a dual_accel_detect() helper") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210802141000.978035-1-hdegoede@redhat.com
2021-08-06phy: phy-twl4030-usb: Disable PHY for suspendTony Lindgren1-0/+15
Since commit 88d26136a256 ("PM: Prevent runtime suspend during system resume"), PM runtime will not let devices idle during system suspend. This is because of the pm_runtime_get_noresume() call done in device_prepare() that is not released until at device_complete() after resume. We must now disable the USB PHY in suspend if no USB cable is connected. Cc: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210727104512.52968-1-tony@atomide.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06phy: phy-mtk-tphy: add support mt8195Chunfeng Yun1-0/+54
The controller is designed to use use PLL integer mode, but in fact used fractional mode for some ones on mt8195, this causes signal degradation (e.g. eye diagram test fail), fix it by switching PLL to 26Mhz from default 48Mhz to improve signal quality. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1627028562-23584-3-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06phy: phy-mtk-tphy: support new hardware versionChunfeng Yun1-11/+29
The PHYA arch is updated, and doesn't support slew rate calibrate anymore on 7nm or advanced process, add a new version number to support it. Note: the FreqMeter bank is not used but reserved. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1627028562-23584-2-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06phy: qualcomm: phy-qcom-usb-hs: repair non-kernel-doc commentRandy Dunlap1-1/+1
Fix errant use of "/**" to begin a comment although the comment is not kernel-doc notation. Just use "/*" instead. Fixes this kernel-doc warning: drivers/phy/qualcomm/phy-qcom-usb-hs.c:3: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Copyright (C) 2016 Linaro Ltd Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: linux-phy@lists.infradead.org Link: https://lore.kernel.org/r/20210723022548.25695-1-rdunlap@infradead.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06hwrng: Add Arm SMCCC TRNG based driverAndre Przywara3-0/+138
The "Arm True Random Number Generator Firmware Interface"[1] provides an SMCCC based interface to a true hardware random number generator. So far we are using that in arch_get_random_seed(), but it might be useful to expose the entropy through the /dev/hwrng device as well. This allows to assess the quality of the implementation, by using "rngtest" from the rng-tools package, for example. Add a simple platform driver implementing the hw_random interface. The corresponding platform device is created by the SMCCC core code, we just match it here by name and provide a module alias. Since the firmware takes care about serialisation, this can happily coexist with the arch_get_random_seed() bits. [1] https://developer.arm.com/documentation/den0098/latest/ Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06firmware: smccc: Register smccc_trng platform deviceAndre Przywara1-0/+17
At the moment we probe for the Random Number Generator SMCCC service, and use that in the core code (arch_get_random). However the hardware entropy can also be useful to access from userland, and be it to assess its quality. Register a platform device when the SMCCC TRNG service is detected, to allow a hw_random driver to hook onto this. The function registering the device is deliberately made in a way which allows expansion, so other services that could be exposed via a platform device (or some other interface), can be added here easily. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: ccp - shutdown SEV firmware on kexecBrijesh Singh2-26/+35
The commit 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver") added support to allocate Trusted Memory Region (TMR) used during the SEV-ES firmware initialization. The TMR gets locked during the firmware initialization and unlocked during the shutdown. While the TMR is locked, access to it is disallowed. Currently, the CCP driver does not shutdown the firmware during the kexec reboot, leaving the TMR memory locked. Register a callback to shutdown the SEV firmware on the kexec boot. Fixes: 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver") Reported-by: Lucas Nussbaum <lucas.nussbaum@inria.fr> Tested-by: Lucas Nussbaum <lucas.nussbaum@inria.fr> Cc: <stable@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - drop pm_runtime_irqsafe() usageTony Lindgren1-1/+0
Commit b0a3d8986a76 ("crypto: omap-sham - Use pm_runtime_irq_safe()") added the use of pm_runtime_irq_safe() as pm_runtime_get_sync() was called from a tasklet. We now use the crypto engine queue instead of a custom queue since commit 33c3d434d91 ("crypto: omap-sham - convert to use crypto engine"). We want to drop the use of pm_runtime_irq_safe() in general as it takes a permanent usage count on the parent device causing issues for power management. Based on testing with CONFIG_DEBUG_ATOMIC_SLEEP=y, modprobe omap-sham, followed by modprobe tcrypt sec=1 mode=423, I have not been able to reproduce the scheduling while atomic issue seen earlier with current kernels and we can just drop the call to pm_runtime_irq_safe(). Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - drop suspend and resume functionsTony Lindgren1-21/+0
Let's get rid of the suspend and resume calls to runtime PM as these calls do not idle the hardware. The runtime suspend has been disabled for system suspend since commit 88d26136a256 ("PM: Prevent runtime suspend during system resume"). Instead of runtime PM, the system suspend and resume functions should call driver internal shared functions to idle the hardware as needed. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - drop old hw_init and unused FLAGS_INITTony Lindgren1-21/+5
FLAGS_INIT is now unused and we can just use standard runtime PM functions instead. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - add missing pm_runtime_dontuse_autosuspend()Tony Lindgren1-0/+2
We should pair the usage of pm_runtime_use_autosuspend() with pm_runtime_dont_use_autosuspend(). Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - initialize req only after omap_sham_hw_init()Tony Lindgren1-2/+2
Let's only initialize dd->req after omap_sham_hw_init() in case of errors. Looks like leaving dd->req initialized on omap_sham_hw_init() errors is is not causing issues though as we return on errors. So this patch can be applied as clean-up. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06crypto: omap-sham - clear dma flags only after omap_sham_update_dma_stop()Tony Lindgren1-1/+1
We should not clear FLAGS_DMA_ACTIVE before omap_sham_update_dma_stop() is done calling dma_unmap_sg(). We already clear FLAGS_DMA_ACTIVE at the end of omap_sham_update_dma_stop(). The early clearing of FLAGS_DMA_ACTIVE is not causing issues as we do not need to defer anything based on FLAGS_DMA_ACTIVE currently. So this can be applied as clean-up. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-08-06phy: rockchip-inno-usb2: fix for_each_child.cocci warningskernel test robot1-1/+3
For_each_available_child_of_node should have of_node_put() before break around line 1184. The other jumps out of the loop do contain the put. Generated by: scripts/coccinelle/iterators/for_each_child.cocci CC: Sumera Priyadarsini <sylphrenadin@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2106231617540.99238@hadrien Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-08-06net: mvvp2: fix short frame size on s390John Hubbard1-1/+1
On s390, the following build warning occurs: drivers/net/ethernet/marvell/mvpp2/mvpp2.h:844:2: warning: overflow in conversion from 'long unsigned int' to 'int' changes value from '18446744073709551584' to '-32' [-Woverflow] 844 | ((total_size) - MVPP2_SKB_HEADROOM - MVPP2_SKB_SHINFO_SIZE) This happens because MVPP2_SKB_SHINFO_SIZE, which is 320 bytes (which is already 64-byte aligned) on some architectures, actually gets ALIGN'd up to 512 bytes in the s390 case. So then, when this is invoked: MVPP2_RX_MAX_PKT_SIZE(MVPP2_BM_SHORT_FRAME_SIZE) ...that turns into: 704 - 224 - 512 == -32 ...which is not a good frame size to end up with! The warning above is a bit lucky: it notices a signed/unsigned bad behavior here, which leads to the real problem of a frame that is too short for its contents. Increase MVPP2_BM_SHORT_FRAME_SIZE by 32 (from 704 to 736), which is just exactly big enough. (The other values can't readily be changed without causing a lot of other problems.) Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Cc: Sven Auhagen <sven.auhagen@voleatech.de> Cc: Matteo Croce <mcroce@microsoft.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: dsa: mt7530: add the missing RxUnicast MIB counterDENG Qingfang1-0/+1
Add the missing RxUnicast counter. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: dsa: mt7530: drop untagged frames on VLAN-aware ports without PVIDDENG Qingfang2-2/+37
The driver currently still accepts untagged frames on VLAN-aware ports without PVID. Use PVC.ACC_FRM to drop untagged frames in that case. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06Merge tag 'sysfs_defferred_iomem_get_mapping-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core driver-core-nextGreg Kroah-Hartman1-3/+3
sysfs: Allow deferred execution of iomem_get_mapping() Tag for toerh trees/branches to pull from in order to have a stable base to build off of for the "Allow deferred execution of iomem_get_mapping()" set of sysfs changes Link: https://lore.kernel.org/r/20210729233235.1508920-1-kw@linux.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> * tag 'sysfs_defferred_iomem_get_mapping-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: sysfs: Rename struct bin_attribute member to f_mapping sysfs: Invoke iomem_get_mapping() from the sysfs open callback
2021-08-06drm/bridge: anx7625: Tune K value for IVO panelXin Ji2-4/+24
IVO panel require less input video clock variation than video clock variation in DP CTS spec. This patch decreases the K value of ANX7625 which will shrink eDP Tx video clock variation to meet IVO panel's requirement. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Xin Ji <xji@analogixsemi.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210806104407.2208538-1-xji@analogixsemi.com
2021-08-06net: dsa: don't disable multicast flooding to the CPU even without an IGMP querierVladimir Oltean4-31/+0
Commit 08cc83cc7fd8 ("net: dsa: add support for BRIDGE_MROUTER attribute") added an option for users to turn off multicast flooding towards the CPU if they turn off the IGMP querier on a bridge which already has enslaved ports (echo 0 > /sys/class/net/br0/bridge/multicast_router). And commit a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags") simply papered over that issue, because it moved the decision to flood the CPU with multicast (or not) from the DSA core down to individual drivers, instead of taking a more radical position then. The truth is that disabling multicast flooding to the CPU is simply something we are not prepared to do now, if at all. Some reasons: - ICMP6 neighbor solicitation messages are unregistered multicast packets as far as the bridge is concerned. So if we stop flooding multicast, the outside world cannot ping the bridge device's IPv6 link-local address. - There might be foreign interfaces bridged with our DSA switch ports (sending a packet towards the host does not necessarily equal termination, but maybe software forwarding). So if there is no one interested in that multicast traffic in the local network stack, that doesn't mean nobody is. - PTP over L4 (IPv4, IPv6) is multicast, but is unregistered as far as the bridge is concerned. This should reach the CPU port. - The switch driver might not do FDB partitioning. And since we don't even bother to do more fine-grained flood disabling (such as "disable flooding _from_port_N_ towards the CPU port" as opposed to "disable flooding _from_any_port_ towards the CPU port"), this breaks standalone ports, or even multiple bridges where one has an IGMP querier and one doesn't. Reverting the logic makes all of the above work. Fixes: a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags") Fixes: 08cc83cc7fd8 ("net: dsa: add support for BRIDGE_MROUTER attribute") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: dsa: mt7530: remove the .port_set_mrouter implementationVladimir Oltean1-13/+0
DSA's idea of optimizing out multicast flooding to the CPU port leaves quite a few holes open, so it should be reverted. The mt7530 driver is the only new driver which added a .port_set_mrouter implementation after the reorg from commit a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags"), so it needs to be reverted separately so that the other revert commit can go a bit further down the git history. Fixes: 5a30833b9a16 ("net: dsa: mt7530: support MDB and bridge flag operations") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: ethernet: ti: am65-cpsw: use napi_complete_done() in TX completionGrygorii Strashko1-5/+5
This patch enables support for hard irqs deferral feature from Eric Dumazet [1] for TI K3 CPSW driver by using napi_complete_done() in TX completion path. Depending on gro_flush_timeout and napi_defer_hard_irqs at gives up to 30% CPU utilization reduction: gro_flush_timeout=50000 napi_defer_hard_irqs=2 netperf -l 10 -H 192.168.1.1 -t UDP_STREAM -c -C -- -m 1470 MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 () port 0 AF_INET Socket Message Elapsed Messages CPU Service Size Size Time Okay Errors Throughput Util Demand bytes bytes secs # # 10^6bits/sec % SS us/KB before: 212992 1470 10.00 809632 0 952.0 42.98 14.792 212992 10.00 809630 952.0 50.66 8.719 after: 212992 1470 10.00 813686 0 956.8 32.14 11.009 212992 10.00 813686 956.8 50.05 8.570 [1] https://lore.kernel.org/netdev/20200422161329.56026-1-edumazet@google.com/ Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06net: ti: am65-cpsw-nuss: fix RX IRQ state after .ndo_stop()Vignesh Raghavendra2-2/+13
On TI K3 am64x platform the issue with RX IRQ is observed - it's become disabled forever after .ndo_stop(). The K3 CPSW driver manipulates RX IRQ by using standard Linux enable_irq()/disable_irq_nosync() API as there is no IRQ enable/disable options in CPSW HW itself, as result during .ndo_stop() following sequence happens phy_stop() teardown TX/RX channels wait for TX tdown complete napi_disable(TX) clean up TX channels (a) napi_disable(RX) At point (a) it's not possible to predict if RX IRQ was triggered or not. if RX IRQ was triggered then it also not possible to definitely say if RX NAPI was run or only scheduled and immediately canceled by napi_disable(RX). Actually the last case causes RX IRQ to be permanently disabled. Another observed issue is that RX IRQ enable counter become unbalanced if (gro_flush_timeout =! 0) while (napi_defer_hard_irqs == 0): Unbalanced enable for IRQ 44 WARNING: CPU: 0 PID: 10 at ../kernel/irq/manage.c:776 __enable_irq+0x38/0x80 __enable_irq+0x38/0x80 enable_irq+0x54/0xb0 am65_cpsw_nuss_rx_poll+0x2f4/0x368 __napi_poll+0x34/0x1b8 net_rx_action+0xe4/0x220 _stext+0x11c/0x284 run_ksoftirqd+0x4c/0x60 To avoid above issues introduce flag indicating if RX was actually disabled before enabling it in am65_cpsw_nuss_rx_poll() and restore RX IRQ state in .ndo_open() Fixes: 4f7cce272403 ("net: ethernet: ti: am65-cpsw: add support for am64x cpsw3g") Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06ptp: ocp: Remove pending_image indicator from devlinkJonathan Lemon1-10/+0
After writing an image blob to the flash memory, a reboot is required to reload the FPGA. There is no versioning prsent in the FPGA image file, so only a running version is available. The 'stored version' was set to 'pending' in order to indicate a reboot was needed. This isn't reliable, as the module could be unloaded/loaded, losing the "reboot needed" indicator. Also, the devlink 'stored version' information is designed to refer to the actual image version. Unfortunately, there is no method to determine the flash image version other than booting it, so remove the devlink stored version setting. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06ptp: ocp: Rename version string shown by devlink.Jonathan Lemon1-2/+2
The TimeCard has two FPGA images in the flash: the actual firmware, and a manufacturing fallback version which is intended to act as a loader in case the flash update failed. Name these "fw" and "loader", which are reflected in devlink: [root@timecard drv]# devlink dev info pci/0000:04:00.0: driver ptp_ocp serial_number fc:c2:3d:2e:d7:c0 versions: running: fw 5 Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06ptp: ocp: Use 'gnss' naming instead of 'gps'Jonathan Lemon1-21/+21
GPS is not the only available positioning system. Use the generic naming of "GNSS" instead. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-06ptp: ocp: Remove devlink health and unused parameters.Jonathan Lemon1-80/+0
"devlink health" was used as a way to monitor the GNSS signal status. This isn't really the intended use, and the same functionality can be achived by monitoring the status file. Remove the devlink heath support entirely, and also remove the currently unused devlink parameters. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.