aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-03-17ACPI / x86: Add support for LPS0 callback handlerMario Limonciello1-0/+40
Currenty the latest thing run during a suspend to idle attempt is the LPS0 `prepare_late` callback and the earliest thing is the `resume_early` callback. There is a desire for the `amd-pmc` driver to suspend later in the suspend process (ideally the very last thing), so create a callback that it or any other driver can hook into to do this. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220317141445.6498-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-17platform/x86: thinkpad_acpi: consistently check fan_get_status return.Tom Rix1-6/+6
Clang static analysis returns this false positive thinkpad_acpi.c:8926:19: warning: The left operand of '!=' is a garbage value (status != 0) ? "enabled" : "disabled", status); ~~~~~~ ^ The return of fan_get_status* is checked inconsistenly. Sometime ret < 0 is an error, sometimes !ret. Both fan_get_status() and fan_get_status_safe() return 0 on success and return negative otherwise. Change the checks for error, ret < 0, into checks for not success, !ret. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220312145327.1398510-1-trix@redhat.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-17drm/i915: include uapi/drm/i915_drm.h directly where neededJani Nikula5-3/+7
Remove the uapi/drm/i915_drm.h include from drm/i915_drm.h, and stop being a proxy for uapi/drm/i915_drm.h. Include uapi/drm/i915_drm.h and drm/i915_drm.h only where needed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311100639.114685-2-jani.nikula@intel.com
2022-03-17spi: Fix erroneous sgs value with min_t()Biju Das1-2/+2
While computing sgs in spi_map_buf(), the data type used in min_t() for max_seg_size is 'unsigned int' where as that of ctlr->max_dma_len is 'size_t'. min_t(unsigned int,x,y) gives wrong results if one of x/y is 'size_t' Consider the below examples on a 64-bit machine (ie size_t is 64-bits, and unsigned int is 32-bit). case 1) min_t(unsigned int, 5, 0x100000001); case 2) min_t(size_t, 5, 0x100000001); Case 1 returns '1', where as case 2 returns '5'. As you can see the result from case 1 is wrong. This patch fixes the above issue by using the data type of the parameters that are used in min_t with maximum data length. Fixes: commit 1a4e53d2fc4f68aa ("spi: Fix invalid sgs value") Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220316175317.465-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-03-17spi: Get sgs size fix into branchMark Brown1-2/+2
Dependency for patch to be applied.
2022-03-17iavf: Fix hang during reboot/shutdownIvan Vecera1-0/+7
Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot [52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca Fixes: 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://lore.kernel.org/r/20220317104524.2802848-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-17net: mscc: ocelot: fix backwards compatibility with single-chain tc-flower offloadVladimir Oltean1-1/+15
ACL rules can be offloaded to VCAP IS2 either through chain 0, or, since the blamed commit, through a chain index whose number encodes a specific PAG (Policy Action Group) and lookup number. The chain number is translated through ocelot_chain_to_pag() into a PAG, and through ocelot_chain_to_lookup() into a lookup number. The problem with the blamed commit is that the above 2 functions don't have special treatment for chain 0. So ocelot_chain_to_pag(0) returns filter->pag = 224, which is in fact -32, but the "pag" field is an u8. So we end up programming the hardware with VCAP IS2 entries having a PAG of 224. But the way in which the PAG works is that it defines a subset of VCAP IS2 filters which should match on a packet. The default PAG is 0, and previous VCAP IS1 rules (which we offload using 'goto') can modify it. So basically, we are installing filters with a PAG on which no packet will ever match. This is the hardware equivalent of adding filters to a chain which has no 'goto' to it. Restore the previous functionality by making ACL filters offloaded to chain 0 go to PAG 0 and lookup number 0. The choice of PAG is clearly correct, but the choice of lookup number isn't "as before" (which was to leave the lookup a "don't care"). However, lookup 0 should be fine, since even though there are ACL actions (policers) which have a requirement to be used in a specific lookup, that lookup is 0. Fixes: 226e9cd82a96 ("net: mscc: ocelot: only install TCAM entries into a specific lookup and PAG") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220316192117.2568261-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-17net: bcmgenet: skip invalid partial checksumsDoug Berger1-2/+4
The RXCHK block will return a partial checksum of 0 if it encounters a problem while receiving a packet. Since a 1's complement sum can only produce this result if no bits are set in the received data stream it is fair to treat it as an invalid partial checksum and not pass it up the stack. Fixes: 810155397890 ("net: bcmgenet: use CHECKSUM_COMPLETE for NETIF_F_RXCSUM") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220317012812.1313196-1-opendmb@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-17bnx2x: fix built-in kernel driver load failureManish Chopra3-26/+19
Commit b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0") added request_firmware() logic in probe() which caused load failure when firmware file is not present in initrd (below), as access to firmware file is not feasible during probe. Direct firmware load for bnx2x/bnx2x-e2-7.13.15.0.fw failed with error -2 Direct firmware load for bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2 This patch fixes this issue by - 1. Removing request_firmware() logic from the probe() such that .ndo_open() handle it as it used to handle it earlier 2. Given request_firmware() is removed from probe(), so driver has to relax FW version comparisons a bit against the already loaded FW version (by some other PFs of same adapter) to allow different compatible/close enough FWs with which multiple PFs may run with (in different environments), as the given PF who is in probe flow has no idea now with which firmware file version it is going to initialize the device in ndo_open() Link: https://lore.kernel.org/all/46f2d9d9-ae7f-b332-ddeb-b59802be2bab@molgen.mpg.de/ Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Fixes: b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0") Signed-off-by: Manish Chopra <manishc@marvell.com> Signed-off-by: Ariel Elior <aelior@marvell.com> Link: https://lore.kernel.org/r/20220316214613.6884-1-manishc@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-17virtio_blk: eliminate anonymous module_init & module_exitRandy Dunlap1-4/+4
Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs Fixes: e467cde23818 ("Block driver using virtio.") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Link: https://lore.kernel.org/r/20220316192010.19001-2-rdunlap@infradead.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-03-17net: phy: mscc: Add MODULE_FIRMWARE macrosJuerg Haefliger1-0/+3
The driver requires firmware so define MODULE_FIRMWARE so that modinfo provides the details. Fixes: fa164e40c53b ("net: phy: mscc: split the driver into separate files") Signed-off-by: Juerg Haefliger <juergh@canonical.com> Link: https://lore.kernel.org/r/20220316151835.88765-1-juergh@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-17igb: zero hwtstamp by defaultTom Rix1-4/+2
Clang static analysis reports this representative issue igb_ptp.c:997:3: warning: The left operand of '+' is a garbage value ktime_add_ns(shhwtstamps.hwtstamp, adjust); ^ ~~~~~~~~~~~~~~~~~~~~ shhwtstamps.hwtstamp is set by a call to igb_ptp_systim_to_hwtstamp(). In the switch-statement for the hw type, the hwtstamp is zeroed for matches but not the default case. Move the memset out of switch-statement. This degarbages the default case and reduces the size. Some whitespace cleanup of empty lines Signed-off-by: Tom Rix <trix@redhat.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-17drm/gma500: Cosmetic cleanup of irq codePatrik Jakobsson7-92/+57
Use the gma_ prefix instead of psb_ since the code is common for all chips. Various coding style fixes. Removal of unused code. Removal of duplicate function declarations. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-4-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Don't store crtc_funcs in psb_opsPatrik Jakobsson5-6/+1
The drm_crtc_funcs are all generic and no chip specific functions are necessary. We can therefore directly put gma_crtc_funcs into the drm_crtc. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-3-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Move gma_intel_crtc_funcs into gma_display.cPatrik Jakobsson7-25/+17
All functions live in gma_display.c already so move the vtable. Also shorten the name to gma_crtc_funcs. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-2-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Remove unused declarations and other cruftPatrik Jakobsson1-74/+1
Most of these are old leftovers from one of the driver merges. This is all dead code. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-1-patrik.r.jakobsson@gmail.com
2022-03-17i40e: little endian only valid checksumsTom Rix1-2/+3
The calculation of the checksum can fail. So move converting the checksum to little endian to inside the return status check. Signed-off-by: Tom Rix <trix@redhat.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-17Merge tag 'mt76-for-kvalo-2022-03-16' of https://github.com/nbd168/wirelessKalle Valo43-461/+1460
mt76 patches for 5.18 - bugfixes - mbssid support for mt7915 - 6 GHz support for mt7915 - mt7921u driver
2022-03-17rtw89: implement stop and resume channels transmission v1Ping-Ke Shih7-15/+123
These function is used to stop transmitting when we are going to switch channels or do some RF calibration. Before these operations, we need to stop channel transmission and backup setting into parameter tx_en. After operations are done, resume transmitting by backup parameter tx_en. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-13-pkshih@realtek.com
2022-03-17rtw89: extend mac tx_en bits from 16 to 32Ping-Ke Shih4-10/+10
In order to support 8852C that uses 32 bits to control TX types. This patch doesn't really use 32 bits tx_en yet, but next patch will use it. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-12-pkshih@realtek.com
2022-03-17rtw89: change value assignment style of rtw89_mac_cfg_gnt()Ping-Ke Shih1-22/+25
Use if() style would be clear than "? :", because the else cases are always 0. The read val from rtw89_mac_read_lte() isn't used, so remove this statement. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-11-pkshih@realtek.com
2022-03-17rtw89: 8852c: add mac_ctrl_path and mac_cfg_gnt APIsChia-Yuan Li7-12/+133
The BT-coexistence uses these function to control antenna and TDMA, so implement the variant type to support all chips. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-10-pkshih@realtek.com
2022-03-17rtw89: disable FW and H2C function if CPU disabledChia-Yuan Li1-0/+4
Initialize FW status and disabled H2C function if CPU disabled. Then, it can reset to initial state. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-9-pkshih@realtek.com
2022-03-17rtw89: initialize preload window of D-MACPing-Ke Shih2-0/+67
8852C add new hardware feature -- preload window, which is used to load more data to D-MAC, so it can possibly yield better performance. This patch is to configure preload and reserved size for next window. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-8-pkshih@realtek.com
2022-03-17rtw89: modify MAC enable functionsChia-Yuan Li2-6/+25
Modify functions that control D-MAC (data MAC) and LDO to support variant chips. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-7-pkshih@realtek.com
2022-03-17rtw89: add config_rf_reg_v1 to configure RF parameter tablesPing-Ke Shih3-4/+27
The format of RF parameter is changed; it doesn't encode delay parameters into table, but the delay coding becomes regular pair of register address and value. To help firmware to recover RF register settings, we need to download these parameters to firmware. For v1 format, only download partial parameters (ignore them with addr < 0x100). Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-6-pkshih@realtek.com
2022-03-17rtw89: 8852c: add read/write rf register functionChung-Hsuan Hung4-0/+134
Using encoded address which BIT(16) is used to discriminate which region is going to access. Illustrate the calling flow as below rtw89_phy_write_rf_v1() -+-> rtw89_phy_write_rf() // old interface +-> rtw89_phy_write_rf_a() // new interface Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-5-pkshih@realtek.com
2022-03-17rtw89: 8852c: add setting of TB UL TX power offsetYuan-Han Zhang4-5/+43
Configure this TX power to indicate TX power offset that uses to transmit TB (trigger base) uplink frames. Also, shrink the unit of TX power offset changes to suitable type s8. Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-4-pkshih@realtek.com
2022-03-17rtw89: 8852c: add write/read crystal function in CFO trackingYuan-Han Zhang2-4/+17
The CFO tracking algorithm is the same, but control methods are different. Set parameters via xtal serial interfaces (SI). Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-3-pkshih@realtek.com
2022-03-17rtw89: modify dcfo_comp to share with chipsYuan-Han Zhang5-4/+22
The dcfo_comp is digital CFO (central frequency offset) compensation. Since the flow can be shared with all chips, add chip parameters to support variant register address and format. Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-2-pkshih@realtek.com
2022-03-17rtw89: Fix spelling mistake "Mis-Match" -> "Mismatch"Colin Ian King1-3/+3
There are some spelling mistakes in some literal strings. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220316234242.55515-1-colin.i.king@gmail.com
2022-03-17brcmfmac: p2p: Fix spelling mistake "Comback" -> "Comeback"Colin Ian King1-4/+4
There are some spelling mistakes in comments and brcmf_dbg messages. Fix these. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220316233938.55135-1-colin.i.king@gmail.com
2022-03-17iwlwifi: mei: fix building iwlmeiArnd Bergmann1-0/+1
Building iwlmei without CONFIG_CFG80211 causes a link-time warning: ld.lld: error: undefined symbol: ieee80211_hdrlen >>> referenced by net.c >>> net/wireless/intel/iwlwifi/mei/net.o:(iwl_mei_tx_copy_to_csme) in archive drivers/built-in.a Add an explicit dependency to avoid this. In theory it should not be needed here, but it also seems pointless to allow IWLMEI for configurations without CFG80211. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Emmanuel Grumbach <Emmanuel.grumbach@intel.com> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220316183617.1470631-1-arnd@kernel.org
2022-03-17drm/vc4: add tracepoints for CL submissionsMelissa Wen3-0/+107
Trace submit_cl_ioctl and related IRQs for CL submission and bin/render jobs execution. It might be helpful to get a rendering timeline and track job throttling. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220201212651.zhltjmaokisffq3x@mail.igalia.com
2022-03-17cpufreq: powernow-k8: Re-order the init checksMario Limonciello1-3/+3
The powernow-k8 driver will do checks at startup that the current active driver is acpi-cpufreq and show a warning when they're not expected. Because of this the following warning comes up on systems that support amd-pstate and compiled in both drivers: `WTF driver: amd-pstate` The systems that support powernow-k8 will not support amd-pstate, so re-order the checks to validate the CPU model number first to avoid this warning being displayed on modern SOCs. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-17ACPI: bus: Avoid using CPPC if not supported by firmwareRafael J. Wysocki2-0/+11
If the platform firmware indicates that it does not support CPPC by clearing the OSC_SB_CPC_SUPPORT and OSC_SB_CPCV2_SUPPORT bits in the platform _OSC capabilities mask, avoid attempting to evaluate _CPC which may fail in that case. Because the OSC_SB_CPC_SUPPORT and OSC_SB_CPCV2_SUPPORT bits are only added to the supported platform capabilities mask on x86, when X86_FEATURE_HWP is supported, allow _CPC to be evaluated regardless in the other cases. Link: https://lore.kernel.org/linux-acpi/CAJZ5v0i=ecAksq0TV+iLVObm-=fUfdqPABzzkgm9K6KxO1ZCcg@mail.gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-17Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"Rafael J. Wysocki1-8/+19
Revert commit 159d8c274fd9 ("ACPI: Pass the same capabilities to the _OSC regardless of the query flag") which caused legitimate usage scenarios (when the platform firmware does not want the OS to control certain platform features controlled by the system bus scope _OSC) to break and was misguided by some misleading language in the _OSC definition in the ACPI specification (in particular, Section 6.2.11.1.3 "Sequence of _OSC Calls" that contradicts other perts of the _OSC definition). Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com Reported-by: Mario Limonciello <Mario.Limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-17cpuidle: intel_idle: Drop redundant backslash at line endRafael J. Wysocki1-1/+1
Drop a redundant backslash character at the end of a line in the spr_cstates[] definition. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2022-03-17cpuidle: intel_idle: Update intel_idle() kerneldoc commentRafael J. Wysocki1-3/+0
Commit bf9282dc26e7 ("cpuidle: Make CPUIDLE_FLAG_TLB_FLUSHED generic") moved the leave_mm() call away from intel_idle(), but it didn't update its kerneldoc comment accordingly, so do that now. Fixes: bf9282dc26e7 ("cpuidle: Make CPUIDLE_FLAG_TLB_FLUSHED generic") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-17ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNUWerner Sembach1-0/+75
Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a working native and video interface. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-17net: stmmac: clean up impossible conditionDan Carpenter1-4/+1
This code works but it has a static checker warning: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1687 init_dma_rx_desc_rings() warn: always true condition '(queue >= 0) => (0-u32max >= 0)' Obviously, it makes no sense to check if an unsigned int is >= 0. What prevents this code from being a forever loop is that later there is a separate check for if (queue == 0). The "queue" variable is less than MTL_MAX_RX_QUEUES (8) so it can easily fit in an int type. Any larger value for "queue" would lead to an array overflow when we assign "rx_q = &priv->rx_queue[queue]". Fixes: de0b90e52a11 ("net: stmmac: rearrange RX and TX desc init into per-queue basis") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220316083744.GB30941@kili Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-03-17net: geneve: support IPv4/IPv6 as inner protocolEyal Birger1-19/+63
This patch adds support for encapsulating IPv4/IPv6 within GENEVE. In order to use this, a new IFLA_GENEVE_INNER_PROTO_INHERIT flag needs to be provided at device creation. This property cannot be changed for the time being. In case IP traffic is received on a non-tun device the drop count is increased. Signed-off-by: Eyal Birger <eyal.birger@gmail.com> Link: https://lore.kernel.org/r/20220316061557.431872-1-eyal.birger@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-03-17drm/ssd130x: Reduce temporary buffer sizesGeert Uytterhoeven1-3/+6
ssd130x_clear_screen() allocates a temporary buffer sized to hold one byte per pixel, while it only needs to hold one bit per pixel. ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one byte per pixel for the whole frame buffer, while it only needs to hold one bit per pixel for the part that is to be updated. Pass dst_pitch to drm_fb_xrgb8888_to_mono(), as we have already calculated it anyway. Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-5-geert@linux-m68k.org
2022-03-17drm/ssd130x: Fix rectangle updatesGeert Uytterhoeven1-4/+11
The rectangle update functions ssd130x_fb_blit_rect() and ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 != 0, or when y1 or y2 are not aligned to display page boundaries. E.g. when used as a text console, only the first line of text is shown on the display. 1. The buffer passed by ssd130x_fb_blit_rect() points to the first byte of monochrome bitmap data, and thus has its origin at (x1, y1), while ssd130x_update_rect() assumes it is at (0, 0). Fix ssd130x_update_rect() by changing the vertical and horizontal loop ranges, and adding the offsets only when needed. 2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page boundaries before doing the color conversion, so the full page is converted and updated. Remove the correction for an unaligned y1 from ssd130x_update_rect(), and add a check to make sure y1 is aligned. Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-4-geert@linux-m68k.org
2022-03-17drm/format-helper: Fix XRGB888 to monochrome conversionGeert Uytterhoeven1-37/+18
The conversion functions drm_fb_xrgb8888_to_mono() and drm_fb_gray8_to_mono_line() do not behave correctly when the horizontal boundaries of the clip rectangle are not multiples of 8: a. When x1 % 8 != 0, the calculated pitch is not correct, b. When x2 % 8 != 0, the pixel data for the last byte is wrong. Simplify the code and fix (a) by: 1. Removing start_offset, and always storing the first pixel in the first bit of the monochrome destination buffer. Drivers that require the first pixel in a byte to be located at an x-coordinate that is a multiple of 8 can always align the clip rectangle before calling drm_fb_xrgb8888_to_mono(). Note that: - The ssd130x driver does not need the alignment, as the monochrome buffer is a temporary format, - The repaper driver always updates the full screen, so the clip rectangle is always aligned. 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(), instead of the number of bytes, and the number of pixels in the last byte. Fix (b) by explicitly setting the target bit, instead of always setting bit 7 and shifting the value in each loop iteration. Remove the bogus pitch check, which operates on bytes instead of pixels, and triggers when e.g. flashing the cursor on a text console with a font that is 8 pixels wide. Drop the confusing comment about scanlines, as a pitch in bytes always contains a multiple of 8 pixels. While at it, use the drm_rect_height() helper instead of open-coding the same operation. Update the comments accordingly. Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-3-geert@linux-m68k.org
2022-03-17drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()Geert Uytterhoeven3-18/+17
There is no "reversed" handling in drm_fb_xrgb8888_to_mono_reversed(): the function just converts from color to grayscale, and reduces the number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is mapped to 0, 128-255 to 1). All "reversed" handling is done in the repaper driver, where this function originated. Hence make this clear by renaming drm_fb_xrgb8888_to_mono_reversed() to drm_fb_xrgb8888_to_mono(), and documenting the black/white pixel mapping. Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-2-geert@linux-m68k.org
2022-03-17drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERSThomas Zimmermann2-1/+2
Fix a number of undefined references to drm_kms_helper.ko in drm_dp_helper.ko: arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_duplicate_state': drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to `__drm_atomic_helper_private_obj_duplicate_state' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_delayed_destroy_work': drm_dp_mst_topology.c:(.text+0x370c): undefined reference to `drm_kms_helper_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_up_req_work': drm_dp_mst_topology.c:(.text+0x7938): undefined reference to `drm_kms_helper_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_link_probe_work': drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to `drm_kms_helper_hotplug_event' This happens if panel-edp.ko has been configured with DRM_PANEL_EDP=y DRM_DP_HELPER=y DRM_KMS_HELPER=m which builds DP helpers into the kernel and KMS helpers sa a module. Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem. To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers cannot be selected directly by the user, config symbols should avoid depending on it anyway. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP") Acked-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Brian Masney <bmasney@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Cc: Linux Kernel Functional Testing <lkft@linaro.org> Cc: Lyude Paul <lyude@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Dave Airlie <airlied@redhat.com> Cc: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/478296/
2022-03-17Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann724-4119/+6930
Backmerging drm/drm-fixes for commit 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP"). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2022-03-17net: mvneta: Add support for 98DX2530 Ethernet portChris Packham1-0/+12
The 98DX2530 SoC is similar to the Armada 3700 except it needs a different MBUS window configuration. Add a new compatible string to identify this device and the required MBUS window configuration. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-03-17ptp: ocp: Fix PTP_PF_* verification requestsJonathan Lemon1-8/+20
Update and check functionality for pin configuration requests: PTP_PF_NONE: requests "IN: None", disabling the pin. # testptp -d /dev/ptp3 -L3,0 -i1 set pin function okay # cat sma4 IN: None PTP_PF_EXTTS: should configure external timestamps, but since the timecard can steer inputs to multiple inputs as well as timestamps, allow the request, but don't change configurations. # testptp -d /dev/ptp3 -L3,1 -i1 set pin function okay (no functional or configuration change here yet) PTP_PF_PEROUT: Channel 0 is the PHC, at 1PPS. Channels 1-4 are the programmable frequency generators. # fails because period is not 1PPS. # testptp -d /dev/ptp3 -L3,2 -i0 -p 500000000 PTP_PEROUT_REQUEST: Invalid argument # testptp -d /dev/ptp3 -L3,2 -i0 -p 1000000000 periodic output request okay # cat sma4 OUT: PHC # testptp -d /dev/ptp3 -L3,2 -i1 -p 500000000 -w 200000000 periodic output request okay # cat sma4 OUT: GEN1 # cat gen1/signal 500000000 40 0 1 2022-03-10T23:55:26 TAI # cat gen1/running 1 # testptp -d /dev/ptp3 -L3,2 -i1 -p 0 periodic output request okay # cat gen1/running 0 Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220315194626.1895-1-jonathan.lemon@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>