summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-22drm/i915/tc: Fix the ICL PHY ownership check in TC-cold stateImre Deak
The commit renaming icl_tc_phy_is_in_safe_mode() to icl_tc_phy_take_ownership() didn't flip the function's return value accordingly, fix this up. This didn't cause an actual problem besides state check errors, since the function is only used during HW readout. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: f53979d68a77 ("drm/i915/display/tc: Rename safe_mode functions ownership") Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-4-imre.deak@intel.com
2023-03-22drm/i915/tc: Fix TC port link ref init for DP MST during HW readoutImre Deak
An enabled TC MST port holds one TC port link reference, regardless of the number of enabled streams on it, but the TC port HW readout takes one reference for each active MST stream. Fix the HW readout, taking only one reference for MST ports. This didn't cause an actual problem, since the encoder HW readout doesn't yet support reading out the MST HW state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-3-imre.deak@intel.com
2023-03-22drm/i915/tc: Abort DP AUX transfer on a disconnected TC portImre Deak
On TC ports the 4ms AUX timeout combined with the 5 * 32 retry attempts during DPCD accesses adds a 640ms delay to each access if the sink is disconnected. This in turn slows down a modeset during which the sink is disconnected (for instance a disabling modeset). Prevent the above delay by aborting AUX transfers on a TC port with a disconnected sink. The DP 1.4a link CTS (4.2.1.5 Source Device Inactive HPD / Inactive AUX Test") also requires not to initiate AUX transfers on disconnected DP ports in general, however this patch doesn't change the behavior on non-TC ports, leaving that for a follow-up. Reported-and-tested-by: Chris Chiu <chris.chiu@canonical.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8279 Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-2-imre.deak@intel.com
2023-03-22selftests/x86/amx: Add a ptrace testChang S. Bae
Include a test case to validate the XTILEDATA injection to the target. Also, it ensures the kernel's ability to copy states between different XSAVE formats. Refactor the memcmp() code to be usable for the state validation. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20230227210504.18520-3-chang.seok.bae%40intel.com
2023-03-22x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf()Chang S. Bae
__copy_xstate_to_uabi_buf() copies either from the tasks XSAVE buffer or from init_fpstate into the ptrace buffer. Dynamic features, like XTILEDATA, have an all zeroes init state and are not saved in init_fpstate, which means the corresponding bit is not set in the xfeatures bitmap of the init_fpstate header. But __copy_xstate_to_uabi_buf() retrieves addresses for both the tasks xstate and init_fpstate unconditionally via __raw_xsave_addr(). So if the tasks XSAVE buffer has a dynamic feature set, then the address retrieval for init_fpstate triggers the warning in __raw_xsave_addr() which checks the feature bit in the init_fpstate header. Remove the address retrieval from init_fpstate for extended features. They have an all zeroes init state so init_fpstate has zeros for them. Then zeroing the user buffer for the init state is the same as copying them from init_fpstate. Fixes: 2308ee57d93d ("x86/fpu/amx: Enable the AMX feature in 64-bit mode") Reported-by: Mingwei Zhang <mizhang@google.com> Link: https://lore.kernel.org/kvm/20230221163655.920289-2-mizhang@google.com/ Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Mingwei Zhang <mizhang@google.com> Link: https://lore.kernel.org/all/20230227210504.18520-2-chang.seok.bae%40intel.com Cc: stable@vger.kernel.org
2023-03-22x86/mm: Do not shuffle CPU entry areas without KASLRMichal Koutný
The commit 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") fixed an omission of KASLR on CPU entry areas. It doesn't take into account KASLR switches though, which may result in unintended non-determinism when a user wants to avoid it (e.g. debugging, benchmarking). Generate only a single combination of CPU entry areas offsets -- the linear array that existed prior randomization when KASLR is turned off. Since we have 3f148f331814 ("x86/kasan: Map shadow for percpu pages on demand") and followups, we can use the more relaxed guard kasrl_enabled() (in contrast to kaslr_memory_enabled()). Fixes: 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") Signed-off-by: Michal Koutný <mkoutny@suse.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20230306193144.24605-1-mkoutny%40suse.com
2023-03-22io_uring/rsrc: fix null-ptr-deref in io_file_bitmap_get()Savino Dicanosa
When fixed files are unregistered, file_alloc_end and alloc_hint are not cleared. This can later cause a NULL pointer dereference in io_file_bitmap_get() if auto index selection is enabled via IORING_FILE_INDEX_ALLOC: [ 6.519129] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 6.541468] RIP: 0010:_find_next_zero_bit+0x1a/0x70 [...] [ 6.560906] Call Trace: [ 6.561322] <TASK> [ 6.561672] io_file_bitmap_get+0x38/0x60 [ 6.562281] io_fixed_fd_install+0x63/0xb0 [ 6.562851] ? __pfx_io_socket+0x10/0x10 [ 6.563396] io_socket+0x93/0xf0 [ 6.563855] ? __pfx_io_socket+0x10/0x10 [ 6.564411] io_issue_sqe+0x5b/0x3d0 [ 6.564914] io_submit_sqes+0x1de/0x650 [ 6.565452] __do_sys_io_uring_enter+0x4fc/0xb20 [ 6.566083] ? __do_sys_io_uring_register+0x11e/0xd80 [ 6.566779] do_syscall_64+0x3c/0x90 [ 6.567247] entry_SYSCALL_64_after_hwframe+0x72/0xdc [...] To fix the issue, set file alloc range and alloc_hint to zero after file tables are freed. Cc: stable@vger.kernel.org Fixes: 4278a0deb1f6 ("io_uring: defer alloc_hint update to io_file_bitmap_set()") Signed-off-by: Savino Dicanosa <sd7.dev@pm.me> [axboe: add explicit bitmap == NULL check as well] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-03-22drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not foundMatheus Castello
Returns EPROBE_DEFER when of_drm_find_bridge() fails, this is consistent with what all the other DRM bridge drivers are doing and this is required since the bridge might not be there when the driver is probed and this should not be a fatal failure. Cc: <stable@vger.kernel.org> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Matheus Castello <matheus.castello@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230322143821.109744-1-francesco@dolcini.it
2023-03-22drm/meson: fix missing component unbind on bind errorsJohan Hovold
Make sure to unbind all subcomponents when binding the aggregate device fails. Fixes: a41e82e6c457 ("drm/meson: Add support for components") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230306103533.4915-1-johan+linaro@kernel.org
2023-03-22drm/mediatek: Add mediatek-drm of vdosys1 support for MT8195Nancy.Lin
Add driver data of mt8195 vdosys1 to mediatek-drm. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-8-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22drm/mediatek: Add drm ovl_adaptor sub driver for MT8195Nancy.Lin
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if the component exists in the path. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-7-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys supportNancy.Lin
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support. The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers, only one drm driver register as the drm device. Each drm driver binds its own component. The last bind drm driver allocates and registers the drm device to drm core. Each crtc path is created with the corresponding drm driver data. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-6-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22drm/mediatek: Add dma dev get functionNancy.Lin
This is a preparation for adding support for the ovl_adaptor sub driver Ovl_adaptor is a DRM sub driver, which doesn't have dma dev. Add dma_dev_get function for getting representative dma dev in ovl_adaptor. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioachino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-5-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22drm/mediatek: Add ovl_adaptor support for MT8195Nancy.Lin
Add ovl_adaptor driver for MT8195. Ovl_adaptor is an encapsulated module and designed for simplified DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and an ETHDR. Two RDMAs merge into one layer, so this module support 4 layers. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-4-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22drm/mediatek: Add ETHDR support for MT8195Nancy.Lin
ETHDR is a part of ovl_adaptor. ETHDR is designed for HDR video and graphics conversion in the external display path. It handles multiple HDR input types and performs tone mapping, color space/color format conversion, and then combine different layers, output the required HDR or SDR signal to the subsequent display path. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-3-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22dt-bindings: mediatek: add ethdr definition for mt8195Nancy.Lin
Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230321121859.2355-2-nancy.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-03-22xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver supportJesper Dangaard Brouer
When driver doesn't implement a bpf_xdp_metadata kfunc the fallback implementation returns EOPNOTSUPP, which indicate device driver doesn't implement this kfunc. Currently many drivers also return EOPNOTSUPP when the hint isn't available, which is ambiguous from an API point of view. Instead change drivers to return ENODATA in these cases. There can be natural cases why a driver doesn't provide any hardware info for a specific hint, even on a frame to frame basis (e.g. PTP). Lets keep these cases as separate return codes. When describing the return values, adjust the function kernel-doc layout to get proper rendering for the return values. Fixes: ab46182d0dcb ("net/mlx4_en: Support RX XDP metadata") Fixes: bc8d405b1ba9 ("net/mlx5e: Support RX XDP metadata") Fixes: 306531f0249f ("veth: Support RX XDP metadata") Fixes: 3d76a4d3d4e5 ("bpf: XDP metadata RX kfuncs") Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/167940675120.2718408.8176058626864184420.stgit@firesoul Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-22x86/PVH: avoid 32-bit build warning when obtaining VGA console infoJan Beulich
In the commit referenced below I failed to pay attention to this code also being buildable as 32-bit. Adjust the type of "ret" - there's no real need for it to be wider than 32 bits. Fixes: 934ef33ee75c ("x86/PVH: obtain VGA console info in Dom0") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/2d2193ff-670b-0a27-e12d-2c5c4c121c79@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2023-03-22hvc/xen: prevent concurrent accesses to the shared ringRoger Pau Monne
The hvc machinery registers both a console and a tty device based on the hv ops provided by the specific implementation. Those two interfaces however have different locks, and there's no single locks that's shared between the tty and the console implementations, hence the driver needs to protect itself against concurrent accesses. Otherwise concurrent calls using the split interfaces are likely to corrupt the ring indexes, leaving the console unusable. Introduce a lock to xencons_info to serialize accesses to the shared ring. This is only required when using the shared memory console, concurrent accesses to the hypercall based console implementation are not an issue. Note the conditional logic in domU_read_console() is slightly modified so the notify_daemon() call can be done outside of the locked region: it's an hypercall and there's no need for it to be done with the lock held. Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20221130150919.13935-1-roger.pau@citrix.com Signed-off-by: Juergen Gross <jgross@suse.com>
2023-03-22mlxsw: spectrum_fid: Fix incorrect local port typeIdo Schimmel
Local port is a 10-bit number, but it was mistakenly stored in a u8, resulting in firmware errors when using a netdev corresponding to a local port higher than 255. Fix by storing the local port in u16, as is done in the rest of the code. Fixes: bf73904f5fba ("mlxsw: Add support for 802.1Q FID family") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/eace1f9d96545ab8a2775db857cb7e291a9b166b.1679398549.git.petrm@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22arm64: dts: qcom: sc8280xp-x13s: mark bob regulator as always-onJohan Hovold
The bob supply is used by several pmic regulators and components which are not (yet fully) described in the devicetree. Mark the regulator as always-on for now. Fixes: f29077d86652 ("arm64: dts: qcom: sc8280xp-x13s: Add soundcard support") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230322113318.17908-5-johan+linaro@kernel.org
2023-03-22arm64: dts: qcom: sc8280xp-x13s: mark s12b regulator as always-onJohan Hovold
The s12b supply is used by several pmic regulators as well as the wlan/bluetooth radio which are not yet fully described in the devicetree. Mark the regulator as always-on for now. Fixes: f29077d86652 ("arm64: dts: qcom: sc8280xp-x13s: Add soundcard support") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230322113318.17908-4-johan+linaro@kernel.org
2023-03-22arm64: dts: qcom: sc8280xp-x13s: mark s10b regulator as always-onJohan Hovold
The s10b supply is used by several components that are not (yet) described in devicetree (e.g. ram, charger, ec) and must not be disabled. Mark the regulator as always-on. Fixes: f29077d86652 ("arm64: dts: qcom: sc8280xp-x13s: Add soundcard support") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230322113318.17908-3-johan+linaro@kernel.org
2023-03-22arm64: dts: qcom: sc8280xp-x13s: mark s11b regulator as always-onJohan Hovold
The s11b supply is used by the wlan module (as well as some of the pmics) which are not yet fully described in the devicetree. Mark the regulator as always-on for now. Fixes: 123b30a75623 ("arm64: dts: qcom: sc8280xp-x13s: enable WiFi controller") Cc: stable@vger.kernel.org # 6.2 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230322113318.17908-2-johan+linaro@kernel.org
2023-03-22ACPI: processor: thermal: Update CPU cooling devices on cpufreq policy changesRafael J. Wysocki
When a cpufreq policy appears or goes away, the CPU cooling devices for the CPUs covered by that policy need to be updated so that the new processor_get_max_state() value is stored as max_state and the statistics in sysfs are rearranged for each of them. Do that accordingly in acpi_thermal_cpufreq_init() and acpi_thermal_cpufreq_exit(). Fixes: a365105c685c("thermal: sysfs: Reuse cdev->max_state") Reported-by: Wang, Quanxian <quanxian.wang@intel.com> Link: https://lore.kernel.org/linux-pm/53ec1f06f61c984100868926f282647e57ecfb2d.camel@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com>
2023-03-22thermal: core: Introduce thermal_cooling_device_update()Rafael J. Wysocki
Introduce a core thermal API function, thermal_cooling_device_update(), for updating the max_state value for a cooling device and rearranging its statistics in sysfs after a possible change of its ->get_max_state() callback return value. That callback is now invoked only once, during cooling device registration, to populate the max_state field in the cooling device object, so if its return value changes, it needs to be invoked again and the new return value needs to be stored as max_state. Moreover, the statistics presented in sysfs need to be rearranged in general, because there may not be enough room in them to store data for all of the possible states (in the case when max_state grows). The new function takes care of that (and some other minor things related to it), but some extra locking and lockdep annotations are added in several places too to protect against crashes in the cases when the statistics are not present or when a stale max_state value might be used by sysfs attributes. Note that the actual user of the new function will be added separately. Link: https://lore.kernel.org/linux-pm/53ec1f06f61c984100868926f282647e57ecfb2d.camel@intel.com/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com>
2023-03-22thermal: core: Introduce thermal_cooling_device_present()Rafael J. Wysocki
Introduce a helper function, thermal_cooling_device_present(), for checking if the given cooling device is in the list of registered cooling devices to avoid some code duplication in a subsequent patch. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com>
2023-03-22ACPI: processor: Reorder acpi_processor_driver_init()Rafael J. Wysocki
The cpufreq policy notifier in the ACPI processor driver may as well be registered before the driver itself, which causes acpi_processor_cpufreq_init to be true (unless the notifier registration fails, which is unlikely at that point) when the ACPI CPU thermal cooling devices are registered, so the processor_get_max_state() result does not change while acpi_processor_driver_init() is running. Change the ordering in acpi_processor_driver_init() accordingly to prevent the max_state value from remaining 0 permanently for all ACPI CPU cooling devices due to setting acpi_processor_cpufreq_init too late. [Note that processor_get_max_state() may still return different values at different times after this change, depending on the cpufreq driver registration time, but that issue needs to be addressed separately.] Fixes: a365105c685c("thermal: sysfs: Reuse cdev->max_state") Reported-by: Wang, Quanxian <quanxian.wang@intel.com> Link: https://lore.kernel.org/linux-pm/53ec1f06f61c984100868926f282647e57ecfb2d.camel@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com>
2023-03-22bootconfig: Change message if no bootconfig with CONFIG_BOOT_CONFIG_FORCE=yMasami Hiramatsu (Google)
Change no bootconfig data error message if user do not specify 'bootconfig' option but CONFIG_BOOT_CONFIG_FORCE=y. With CONFIG_BOOT_CONFIG_FORCE=y, the kernel proceeds bootconfig check even if user does not specify 'bootconfig' option. So the current error message is confusing. Let's show just an information message to notice skipping the bootconfig in that case. Link: https://lore.kernel.org/all/167754610254.318944.16848412476667893329.stgit@devnote2/ Fixes: b743852ccc1d ("Allow forcing unconditional bootconfig processing") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/all/CAMuHMdV9jJvE2y8gY5V_CxidUikCf5515QMZHzTA3rRGEOj6=w@mail.gmail.com/ Suggested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com>
2023-03-22wifi: mac80211: fix mesh path discovery based on unicast packetsFelix Fietkau
If a packet has reached its intended destination, it was bumped to the code that accepts it, without first checking if a mesh_path needs to be created based on the discovered source. Fix this by moving the destination address check further down. Cc: stable@vger.kernel.org Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230314095956.62085-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22wifi: mac80211: fix qos on mesh interfacesFelix Fietkau
When ieee80211_select_queue is called for mesh, the sta pointer is usually NULL, since the nexthop is looked up much later in the tx path. Explicitly check for unicast address in that case in order to make qos work again. Cc: stable@vger.kernel.org Fixes: 50e2ab392919 ("wifi: mac80211: fix queue selection for mesh/OCB interfaces") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230314095956.62085-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22drm/fbdev-generic: Rename symbolsThomas Zimmermann
Rename symbols to match the style of other fbdev-emulation source code. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-9-tzimmermann@suse.de
2023-03-22drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEMThomas Zimmermann
Consolidate all handling of CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM by making the module parameter optional in drm_fb_helper.c. Without the config option, modules can set smem_start in struct fb_info for internal usage, but not export if to userspace. The address can only be exported by enabling the option and setting the module parameter. Also update the comment. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng<suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-8-tzimmermann@suse.de
2023-03-22drm/fbdev-generic: Clean up after failed probingThomas Zimmermann
Clean up fbdev and client state if the probe function fails. It used to leak allocated resources. Also reorder the individual steps to simplify cleanup. v2: * move screen_size update into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-7-tzimmermann@suse.de
2023-03-22drm/fbdev-generic: Set screen size to size of GEM bufferThomas Zimmermann
The size of the screen memory should be equivalent to the size of the screen's GEM buffer. Don't recalculate the value. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-6-tzimmermann@suse.de
2023-03-22drm/fb-helper: Support smem_len in deferred I/OThomas Zimmermann
The size of the framebuffer can either be stored in screen_info or smem_len. Take both into account in the deferred I/O code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-5-tzimmermann@suse.de
2023-03-22drm/fb-helper: Export drm_fb_helper_release_info()Thomas Zimmermann
Export the fb_info release code as drm_fb_helper_release_info(). Will help with cleaning up failed fbdev probing. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng<suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-4-tzimmermann@suse.de
2023-03-22drm/fbdev-generic: Remove unused prefer_shadow_fbdev flagThomas Zimmermann
Remove the flag prefer_shadow_fbdev from struct drm_mode_config. Drivers set this flag to enable shadow buffering in the generic fbdev emulation. Such shadow buffering is now mandatory, so the flag is unused. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-3-tzimmermann@suse.de
2023-03-22drm/fbdev-generic: Always use shadow bufferingThomas Zimmermann
Remove all codepaths that implement fbdev output directly on GEM buffers. Always allocate a shadow buffer in system memory and set up deferred I/O for mmap. The fbdev code that operated directly on GEM buffers was used by drivers based on GEM DMA helpers. Those drivers have been migrated to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All remaining users of fbdev-generic require shadow buffering. Memory management of the remaining callers uses TTM, GEM SHMEM helpers or a variant of GEM DMA helpers that is incompatible with fbdev-dma. Therefore remove the unused codepaths from fbdev-generic and simplify the code. Using a shadow buffer with deferred I/O is probably the best case for most remaining callers. Some of the TTM-based drivers might benefit from a dedicated fbdev emulation that operates directly on the driver's video memory. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-2-tzimmermann@suse.de
2023-03-22wifi: iwlwifi: mvm: protect TXQ list manipulationJohannes Berg
Some recent upstream debugging uncovered the fact that in iwlwifi, the TXQ list manipulation is racy. Introduce a new state bit for when the TXQ is completely ready and can be used without locking, and if that's not set yet acquire the lock to check everything correctly. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22wifi: iwlwifi: mvm: fix mvmtxq->stopped handlingJohannes Berg
This could race if the queue is redirected while full, then the flushing internally would start it while it's not yet usable again. Fix it by using two state bits instead of just one. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMPGeert Uytterhoeven
sh/migor_defconfig: mm/slab.c: In function ‘slab_memory_callback’: mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration] 1127 | ret = init_cache_node_node(nid); | ^~~~~~~~~~~~~~~~~~~~ | drain_cache_node_node The #ifdef condition protecting the definition of init_cache_node_node() no longer matches the conditions protecting the (multiple) users. Fix this by syncing the conditions. Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef") Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/b5bdea22-ed2f-3187-6efe-0c72330270a4@infradead.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2023-03-22drm: bridge: simple-bridge: Use dev_err_probe()Ye Xingchen
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/202303221622511915615@zte.com.cn
2023-03-22drm/bridge: display-connector: Use dev_err_probe()Ye Xingchen
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/202303221621336645576@zte.com.cn
2023-03-22drm: remove drm_dev_set_uniqueChristian König
Not used by any drivers any more, the only use case in drm_dev_init() can be inlined now. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316082035.567520-2-christian.koenig@amd.com
2023-03-22nvme-tcp: fix nvme_tcp_term_pdu to match specCaleb Sander
The FEI field of C2HTermReq/H2CTermReq is 4 bytes but not 4-byte-aligned in the NVMe/TCP specification (it is located at offset 10 in the PDU). Split it into two 16-bit integers in struct nvme_tcp_term_pdu so no padding is inserted. There should also be 10 reserved bytes after. There are currently no users of this type. Fixes: fc221d05447aa6db ("nvme-tcp: Add protocol header") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Caleb Sander <csander@purestorage.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-03-22nvme: send Identify with CNS 06h only to I/O controllersMartin George
Identify CNS 06h (I/O Command Set Specific Identify Controller data structure) is supported only on i/o controllers. But nvme_init_non_mdts_limits() currently invokes this on all controllers. Correct this by ensuring this is sent to I/O controllers only. Signed-off-by: Martin George <marting@netapp.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-03-22drm/amd/amdgpu: limit one queue per gangJack Xiao
Limit one queue per gang in mes self test, due to mes schq fw change. Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-22drm/amd/pm: enable TEMP_DEPENDENT_VMIN for navi1xAlex Deucher
May help stability with some navi1x boards. Hopefully this helps with stability with multiple monitors and would allow us to re-enable MPC_SPLIT_DYNAMIC in the DC code for better power savings. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2196 Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
2023-03-22drm/amd/display: 3.2.228Aric Cyr
This DC version brings along: - Power down eDP if eDP not present - Set MPC_SPLIT_DYNAMIC for DCN10 and DCN301 - Initialize link_srv in virtual env - Code cleanup and alignment Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-14 04:21:38 +0000