- 26 8月, 2021 3 次提交
-
-
由 Mathias Nyman 提交于
Only TDs with status TD_CLEARING_CACHE will be given back after cache is cleared with a set TR deq command. xhci_invalidate_cached_td() failed to set the TD_CLEARING_CACHE status for some cancelled TDs as it assumed an endpoint only needs to clear the TD it stopped on. This isn't always true. For example with streams enabled an endpoint may have several stream rings, each stopping on a different TDs. Note that if an endpoint has several stream rings, the current code will still only clear the cache of the stream pointed to by the last cancelled TD in the cancel list. This patch only focus on making sure all canceled TDs are given back, avoiding hung task after device removal. Another fix to solve clearing the caches of all stream rings with cancelled TDs is needed, but not as urgent. This issue was simultanously discovered and debugged by by Tao Wang, with a slightly different fix proposal. Fixes: 674f8438 ("xhci: split handling halted endpoints into two steps") Cc: <stable@vger.kernel.org> #5.12 Reported-by: NTao Wang <wat@codeaurora.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Removes static char buffer usage in the following decode functions: xhci_decode_ctrl_ctx() xhci_decode_slot_context() xhci_decode_usbsts() xhci_decode_doorbell() xhci_decode_ep_context() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor changes are needed in other xhci code as these functions are also used elsewhere Cc: <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Removes static char buffer usage in the following decode functions: xhci_decode_trb() xhci_decode_ptortsc() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor chanes are needed in xhci debugfs code as these functions are also used there. Changes include moving XHCI_MSG_MAX definititon from xhci-trace.h to xhci.h Cc: <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 8月, 2021 1 次提交
-
-
由 Maxim Devaev 提交于
f_hid provides the OUT Endpoint as only way for receiving reports from the host. SETUP/SET_REPORT method is not supported, and this causes a number of compatibility problems with various host drivers, especially in the case of keyboard emulation using f_hid. - Some hosts do not support the OUT Endpoint and ignore it, so it becomes impossible for the gadget to receive a report from the host. In the case of a keyboard, the gadget loses the ability to receive the status of the LEDs. - Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint at all. This may be due to their bugs or incomplete implementation of the HID standard. For example, absolutely all Apple UEFIs can't handle the OUT Endpoint if it goes after IN Endpoint in the descriptor and require the reverse order (OUT, IN) which is a violation of the standard. Other hosts either do not initialize gadgets with a descriptor containing the OUT Endpoint completely (like some HP and DELL BIOSes and embedded firmwares like on KVM switches), or initialize them, but will not poll the IN Endpoint. This patch adds configfs option no_out_endpoint=1 to disable the OUT Endpoint and allows f_hid to receive reports from the host via SETUP/SET_REPORT. Previously, there was such a feature in f_hid, but it was replaced by the OUT Endpoint [1] in the commit 99c51500 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT"). So this patch actually returns the removed functionality while making it optional. For backward compatibility reasons, the OUT Endpoint mode remains the default behaviour. - The OUT Endpoint mode provides the report queue and reduces USB overhead (eliminating SETUP routine) on transmitting a report from the host. - If the SETUP/SET_REPORT mode is used, there is no report queue, so the userspace will only read last report. For classic HID devices like keyboards this is not a problem, since it's intended to transmit the status of the LEDs and only the last report is important. This mode provides better compatibility with strange and buggy host drivers. Both modes passed USBCV tests. Checking with the USB protocol analyzer also confirmed that everything is working as it should and the new mode ensures operability in all of the described cases. Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1] Reviewed-by: NMaciej Żenczykowski <zenczykowski@gmail.com> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NMaxim Devaev <mdevaev@gmail.com> Link: https://lore.kernel.org/r/20210821134004.363217-1-mdevaev@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 8月, 2021 3 次提交
-
-
由 Vladimir Oltean 提交于
Currently dpaa2_switch_takedown has a funny name and does not do the opposite of dpaa2_switch_init, which makes probing fail when we need to handle an -EPROBE_DEFER. A sketch of what dpaa2_switch_init does: dpsw_open dpaa2_switch_detect_features dpsw_reset for (i = 0; i < ethsw->sw_attr.num_ifs; i++) { dpsw_if_disable dpsw_if_set_stp dpsw_vlan_remove_if_untagged dpsw_if_set_tci dpsw_vlan_remove_if } dpsw_vlan_remove alloc_ordered_workqueue dpsw_fdb_remove dpaa2_switch_ctrl_if_setup When dpaa2_switch_takedown is called from the error path of dpaa2_switch_probe(), the control interface, enabled by dpaa2_switch_ctrl_if_setup from dpaa2_switch_init, remains enabled, because dpaa2_switch_takedown does not call dpaa2_switch_ctrl_if_teardown. Since dpaa2_switch_probe might fail due to EPROBE_DEFER of a PHY, this means that a second probe of the driver will happen with the control interface directly enabled. This will trigger a second error: [ 93.273528] fsl_dpaa2_switch dpsw.0: dpsw_ctrl_if_set_pools() failed [ 93.281966] fsl_dpaa2_switch dpsw.0: fsl_mc_driver_probe failed: -13 [ 93.288323] fsl_dpaa2_switch: probe of dpsw.0 failed with error -13 Which if we investigate the /dev/dpaa2_mc_console log, we find out is caused by: [E, ctrl_if_set_pools:2211, DPMNG] ctrl_if must be disabled So make dpaa2_switch_takedown do the opposite of dpaa2_switch_init (in reasonable limits, no reason to change STP state, re-add VLANs etc), and rename it to something more conventional, like dpaa2_switch_teardown. Fixes: 613c0a58 ("staging: dpaa2-switch: enable the control interface") Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NIoana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20210819141755.1931423-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Sylwester Dziedziuch 提交于
Make changes to MAC address dependent on the response of PF. Disallow changes to HW MAC address and MAC filter from untrusted VF, thanks to that ping is not lost if VF tries to change MAC. Add a new field in iavf_mac_filter, to indicate whether there was response from PF for given filter. Based on this field pass or discard the filter. If untrusted VF tried to change it's address, it's not changed. Still filter was changed, because of that ping couldn't go through. Fixes: c5c922b3 ("iavf: fix MAC address setting for VFs when filter is rejected") Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by: NSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: NGurucharan G <Gurucharanx.g@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Arkadiusz Kubalewski 提交于
Without this patch, ATR does not work. Receive/transmit uses queue selection based on SW DCB hashing method. If traffic classes are not configured for PF, then use netdev_pick_tx function for selecting queue for packet transmission. Instead of calling i40e_swdcb_skb_tx_hash, call netdev_pick_tx, which ensures that packet is transmitted/received from CPU that is running the application. Reproduction steps: 1. Load i40e driver 2. Map each MSI interrupt of i40e port for each CPU 3. Disable ntuple, enable ATR i.e.: ethtool -K $interface ntuple off ethtool --set-priv-flags $interface flow-director-atr 4. Run application that is generating traffic and is bound to a single CPU, i.e.: taskset -c 9 netperf -H 1.1.1.1 -t TCP_RR -l 10 5. Observe behavior: Application's traffic should be restricted to the CPU provided in taskset. Fixes: 89ec1f08 ("i40e: Fix queue-to-TC mapping on Tx") Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: NDave Switzer <david.switzer@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 19 8月, 2021 8 次提交
-
-
由 Krzysztof Wilczyński 提交于
Two legacy PCI sysfs objects "legacy_io" and "legacy_mem" were updated to use an unified address space in the commit 636b21b5 ("PCI: Revoke mappings like devmem"). This allows for revocations to be managed from a single place when drivers want to take over and mmap() a /dev/mem range. Following the update, both of the sysfs objects should leverage the iomem_get_mapping() function to get an appropriate address range, but only the "legacy_io" has been correctly updated - the second attribute seems to be using a wrong variable to pass the iomem_get_mapping() function to. Thus, correct the variable name used so that the "legacy_mem" sysfs object would also correctly call the iomem_get_mapping() function. Fixes: 636b21b5 ("PCI: Revoke mappings like devmem") Link: https://lore.kernel.org/r/20210812132144.791268-1-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Marcin Bachry 提交于
The Renoir XHCI controller apparently doesn't resume reliably with the standard D3hot-to-D0 delay. Increase it to 20ms. [Alex: I talked to the AMD USB hardware team and the AMD Windows team and they are not aware of any HW errata or specific issues. The HW works fine in Windows. I was told Windows uses a rather generous default delay of 100ms for PCI state transitions.] Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.comSigned-off-by: NMarcin Bachry <hegel666@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Prike Liang <prike.liang@amd.com> Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
-
由 Hayes Wang 提交于
The maximum PLA bp number of RTL8153C is 16, not 8. That is, the bp 0 ~ 15 are at 0xfc28 ~ 0xfc46, and the bp_en is at 0xfc48. Fixes: 195aae32 ("r8152: support new chips") Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hayes Wang 提交于
The register of USB_BP2_EN is 16 bits, so we should use ocp_write_word(), not ocp_write_byte(). Fixes: 9370f2d0 ("support request_firmware for RTL8153") Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
Currently we are unable to ping a bridge on top of a felix switch which uses the ocelot-8021q tagger. The packets are dropped on the ingress of the user port and the 'drop_local' counter increments (the counter which denotes drops due to no valid destinations). Dumping the PGID tables, it becomes clear that the PGID_SRC of the user port is zero, so it has no valid destinations. But looking at the code, the cpu_fwd_mask (the bit mask of DSA tag_8021q ports) is clearly missing from the forwarding mask of ports that are under a bridge. So this has always been broken. Looking at the version history of the patch, in v7 https://patchwork.kernel.org/project/netdevbpf/patch/20210125220333.1004365-12-olteanv@gmail.com/ the code looked like this: /* Standalone ports forward only to DSA tag_8021q CPU ports */ unsigned long mask = cpu_fwd_mask; (...) } else if (ocelot->bridge_fwd_mask & BIT(port)) { mask |= ocelot->bridge_fwd_mask & ~BIT(port); while in v8 (the merged version) https://patchwork.kernel.org/project/netdevbpf/patch/20210129010009.3959398-12-olteanv@gmail.com/ it looked like this: unsigned long mask; (...) } else if (ocelot->bridge_fwd_mask & BIT(port)) { mask = ocelot->bridge_fwd_mask & ~BIT(port); So the breakage was introduced between v7 and v8 of the patch. Fixes: e21268ef ("net: dsa: felix: perform switch setup for tag_8021q") Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210817160425.3702809-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Zhan Liu 提交于
[why] dcn301_calculate_wm_and_dl() causes flickering when external monitor is connected. This issue has been fixed before by commit 0e4c0ae5 ("drm/amdgpu/display: drop dcn301_calculate_wm_and_dl for now"), however part of the fix was gone after commit 2cbcb78c ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next"). [how] Use dcn30_calculate_wm_and_dlg() instead as in the original fix. Fixes: 2cbcb78c ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next") Signed-off-by: NNikola Cornij <nikola.cornij@amd.com> Reviewed-by: NZhan Liu <zhan.liu@amd.com> Tested-by: NZhan Liu <zhan.liu@amd.com> Tested-by: NOliver Logush <oliver.logush@amd.com> Signed-off-by: NZhan Liu <zhan.liu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Kees Cook 提交于
Refactor struct ehci_regs to avoid accessing beyond the end of port_status. This change results in no difference in the final object code. Avoids several warnings when building with -Warray-bounds: drivers/usb/host/ehci-brcm.c: In function 'ehci_brcm_reset': drivers/usb/host/ehci-brcm.c:113:32: warning: array subscript 16 is above array bounds of 'u32[15]' {aka 'unsigned int[15]'} [-Warray-bounds] 113 | ehci_writel(ehci, 0x00800040, &ehci->regs->port_status[0x10]); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/usb/host/ehci.h:274, from drivers/usb/host/ehci-brcm.c:15: ./include/linux/usb/ehci_def.h:132:7: note: while referencing 'port_status' 132 | u32 port_status[HCS_N_PORTS_MAX]; | ^~~~~~~~~~~ Note that the documentation around this proprietary register was confusing. If "USB_EHCI_INSNREG00" is at port_status[0x0f], its offset would be 0x80 (not 0x90). The comments have been adjusted to fix this apparent typo. Fixes: 9df23151 ("usb: ehci: Add new EHCI driver for Broadcom STB SoC's") Cc: Al Cooper <alcooperx@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Suggested-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NKees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210818173018.2259231-3-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Thomas Weißschuh 提交于
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-901207693Signed-off-by: NThomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210818164435.99821-1-linux@weissschuh.netSigned-off-by: NHans de Goede <hdegoede@redhat.com>
-
- 18 8月, 2021 25 次提交
-
-
由 Nadezda Lutovinova 提交于
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: 90fccb52 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NNadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Commit a20dcf53 ("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: a20dcf53 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo") Cc: stable <stable@vger.kernel.org> Cc: Kyle Tso <kyletso@google.com> Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: NKyle Tso <kyletso@google.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210816154632.381968-1-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pavel Hofman 提交于
Fixing inconsistent indenting identified by kernel test robot. Signed-off-by: NPavel Hofman <pavel.hofman@ivitera.com> Acked-By: NFelipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20210817100555.4437-1-pavel.hofman@ivitera.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lukas Bulwahn 提交于
Commit 7583b63c ("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: NLukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-4-lukas.bulwahn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lukas Bulwahn 提交于
Commit 71ed79b0 ("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: NLukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-3-lukas.bulwahn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lukas Bulwahn 提交于
Commit 1b00767f ("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: NLukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-2-lukas.bulwahn@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jack Pham 提交于
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 d1d90dd2 ("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: NJun 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: NJun Li <jun.li@nxp.com> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NJack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210812082635.12924-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jani Nikula 提交于
The symbol isn't needed outside of i915.ko. Fixes: b30edfd8 ("drm/i915: Switch to LTTPR non-transparent mode link training") Fixes: 264613b4 ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210816071737.2917-1-jani.nikula@intel.com (cherry picked from commit d8959fb3) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Jani Nikula 提交于
ADL-P supports stream splitter on pipe B in addition to pipe A. Update the sanity check in intel_ddi_mso_get_config() to reflect this, and remove the check in intel_ddi_mso_configure() as redundant with encoder->pipe_mask. Abstract the splitter pipe mask to a single point of truth while at it to avoid similar mistakes in the future. Fixes: 7bc188cc ("drm/i915/adl_p: enable MSO on pipe B") Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Reviewed-by: NSwati Sharma <swati2.sharma@intel.com> Tested-by: NSwati Sharma <swati2.sharma@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210812132354.10885-1-jani.nikula@intel.com (cherry picked from commit f6864b27) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Anshuman Gupta 提交于
dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked Wa_14010685332 sequence for every PCH since PCH_CNP. v2: - removed RKL from comment and simplified condition. [Rodrigo] Fixes: b896898c ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210810113112.31739-2-anshuman.gupta@intel.com (cherry picked from commit 8b46cc65) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Liu Yi L 提交于
This fixes improper iotlb invalidation in intel_pasid_tear_down_entry(). When a PASID was used as nested mode, released and reused, the following error message will appear: [ 180.187556] Unexpected page request in Privilege Mode [ 180.187565] Unexpected page request in Privilege Mode [ 180.279933] Unexpected page request in Privilege Mode [ 180.279937] Unexpected page request in Privilege Mode Per chapter 6.5.3.3 of VT-d spec 3.3, when tear down a pasid entry, the software should use Domain selective IOTLB flush if the PGTT of the pasid entry is SL only or Nested, while for the pasid entries whose PGTT is FL only or PT using PASID-based IOTLB flush is enough. Fixes: 2cd1311a ("iommu/vt-d: Add set domain DOMAIN_ATTR_NESTING attr") Signed-off-by: NKumar Sanjay K <sanjay.k.kumar@intel.com> Signed-off-by: NLiu Yi L <yi.l.liu@intel.com> Tested-by: NYi Sun <yi.y.sun@intel.com> Link: https://lore.kernel.org/r/20210817042425.1784279-1-yi.l.liu@intel.comSigned-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210817124321.1517985-3-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Fenghua Yu 提交于
A PASID reference is increased whenever a device is bound to an mm (and its PASID) successfully (i.e. the device's sdev user count is increased). But the reference is not dropped every time the device is unbound successfully from the mm (i.e. the device's sdev user count is decreased). The reference is dropped only once by calling intel_svm_free_pasid() when there isn't any device bound to the mm. intel_svm_free_pasid() drops the reference and only frees the PASID on zero reference. Fix the issue by dropping the PASID reference and freeing the PASID when no reference on successful unbinding the device by calling intel_svm_free_pasid() . Fixes: 40483774 ("iommu/vt-d: Use iommu_sva_alloc(free)_pasid() helpers") Signed-off-by: NFenghua Yu <fenghua.yu@intel.com> Link: https://lore.kernel.org/r/20210813181345.1870742-1-fenghua.yu@intel.comSigned-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210817124321.1517985-2-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Pavel Skripkin 提交于
Syzbot reported uninit-value in asix_mdio_read(). The problem was in missing error handling. asix_read_cmd() should initialize passed stack variable smsr, but it can fail in some cases. Then while condidition checks possibly uninit smsr variable. Since smsr is uninitialized stack variable, driver can misbehave, because smsr will be random in case of asix_read_cmd() failure. Fix it by adding error handling and just continue the loop instead of checking uninit value. Added helper function for checking Host_En bit, since wrong loop was used in 4 functions and there is no need in copy-pasting code parts. Cc: Robert Foss <robert.foss@collabora.com> Fixes: d9fe64e5 ("net: asix: Add in_pm parameter") Reported-by: syzbot+a631ec9e717fb0423053@syzkaller.appspotmail.com Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Saravana Kannan 提交于
When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't ignore it and continue registering the rest of the mdiobus children. This would permanently prevent the deferring child mdiobus from working instead of reattempting it in the future. So, if a child mdiobus needs to be reattempted in the future, defer the entire mdio-mux initialization. This fixes the issue where PHYs sitting under the mdio-mux aren't initialized correctly if the PHY's interrupt controller is not yet ready when the mdio-mux is being probed. Additional context in the link below. Fixes: 0ca2997d ("netdev/of/phy: Add MDIO bus multiplexer support.") Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#tSigned-off-by: NSaravana Kannan <saravanak@google.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NMarc Zyngier <maz@kernel.org> Tested-by: NMarc Zyngier <maz@kernel.org> Acked-by: NKevin Hilman <khilman@baylibre.com> Tested-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Saravana Kannan 提交于
If we are seeing memory allocation errors, don't try to continue registering child mdiobus devices. It's unlikely they'll succeed. Fixes: 342fa196 ("mdio: mux: make child bus walking more permissive and errors more verbose") Signed-off-by: NSaravana Kannan <saravanak@google.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NMarc Zyngier <maz@kernel.org> Tested-by: NMarc Zyngier <maz@kernel.org> Acked-by: NKevin Hilman <khilman@baylibre.com> Tested-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Saravana Kannan 提交于
The whole point of devm_* APIs is that you don't have to undo them if you are returning an error that's going to get propagated out of a probe() function. So delete unnecessary devm_kfree() call in the error return path. Fixes: b6016166 ("mdio: mux: Correct mdio_mux_init error path issues") Signed-off-by: NSaravana Kannan <saravanak@google.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NMarc Zyngier <maz@kernel.org> Tested-by: NMarc Zyngier <maz@kernel.org> Acked-by: NKevin Hilman <khilman@baylibre.com> Tested-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
It seems that of_find_compatible_node has a weird calling convention in which it calls of_node_put() on the "from" node argument, instead of leaving that up to the caller. This comes from the fact that of_find_compatible_node with a non-NULL "from" argument it only supposed to be used as the iterator function of for_each_compatible_node(). OF iterator functions call of_node_get on the next OF node and of_node_put() on the previous one. When of_find_compatible_node calls of_node_put, it actually never expects the refcount to drop to zero, because the call is done under the atomic devtree_lock context, and when the refcount drops to zero it triggers a kobject and a sysfs file deletion, which assume blocking context. So any driver call to of_find_compatible_node is probably buggy because an unexpected of_node_put() takes place. What should be done is to use the of_get_compatible_child() function. Fixes: 5a8f0974 ("net: dsa: sja1105: register the MDIO buses for 100base-T1 and 100base-TX") Link: https://lore.kernel.org/netdev/20210814010139.kzryimmp4rizlznt@skbuf/Suggested-by: NFrank Rowand <frowand.list@gmail.com> Suggested-by: NRob Herring <robh+dt@kernel.org> Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Skeggs 提交于
No longer required now that userspace can't touch anything that might need it, and should fix DRM MM operations racing with each other, and the random hangs/crashes that come with that. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Ben Skeggs 提交于
Long ago, there had been plans for making use of a bunch of these APIs from userspace and there's various checks in place to stop misbehaving. Countless other projects have occurred in the meantime, and the pieces didn't finish falling into place for that to happen. They will (hopefully) in the not-too-distant future, but it won't look quite as insane. The super checks are causing problems right now, and are going to be removed. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Ben Skeggs 提交于
I honestly don't even know why... These have never been used. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Ben Skeggs 提交于
Should fix some initial modeset failures on (at least) Ampere boards. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Ben Skeggs 提交于
When booted with multiple displays attached, the EFI GOP driver on (at least) Ampere, can leave DP links powered up that aren't being used to display anything. This confuses our tracking of SOR routing, with the likely result being a failed modeset and display engine hang. Fix this by (ab?)using the DisableLT IED script to power-down the link, restoring HW to a state the driver expects. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Ben Skeggs 提交于
Still no GA106 as I don't have HW to verif. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NLyude Paul <lyude@redhat.com>
-
由 Thomas Weißschuh 提交于
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115Signed-off-by: NThomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.netSigned-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Wang Hai 提交于
In ixgbe_xsk_pool_enable(), if ixgbe_xsk_wakeup() fails, We should restore the previous state and clean up the resources. Add the missing clear af_xdp_zc_qps and unmap dma to fix this bug. Fixes: d49e286d ("ixgbe: add tracking of AF_XDP zero-copy state for each queue pair") Fixes: 4a9b32f3 ("ixgbe: fix potential RX buffer starvation for AF_XDP") Signed-off-by: NWang Hai <wanghai38@huawei.com> Acked-by: NMagnus Karlsson <magnus.karlsson@intel.com> Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20210817203736.3529939-1-anthony.l.nguyen@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-