aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-06-01drm/amd/display: 3.2.187Aric Cyr1-1/+1
This version brings along the following fixes: * Changes to DP LT fallback behavior to more closely match the DP standard * Added new interfaces for lut pipeline * Restore ref_dtblck value when clk struct is cleared in init_clocks * Fixes DMUB outbox trace in S4 * Fixes lingering DIO FIFO errors when DIO no longer enabled * Reads Golden Settings Table from VBIOS Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Fix possible infinite loop in DP LT fallbackIlya1-57/+49
[Why] It's possible for some fallback scenarios to result in infinite looping during link training. [How] This change modifies DP LT fallback behavior to more closely match the DP standard. Keep track of the link rate during the EQ_FAIL fallback, and use it as the maximum link rate for the CR sequence. Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Ilya <Ilya.Bakoulin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Don't clear ref_dtbclk valueAlvin3-3/+5
[Description] ref_dtbclk value is assigned in clk_mgr_construct, but the clks struct is cleared in init_clocks. Make sure to restore the value or we will get 0 value for ref_dtbclk in DCN31. Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Fix DMUB outbox trace in S4 (#4465)Hung, Cruise2-32/+31
[Why] DMUB Outbox0 read/write pointer not sync after resumed from S4. And that caused old traces were sent to outbox. [How] Disable DMUB Outbox0 interrupt and clear DMUB Outbox0 read/write pointer when resumes from S4. And then enable Outbox0 interrupt before starts DMCUB. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Cruise Hung <Cruise.Hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Wait DMCUB to idle state before reset.hengzhou3-3/+11
[WHY] Very low rate to cause memory access issue while resetting DMCUB after the halt command was sent to it. The process of stopping fw of DMCUB may be timeout, that means it is not in idle state, such as the window frames may still be kept in cache, so reset by force will cause MMHUB hang. [HOW] After the halt command was sent, keep checking the DMCUB state until it is idle. Reviewed-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: hengzhou <Hengyong.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Pass the new context into disable OTG WANicholas Kazlauskas4-13/+13
[Why] When enabling an HPO stream for the first time after having previously enabled a DIO stream there may be lingering DIO FIFO errors even though the DIO is no longer enabled. These can cause display clock change to hang if we don't apply the OTG disable workaround since the ramping logic is tied to OTG on. [How] The workaround wasn't being applied in the sequence of: 1 DIO stream 0 streams 1 HPO stream because current_state has no stream or planes in its context - and it's only swapped after optimize has finished. We should be using the incoming context instead to determine whether this logic is needed or not. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: revert Blank eDP on disable/enable drvLeung, Martin9-19/+44
why and how: Revert this change. It was causing a black screen with certain blocks Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Leung, Martin <Martin.Leung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01drm/amd/display: Read Golden Settings Table from VBIOSSherry Wang1-3/+1
[Why] Dmub read AUX_DPHY_RX_CONTROL0 from Golden Setting Table, but driver will set it to default value 0x103d1110, which causes issue in some case [How] Remove the driver code, use the value set by dmub in dp_aux_init Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Sherry Wang <YAO.WANG1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-01Merge tag 'pwm/for-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwmLinus Torvalds20-285/+1179
Pull pwm updates from Thierry Reding: "Quite a large number of conversions this time around, courtesy of Uwe who has been working tirelessly on these. No drivers of the legacy API are left at this point, so as a next step the old API can be removed. Support is added for a few new devices such as the Xilinx AXI timer- based PWMs and the PWM IP found on Sunplus SoCs. Other than that, there's a number of fixes, cleanups and optimizations" * tag 'pwm/for-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (43 commits) pwm: pwm-cros-ec: Add channel type support dt-bindings: google,cros-ec-pwm: Add the new -type compatible dt-bindings: Add mfd/cros_ec definitions pwm: Document that the pinstate of a disabled PWM isn't reliable pwm: twl-led: Implement .apply() callback pwm: lpc18xx: Implement .apply() callback pwm: mediatek: Implement .apply() callback pwm: lpc32xx: Implement .apply() callback pwm: tegra: Implement .apply() callback pwm: stmpe: Implement .apply() callback pwm: sti: Implement .apply() callback pwm: pwm-mediatek: Add support for MediaTek Helio X10 MT6795 dt-bindings: pwm: pwm-mediatek: Add documentation for MT6795 SoC pwm: tegra: Optimize period calculation pwm: renesas-tpu: Improve precision of period and duty_cycle calculation pwm: renesas-tpu: Improve maths to compute register settings pwm: renesas-tpu: Rename variables to match the usual naming pwm: renesas-tpu: Implement .apply() callback pwm: renesas-tpu: Make use of devm functions pwm: renesas-tpu: Make use of dev_err_probe() ...
2022-06-01Merge tag 'rpmsg-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linuxLinus Torvalds2-7/+6
Pull rpmsg updates from Bjorn Andersson: "This corrects the check for irq_of_parse_and_map() failures in the Qualcomm SMD driver and fixes unregistration and a couple of double free in the virtio rpmsg driver" * tag 'rpmsg-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: rpmsg: qcom_smd: Fix returning 0 if irq_of_parse_and_map() fails rpmsg: virtio: Fix the unregistration of the device rpmsg_ctrl rpmsg: virtio: Fix possible double free in rpmsg_virtio_add_ctrl_dev() rpmsg: virtio: Fix possible double free in rpmsg_probe() rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value
2022-06-01Merge tag 'rproc-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linuxLinus Torvalds10-156/+153
Pull remoteproc updates from Bjorn Andersson: "This fixes a race condition in the user space interface for starting and stopping remote processors, it makes the ELF loader properly skip zero memsz segments and it cleans up the debugfs tracefile code a bit by not checking for errors. It introduces support for controlling the audio DSP on Qualcomm MSM8226, as well as audio and compute DSPs on Qualcomm SC8280XP. It makes it possible to specify the firmware path for Mediatek's remote processors, fixes a double free in the SCP driver and addresses an issue with the SRAM initialization on MT8195. Lastly it deprecates the custom ELF loader in the iMX remoteproc driver, in favor of using the shared one" * tag 'rproc-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (21 commits) dt-bindings: remoteproc: mediatek: Add optional memory-region to mtk,scp dt-bindings: remoteproc: mediatek: Make l1tcm reg exclusive to mt819x dt-bindings: remoteproc: st,stm32-rproc: Fix phandle-array parameters description remoteproc: imx_rproc: Support i.MX93 dt-bindings: remoteproc: imx_rproc: Support i.MX93 remoteproc: qcom: pas: Add MSM8226 ADSP support dt-bindings: remoteproc: qcom: pas: Add MSM8226 adsp remoteproc: mediatek: Allow reading firmware-name from DT dt-bindings: remoteproc: mediatek: Add firmware-name property remoteproc: qcom: pas: Add sc8280xp remoteprocs dt-bindings: remoteproc: qcom: pas: Add sc8280xp adsp and nsp pair dt-bindings: remoteproc: mediatek: Add interrupts property to mtk,scp remoteproc: imx_rproc: Ignore create mem entry for resource table remoteproc: core: Move state checking to remoteproc_core remoteproc: core: Remove state checking before calling rproc_boot() remoteproc: imx_dsp_rproc: Make rsc_table optional remoteproc: imx_dsp_rproc: use common rproc_elf_load_segments remoteproc: elf_loader: skip segment with memsz as zero remoteproc: mtk_scp: Fix a potential double free remoteproc: Don't bother checking the return value of debugfs_create* ...
2022-06-01Merge tag 'spi-fix-v5.19-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spiLinus Torvalds2-7/+8
Pull spi fixes from Mark Brown: "A couple of fixes that came in during the merge window: a driver fix for spurious timeouts in the fsi driver and an improvement to make the core display error messages for transfer_one_message() to help people debug things" * tag 'spi-fix-v5.19-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: core: Display return code when failing to transfer message spi: fsi: Fix spurious timeout
2022-06-01Merge branch 'pcmcia-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linuxLinus Torvalds3-6/+7
Pull pcmcia updates from Dominik Brodowski: "A few odd cleanups and fixes, including a Kconfig fix to add a required dependency on MIPS" * 'pcmcia-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux: pcmcia: Use platform_get_irq() to get the interrupt pcmcia: db1xxx_ss: restrict to MIPS_DB1XXX boards drivers/pcmcia: Fix typo in comment
2022-06-01gpio: pca953x: use the correct register address to do regcache syncHaibo Chen1-8/+11
For regcache_sync_region, need to use pca953x_recalc_addr() to get the real register address. Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-06-01drm/i915: Treat DMRRS as static DRRSVille Syrjälä1-4/+20
Some machines declare DRRS type = seamless, DRRS = no, DMRRS = yes. I *think* DMRRS stands for "dynamcic media refresh rate", and I suspect the way it's meant to work is that it lets the driver switch refresh rates to match the frame rate for media playback. Obviously for us all that kind of policy stuff is entirely up to userspace, so the only thing we may do is make the extra refresh rate(s) available. So let's treat this case as just static DRRS for now. In the future We might want to differentiate the "seamless w/ downclocking" vs. "seamless w/o downclocking" cases so that we could do seamless refresh rate changes for systems that only claim to support DMRRS. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-7-ville.syrjala@linux.intel.com
2022-06-01drm/i915/bios: Define more BDB contentsVille Syrjälä1-7/+43
Add a bunch of new struff we're missing in various BDB blocks. TODO: Bunch of these might actually need to be taken into use... v2: s/lfp_features/lfp_power/features/ (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-6-ville.syrjala@linux.intel.com
2022-06-01drm/i915/bios: Fix aggressiveness typosVille Syrjälä1-4/+4
Fix various typos around "aggressiveness". Note that the VBT spec also sometimes missspells it as "agressiveness" so I guess that's where some of the typos came from. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-5-ville.syrjala@linux.intel.com
2022-06-01drm/i915: Accept more fixed modes with VRR panelsVille Syrjälä5-16/+44
It seem that when dealing with VRR capable eDP panels we need to accept fixed modes with variable vblank length (which is what VRR varies dynamically). Typically the preferred mode seems to be a non-VRR more (lowish dotclock/refresh rate + short vblank). We also have examples where it looks like even the hblank length is a bit different between the preferred mode vs. VRR mode(s). So let's just accept anything that has matching hdisp+vdisp+flags. v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-4-ville.syrjala@linux.intel.com
2022-06-01drm/i915: Print out rejected fixed modesVille Syrjälä1-0/+4
To help with debugging DRRS/VRR panel init let's dump out all the fixed modes we rejected for whatever reason. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-3-ville.syrjala@linux.intel.com
2022-06-01drm/i915: Parse VRR capability from VBTVille Syrjälä3-6/+23
VBT seems to have an extra flag for VRR vs. not. Let's consult that for eDP panels. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-2-ville.syrjala@linux.intel.com
2022-06-01mmc: block: Fix CQE recovery reset successAdrian Hunter1-2/+1
The intention of the use of mmc_blk_reset_success() in mmc_blk_cqe_recovery() was to prevent repeated resets when retrying and getting the same error. However, that may not be the case - any amount of time and I/O may pass before another recovery is needed, in which case there would be no reason to deny it the opportunity to recover via a reset if necessary. CQE recovery is expected seldom and failure to recover (if the clear tasks command fails), even more seldom, so it is better to allow the reset always, which can be done by calling mmc_blk_reset_success() always. Fixes: 1e8e55b67030c6 ("mmc: block: Add CQE support") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20220531171922.76080-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-06-01efi: clean up Kconfig dependencies on CONFIG_EFIArd Biesheuvel2-30/+25
Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-01efi/x86: libstub: Make DXE calls mixed mode safeArd Biesheuvel1-2/+2
The newly added DXE calls use 64-bit quantities, which means we need to marshall them explicitly when running in mixed mode. Currently, we get away without it because we just bail when GetMemorySpaceDescriptor() fails, which is guaranteed to happen due to the function argument mixup. Let's fix this properly, though, by defining the macros that describe how to marshall the arguments. While at it, drop an incorrect cast on a status variable. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-01macsec: fix UAF bug for real_devZiyang Xuan1-0/+7
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following: ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. Fixes: 2bce1ebed17d ("macsec: fix refcnt leak in module exit routine") Reported-by: syzbot+d0e94b65ac259c29ce7a@syzkaller.appspotmail.com Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/r/20220531074500.1272846-1-william.xuanziyang@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-06-01gpu: host1x: Add context busMikko Perttunen4-2/+38
The context bus is a "dummy" bus that contains struct devices that correspond to IOMMU contexts assigned through Host1x to processes. Even when host1x itself is built as a module, the bus is registered in built-in code so that the built-in ARM SMMU driver is able to reference it. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-06-01octeontx2-af: fix error code in is_valid_offset()Dan Carpenter1-1/+1
The is_valid_offset() function returns success/true if the call to validate_and_get_cpt_blkaddr() fails. Fixes: ecad2ce8c48f ("octeontx2-af: cn10k: Add mailbox to configure reassembly timeout") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YpXDrTPb8qV01JSP@kili Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-06-01drm/i915/display: stop using BUG()Jani Nikula3-19/+26
Avoid bringing the entire machine down even if there's a bug that shouldn't happen, but won't corrupt the system either. Log them loudly and limp on. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531162527.1062319-1-jani.nikula@intel.com
2022-06-01bonding: guard ns_targets by CONFIG_IPV6Hangbin Liu2-4/+8
Guard ns_targets in struct bond_params by CONFIG_IPV6, which could save 256 bytes if IPv6 not configed. Also add this protection for function bond_is_ip6_target_ok() and bond_get_targets_ip6(). Remove the IS_ENABLED() check for bond_opts[] as this will make BOND_OPT_NS_TARGETS uninitialized if CONFIG_IPV6 not enabled. Add a dummy bond_option_ns_ip6_targets_set() for this situation. Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Acked-by: Jonathan Toppins <jtoppins@redhat.com> Link: https://lore.kernel.org/r/20220531063727.224043-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-06-01vdpa: ifcvf: set pci driver data in probeJason Wang1-1/+2
We should set the pci driver data in probe instead of the vdpa device adding callback. Otherwise if no vDPA device is created we will lose the pointer to the management device. Fixes: 6b5df347c6482 ("vDPA/ifcvf: implement management netlink framework for ifcvf") Tested-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220524055557.1938-1-jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-01vdpa/mlx5: Add RX MAC VLAN filter supportEli Cohen1-58/+216
Support HW offloaded filtering of MAC/VLAN packets. To allow that, we add a handler to handle VLAN configurations coming through the control VQ. Two operations are supported. 1. Adding VLAN - in this case, an entry will be added to the RX flow table that will allow the combination of the MAC/VLAN to be forwarded to the TIR. 2. Removing VLAN - will remove the entry from the flow table, effectively blocking such packets from going through. Currently the control VQ does not propagate changes to the MAC of the VLAN device so we always use the MAC of the parent device. Examples: 1. Create vlan device: $ ip link add link ens1 name ens1.8 type vlan id 8 Signed-off-by: Eli Cohen <elic@nvidia.com> Message-Id: <20220411122942.225717-4-elic@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2022-06-01vdpa/mlx5: Remove flow counter from steeringEli Cohen1-18/+6
The flow counter has been introduced in early versions of the driver to aid in debugging. It is no longer needed and can harm performance. Remove it. Signed-off-by: Eli Cohen <elic@nvidia.com> Message-Id: <20220411122942.225717-2-elic@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-01xen: replace xen_remap() with memremap()Juergen Gross3-8/+8
xen_remap() is used to establish mappings for frames not under direct control of the kernel: for Xenstore and console ring pages, and for grant pages of non-PV guests. Today xen_remap() is defined to use ioremap() on x86 (doing uncached mappings), and ioremap_cache() on Arm (doing cached mappings). Uncached mappings for those use cases are bad for performance, so they should be avoided if possible. As all use cases of xen_remap() don't require uncached mappings (the mapped area is always physical RAM), a mapping using the standard WB cache mode is fine. As sparse is flagging some of the xen_remap() use cases to be not appropriate for iomem(), as the result is not annotated with the __iomem modifier, eliminate xen_remap() completely and replace all use cases with memremap() specifying the MEMREMAP_WB caching mode. xen_unmap() can be replaced with memunmap(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2022-05-31Input: mtk-pmic-keys - move long press debounce mask to mtk_pmic_regsAngeloGioacchino Del Regno1-6/+9
As the second and last step of preparation to add support for more PMICs in this driver, move the long press debounce mask to struct mtk_pmic_regs and use that in mtk_pmic_keys_lp_reset_setup() instead of directly using the definition. While at it, remove the definition for MTK_PMIC_RST_DU_SHIFT as we are able to calculate it dynamically and spares us some unnecessary new definitions around for future per-PMIC variations of RST_DU_MASK. Lastly, it was necessary to change the function signature of mtk_pmic_keys_lp_reset_setup() to now pass a pointer to the main mtk_pmic_regs structure, since that's where the reset debounce mask now resides. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20220524093505.85438-3-angelogioacchino.delregno@collabora.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: mtk-pmic-keys - transfer per-key bit in mtk_pmic_keys_regsAngeloGioacchino Del Regno1-11/+19
Place the key bit in struct mtk_pmic_keys_regs to enhance this driver's flexibility, in preparation for adding support for more PMICs. While at it, remove the definition of MTK_PMIC_RST_KEY_MASK as we are now dynamically setting the keymask relatively to the keys that are defined in the newly added rst_en_mask variable, on a per-key basis. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20220524093505.85438-2-angelogioacchino.delregno@collabora.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: mtk-pmic-keys - use single update when configuring long press behaviorDmitry Torokhov1-43/+28
Instead of doing 3 read-modify-write operations when configuring behavior of long-press, consolidate everything into one. Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on mt8183-pumpkin Link: https://lore.kernel.org/r/YowH0Q5HAGU7Grx2@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: mtk-pmic-keys - allow compiling with COMPILE_TESTDmitry Torokhov1-1/+1
There are no hard architecture dependencies in the driver, so to improve compile test coverage let's enable the driver when COMPILE_TEST is selected. Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/YowG7BVsJTNd0ELi@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31drm/i915/pvc: Add initial PVC workaroundsStuart Summers4-12/+73
Bspec: 64027 Signed-off-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220527163348.1936146-3-matthew.d.roper@intel.com
2022-05-31drm/i915/pvc: Extract stepping information from PCI revidMatt Roper3-2/+85
For PVC, the base die and compute tile have separate stepping values that we need to track; we'll use the existing graphics_step field to represent the compute tile stepping and add a new 'basedie_step' field. Unlike past platforms, steppings for these components are represented by specific bitfields within the PCI revision ID, and we shouldn't make assumptions about the non-CT, non-BD bits staying 0. Let's update our stepping code accordingly. Bspec: 44484 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220527163348.1936146-2-matthew.d.roper@intel.com
2022-05-31Merge tag 'leds-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-ledsLinus Torvalds11-42/+1719
Pull LED updates from Pavel Machek: "Most significant here is the driver for Qualcomm LPG. Apparently it drives backlight on some boards, so it is quite important for some people" * tag 'leds-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: qcom-lpg: Require pattern to follow documentation leds: lp50xx: Remove duplicated error reporting in .remove() leds: qcom-lpg: add missing PWM dependency leds: ktd2692: Make aux-gpios optional dt-bindings: leds: convert ktd2692 bindings to yaml leds: ktd2692: Avoid duplicate error messages on probe deferral leds: is31fl32xx: Improve error reporting in .remove() leds: Move pwm-multicolor driver into rgb directory leds: Add PWM multicolor driver dt-bindings: leds: Add multicolor PWM LED bindings dt-bindings: leds: Optional multi-led unit address leds: regulator: Make probeable from device tree leds: regulator: Add dev helper variable dt-bindings: leds: Add regulator-led binding leds: pca9532: Make pca9532_destroy_devices() return void leds: Add pm8350c support to Qualcomm LPG driver dt-bindings: leds: Add pm8350c pmic support leds: Add driver for Qualcomm LPG dt-bindings: leds: Add Qualcomm Light Pulse Generator binding
2022-05-31Merge tag 'i2c-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds13-231/+370
Pull i2c updates from Wolfram Sang: "Only driver updates for 5.19. Bigger changes are for Meson, NPCM, and R-Car, but there are also changes all over the place" * tag 'i2c-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (34 commits) i2c: meson: fix typo in comment i2c: rcar: use flags instead of atomic_xfer i2c: rcar: REP_AFTER_RD is not a persistent flag i2c: rcar: use BIT macro consistently i2c: qcom-geni: remove unnecessary conditions i2c: mt7621: Use devm_platform_get_and_ioremap_resource() i2c: rcar: refactor handling of first message i2c: rcar: avoid race condition with SMIs i2c: xiic: Correct the datatype for rx_watermark i2c: rcar: fix PM ref counts in probe error paths i2c: npcm: Handle spurious interrupts i2c: npcm: Correct register access width i2c: npcm: Add tx complete counter i2c: npcm: Fix timeout calculation i2c: npcm: Remove unused variable clk_regmap i2c: npcm: Change the way of getting GCR regmap i2c: xiic: Fix Tx Interrupt path for grouped messages i2c: xiic: Fix coding style issues i2c: xiic: return value of xiic_reinit i2c: cadence: Increase timeout per message if necessary ...
2022-05-31Input: raspberrypi-ts - add missing HAS_IOMEM dependencyRandy Dunlap1-0/+1
Since JOYSTICK_SENSEHAT selects MFD_SIMPLE_MFD_I2C and the latter depends on HAS_IOMEM, and since 'select' does not follow any dependency chains, JOYSTICK_SENSEHAT should also depend on HAS_IOMEM to prevent a kconfig warning and a build error: WARNING: unmet direct dependencies detected for MFD_SIMPLE_MFD_I2C Depends on [n]: HAS_IOMEM [=n] && I2C [=y] Selected by [y]: - JOYSTICK_SENSEHAT [=y] && INPUT_JOYSTICK [=y] && INPUT [=y] && I2C [=y] s390-linux-ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe': simple-mfd-i2c.c:(.text+0xc8): undefined reference to `devm_mfd_add_devices' Fixes: 41657514c796 ("Input: add Raspberry Pi Sense HAT joystick driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220531022942.16340-1-rdunlap@infradead.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: adp5588-keys - do not explicitly set device as wakeup sourceDmitry Torokhov1-8/+0
I2C core will set up device as a wakeup source and will configure interrupt as a wakeup interrupt if client is created with I2C_CLIENT_WAKE flag. Let's rely on this facility and to not unconditionally set up the device as wakeup device in the driver. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20220528045631.289821-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: adp5588-keys - switch to using managed resourcesDmitry Torokhov1-67/+45
This simplifies error handling in probe() and reduces amount of explicit code in remove(). Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20220528045631.289821-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: adp5588-keys - switch to using threaded interruptDmitry Torokhov1-36/+45
Instead of using hard interrupt handler and manually scheduling work item to handle I2C communications, let's switch to threaded interrupt handling. While at that enforce the readout delay required on pre- revision 4 silicon. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20220528045631.289821-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31Input: adp5588-keys - drop CONFIG_PM guardsDmitry Torokhov1-10/+3
To improve compile-time coverage let's drop #ifdef CONFIG_PM guards and use SIMPLE_DEV_PM_OPS and __maybe_unused attributes and rely on the linker to drop unused code. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20220528045631.289821-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-05-31net/mlx5: Fix mlx5_get_next_dev() peer device matchingSaeed Mahameed1-11/+23
In some use-cases, mlx5 instances will need to search for their peer device (the other port on the same HCA). For that, mlx5 device matching mechanism relied on auxiliary_find_device() to search, and used a bad matching callback function. This approach has two issues: 1) next_phys_dev() the matching function, assumed all devices are of the type mlx5_adev (mlx5 auxiliary device) which is wrong and could lead to crashes, this worked for a while, since only lately other drivers started registering auxiliary devices. 2) using the auxiliary class bus (auxiliary_find_device) to search for mlx5_core_dev devices, who are actually PCIe device instances, is wrong. This works since mlx5_core always has at least one mlx5_adev instance hanging around in the aux bus. As suggested by others we can fix 1. by comparing device names prefixes if they have the string "mlx5_core" in them, which is not a best practice ! but even with that fixed, still 2. needs fixing, we are trying to match pcie device peers so we should look in the right bus (pci bus), hence this fix. The fix: 1) search the pci bus for mlx5 peer devices, instead of the aux bus 2) to validated devices are the same type "mlx5_core_dev" compare if they have the same driver, which is bulletproof. This wouldn't have worked with the aux bus since the various mlx5 aux device types don't share the same driver, even if they share the same device wrapper struct (mlx5_adev) "which helped to find the parent device" Fixes: a925b5e309c9 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus") Reported-by: Alexander Lobakin <alexandr.lobakin@intel.com> Reported-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
2022-05-31net/mlx5e: Update netdev features after changing XDP stateMaxim Mikityanskiy1-0/+5
Some features (LRO, HW GRO) conflict with XDP. If there is an attempt to enable such features while XDP is active, they will be set to `off [requested on]`. In order to activate these features after XDP is turned off, the driver needs to call netdev_update_features(). This commit adds this missing call after XDP state changes. Fixes: cf6e34c8c22f ("net/mlx5e: Properly block LRO when XDP is enabled") Fixes: b0617e7b3500 ("net/mlx5e: Properly block HW GRO when XDP is enabled") Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-05-31net/mlx5e: Disable softirq in mlx5e_activate_rq to avoid race conditionMaxim Mikityanskiy7-11/+31
When the driver activates the channels, it assumes NAPI isn't running yet. mlx5e_activate_rq posts a NOP WQE to ICOSQ to trigger a hardware interrupt and start NAPI, which will run mlx5e_alloc_rx_mpwqe and post UMR WQEs to ICOSQ to be able to receive packets with striding RQ. Unfortunately, a race condition is possible if NAPI is triggered by something else (for example, TX) at a bad timing, before mlx5e_activate_rq finishes. In this case, mlx5e_alloc_rx_mpwqe may post UMR WQEs to ICOSQ, and with the bad timing, the wqe_info of the first UMR may be overwritten by the wqe_info of the NOP posted by mlx5e_activate_rq. The consequence is that icosq->db.wqe_info[0].num_wqebbs will be changed from MLX5E_UMR_WQEBBS to 1, disrupting the integrity of the array-based linked list in wqe_info[]. mlx5e_poll_ico_cq will hang in an infinite loop after processing wqe_info[0], because after the corruption, the next item to be processed will be wqe_info[1], which is filled with zeros, and `sqcc += wi->num_wqebbs` will never move further. This commit fixes this race condition by using async_icosq to post the NOP and trigger the interrupt. async_icosq is always protected with a spinlock, eliminating the race condition. Fixes: bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE") Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reported-by: Karsten Nielsen <karsten@foo-bar.dk> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-05-31net/mlx5: CT: Fix header-rewrite re-use for tupelsPaul Blakey1-8/+11
Tuple entries that don't have nat configured for them which are added to the ct nat table will always create a new modify header, as we don't check for possible re-use on them. The same for tuples that have nat configured for them but are added to ct table. Fix the above by only avoiding wasteful re-use lookup for actually natted entries in ct nat table. Fixes: 7fac5c2eced3 ("net/mlx5: CT: Avoid reusing modify header context for natted entries") Signed-off-by: Paul Blakey <paulb@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-05-31net/mlx5e: TC NIC mode, fix tc chains miss tableMaor Dickman3-3/+39
The cited commit changed promisc table to be created on demand with the highest priority in the NIC table replacing the vlan table, this caused tc NIC tables miss flow to skip the prmoisc table because it use vlan table as miss table. OVS offload in NIC mode use promisc by default so any unicast packet which will be handled by tc NIC tables miss flow will skip the promisc rule and will be dropped. Fix this by adding new empty table in new tc level with low priority and point the nic tc chain miss to it, the new table is managed so it will point to vlan table if promisc is disabled and to promisc table if enabled. Fixes: 1c46d7409f30 ("net/mlx5e: Optimize promiscuous mode") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>