- 04 Jul, 2022 14 commits
-
-
Dmitry Baryshkov authored
There might be a chain of bridges attached to the HDMI node (including but not limited to the display-connector bridge). Add support for attaching them right to the HDMI bridge chain. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/489709/ Link: https://lore.kernel.org/r/20220616085057.432353-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Drop empty callbacks msm_hdmi_bridge_enable() and msm_hdmi_bridge_disable(). Signed-off-by:
-
Dmitry Baryshkov authored
Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface clock (this is the same config as is used by the 8960). Reviewed-by:
-
Dmitry Baryshkov authored
MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse MSM8960's config for the MSM8660 (8x60). Reviewed-by:
-
Dmitry Baryshkov authored
Since there is no more difference between the HDMI platform data between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a single entry. Reviewed-by:
-
Dmitry Baryshkov authored
The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply regulators that are to be enabled for HPD to work. Currently these regulators contain the hpd_gdsc, which was replaced by the power-domains support and hpd-5v/hpd-5v-en, which are not used by the chip itself. They power up the ESD bridge. However it is a separate device which should be represented separately in the device tree. None of upstreamed devices support these properties. Thus drop support for them from the HDMI driver. Reviewed-by:
-
Dmitry Baryshkov authored
Several platform configs use empty 'none' regulator arrays. They are not necessary, as the code will use corresponding _cnt field and skip the array completely. Drop them now. Reviewed-by:
-
Dmitry Baryshkov authored
DB820c makes use of core-vcc-supply and core-vdda-supply, however the driver code doesn't support these regulators. Enable them for HDMI on 8996 platform. Fixes: 0afbe59e ("drm/msm/hdmi: Add basic HDMI support for msm8996") Signed-off-by:
-
Dmitry Baryshkov authored
The HDMI driver has code to configure extra GPIOs, which predates pinctrl support. Nowadays all platforms should use pinctrl instead. Neither of upstreamed Qualcomm platforms uses these properties, so it's safe to drop them. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Dmitry Baryshkov authored
With the last (and only) in-kernel user of hdmi-mux regulator, drop it from the HDMI driver. Reviewed-by:
-
Dmitry Baryshkov authored
hdmi-mux-supply is not used by the SoC's HDMI block, it is thought to power up the external logic. Thus it should not be a part of HDMI bindings, but it should be declared at some other device in the DT (like HDMI mux, bridge, etc). Mark it as deprecated. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
Mark obsolete GPIO properties as deprecated. They are not used by existing device trees. While we are at it, also drop them from the schema example. Reviewed-by:
-
Dmitry Baryshkov authored
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings. Changes to schema: HDMI: - fixed reg-names numbering to match 0..3 instead 0,1,3,4 - dropped qcom,tx-ddc-* from example, they were not documented - make phy-names deprecated, drop it from the examples PHY: - moved into phy/ directory - split into QMP and non-QMP PHY schemas Co-developed-by:
David Heidelberg <david@ixit.cz> Signed-off-by:
-
Dmitry Baryshkov authored
Conversion to use bulk regulator API omitted filling the pwr_regs with proper regulator IDs. This was left unnoticed, since none of my testing platforms has used the pwr_regs. Fix this by propagating regulator ids properly. Fixes: 31b3b1f5 ("drm/msm/hdmi: use bulk regulator API") Signed-off-by:
-
- 28 Jun, 2022 1 commit
-
-
Rob Clark authored
Merge v5.19 fixes to avoid merge conflicts Signed-off-by:Rob Clark <robdclark@chromium.org>
-
- 27 Jun, 2022 1 commit
-
-
Rob Clark authored
This was a typo, we didn't actually want to return zero. Fixes: a61acbbe ("drm/msm: Track "seqno" fences by idr") Signed-off-by:
-
- 23 Jun, 2022 3 commits
-
-
sunliming authored
Fixes the following smatch warning: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:261 dpu_encoder_phys_wb_atomic_check() warn: variable dereferenced before check 'conn_state' Fixes: d7d0e73f ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by:
sunliming <sunliming@kylinos.cn> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/490850/ Link: https://lore.kernel.org/r/20220623012707.453972-1-sunliming@kylinos.cnSigned-off-by:
-
Kuogee Hsieh authored
During msm initialize phase, dp_display_unbind() will be called to undo initializations had been done by dp_display_bind() previously if there is error happen at msm_drm_bind. Under this kind of circumstance, drm_device may not be populated completed which causes system crash at drm_dev_dbg(). This patch reset drm_dev to NULL so that following drm_dev_dbg() will not refer to any internal fields of drm_device to prevent system from crashing. Below are panic stack trace, [ 53.584904] Unable to handle kernel paging request at virtual address 0000000070018001 . [ 53.702212] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT) [ 53.710445] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 53.717596] pc : string_nocheck+0x1c/0x64 [ 53.721738] lr : string+0x54/0x60 [ 53.725162] sp : ffffffc013d6b650 [ 53.728590] pmr_save: 000000e0 [ 53.731743] x29: ffffffc013d6b650 x28: 0000000000000002 x27: 0000000000ffffff [ 53.739083] x26: ffffffc013d6b710 x25: ffffffd07a066ae0 x24: ffffffd07a419f97 [ 53.746420] x23: ffffffd07a419f99 x22: ffffff81fef360d4 x21: ffffff81fef364d4 [ 53.753760] x20: ffffffc013d6b6f8 x19: ffffffd07a06683c x18: 0000000000000000 [ 53.761093] x17: 4020386678302f30 x16: 00000000000000b0 x15: ffffffd0797523c8 [ 53.768429] x14: 0000000000000004 x13: ffff0000ffffff00 x12: ffffffd07a066b2c [ 53.775780] x11: 0000000000000000 x10: 000000000000013c x9 : 0000000000000000 [ 53.783117] x8 : ffffff81fef364d4 x7 : 0000000000000000 x6 : 0000000000000000 [ 53.790445] x5 : 0000000000000000 x4 : ffff0a00ffffff04 x3 : ffff0a00ffffff04 [ 53.797783] x2 : 0000000070018001 x1 : ffffffffffffffff x0 : ffffff81fef360d4 [ 53.805136] Call trace: [ 53.807667] string_nocheck+0x1c/0x64 [ 53.811439] string+0x54/0x60 [ 53.814498] vsnprintf+0x374/0x53c [ 53.818009] pointer+0x3dc/0x40c [ 53.821340] vsnprintf+0x398/0x53c [ 53.824854] vscnprintf+0x3c/0x88 [ 53.828274] __trace_array_vprintk+0xcc/0x2d4 [ 53.832768] trace_array_printk+0x8c/0xb4 [ 53.836900] drm_trace_printf+0x74/0x9c [ 53.840875] drm_dev_dbg+0xfc/0x1b8 [ 53.844480] dp_pm_suspend+0x70/0xf8 [ 53.848164] dpm_run_callback+0x60/0x1a0 [ 53.852222] __device_suspend+0x304/0x3f4 [ 53.856363] dpm_suspend+0xf8/0x3a8 [ 53.859959] dpm_suspend_start+0x8c/0xc0 Fixes: 570d3e5d ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Stephen Boyd authored
The 'vsync_cnt' is used to count the number of frames for a crtc. Unfortunately, we increment the count after waking up userspace via dpu_crtc_vblank_callback() calling drm_crtc_handle_vblank(). drm_crtc_handle_vblank() wakes up userspace processes that have called drm_wait_vblank_ioctl(), and if that ioctl is expecting the count to increase it won't. Increment the count before calling into the drm APIs so that we don't have to worry about ordering the increment with anything else in drm. This fixes a software video decode test that fails to see frame counts increase on Trogdor boards. Cc: Mark Yacoub <markyacoub@chromium.org> Cc: Jessica Zhang <quic_jesszhan@quicinc.com> Fixes: 885455d6 ("drm/msm: Change dpu_crtc_get_vblank_counter to use vsync count.") Signed-off-by:
-
- 18 Jun, 2022 6 commits
-
-
Kuogee Hsieh authored
Display resolution change is implemented through drm modeset. Older modeset (resolution) has to be disabled first before newer modeset (resolution) can be enabled. Display disable will turn off both pixel clock and main link clock so that main link have to be re-trained during display enable to have new video stream flow again. At current implementation, display enable function manually kicks up irq_hpd_handle which will read panel link status and start link training if link status is not in sync state. However, there is rare case that a particular panel links status keep staying in sync for some period of time after main link had been shut down previously at display disabled. In this case, main link retraining will not be executed by irq_hdp_handle(). Hence video stream of newer display resolution will fail to be transmitted to panel due to main link is not in sync between host and panel. This patch will bypass irq_hpd_handle() in favor of directly call dp_ctrl_on_stream() to always perform link training in regardless of main link status. So that no unexpected exception resolution change failure cases will happen. Also this implementation are more efficient than manual kicking off irq_hpd_handle function. Changes in v2: -- set force_link_train flag on DP only (is_edp == false) Changes in v3: -- revise commit text -- add Fixes tag Changes in v4: -- revise commit text Changes in v5: -- fix spelling at commit text Changes in v6: -- split dp_ctrl_on_stream() for phy test case -- revise commit text for modeset Changes in v7: -- drop 0 assignment at local variable (ret = 0) Changes in v8: -- add patch to remove pixel_rate from dp_ctrl Changes in v9: -- forward declare dp_ctrl_on_stream_phy_test_report() Fixes: 62671d2e ("drm/msm/dp: fixes wrong connection state caused by failure of link train") Signed-off-by:
-
Abhinav Kumar authored
As explained in [1], using max_linewidth to limit the modes does not seem to remove 4K modes on chipsets such as sm8250 where the max_linewidth actually supports 4k. This would have been alright if dual SSPP support was present but otherwise fails the per SSPP bandwidth check. The ideal way to implement this would be to filter out the modes which will exceed the bandwidth check by computing it. But this would be an exhaustive solution till we have dual SSPP support. Let's instead use max_mixer_width to limit the modes. max_mixer_width still remains 2560 on sm8250 so even if the max_linewidth is 4096, the only way 4k modes could have been supported is to have source split enabled on the SSPP. Since source split support is not enabled yet in DPU driver, enforce max_mixer_width as the upper limit on the modes. [1] https://patchwork.freedesktop.org/patch/489662/ Fixes: e67dcecd ("drm/msm/dpu: limit writeback modes according to max_linewidth") Signed-off-by:
-
Kuogee Hsieh authored
During msm initialize phase, dp_display_unbind() will be called to undo initializations had been done by dp_display_bind() previously if there is error happen at msm_drm_bind. In this case, core_initialized flag had to be check to make sure clocks is on before update DP controller register to disable HPD interrupts. Otherwise system will crash due to below NOC fatal error. QTISECLIB [01f01a7ad]CNOC2 ERROR: ERRLOG0_LOW = 0x00061007 QTISECLIB [01f01a7ad]GEM_NOC ERROR: ERRLOG0_LOW = 0x00001007 QTISECLIB [01f0371a0]CNOC2 ERROR: ERRLOG0_HIGH = 0x00000003 QTISECLIB [01f055297]GEM_NOC ERROR: ERRLOG0_HIGH = 0x00000003 QTISECLIB [01f072beb]CNOC2 ERROR: ERRLOG1_LOW = 0x00000024 QTISECLIB [01f0914b8]GEM_NOC ERROR: ERRLOG1_LOW = 0x00000042 QTISECLIB [01f0ae639]CNOC2 ERROR: ERRLOG1_HIGH = 0x00004002 QTISECLIB [01f0cc73f]GEM_NOC ERROR: ERRLOG1_HIGH = 0x00004002 QTISECLIB [01f0ea092]CNOC2 ERROR: ERRLOG2_LOW = 0x0009020c QTISECLIB [01f10895f]GEM_NOC ERROR: ERRLOG2_LOW = 0x0ae9020c QTISECLIB [01f125ae1]CNOC2 ERROR: ERRLOG2_HIGH = 0x00000000 QTISECLIB [01f143be7]GEM_NOC ERROR: ERRLOG2_HIGH = 0x00000000 QTISECLIB [01f16153a]CNOC2 ERROR: ERRLOG3_LOW = 0x00000000 QTISECLIB [01f17fe07]GEM_NOC ERROR: ERRLOG3_LOW = 0x00000000 QTISECLIB [01f19cf89]CNOC2 ERROR: ERRLOG3_HIGH = 0x00000000 QTISECLIB [01f1bb08e]GEM_NOC ERROR: ERRLOG3_HIGH = 0x00000000 QTISECLIB [01f1d8a31]CNOC2 ERROR: SBM1 FAULTINSTATUS0_LOW = 0x00000002 QTISECLIB [01f1f72a4]GEM_NOC ERROR: SBM0 FAULTINSTATUS0_LOW = 0x00000001 QTISECLIB [01f21a217]CNOC3 ERROR: ERRLOG0_LOW = 0x00000006 QTISECLIB [01f23dfd3]NOC error fatal changes in v2: -- drop the first patch (drm/msm: enable msm irq after all initializations are done successfully at msm_drm_init()) since the problem had been fixed by other patch Fixes: 570d3e5d ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by:
-
Miaoqian Lin authored
of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 86418f90 ("drm: convert drivers to use of_graph_get_remote_node") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
-
Rob Clark authored
Prior to the last commit, this could result in setting the GPU written fence value back to an older value, if we had missed updating completed_fence prior to suspend. This was mostly harmless as the GPU would eventually overwrite it again with the correct value. But we should just not do this. Instead just leave a sanity check that the fence looks plausible (in case the GPU scribbled on memory). Reported-by:
Steev Klimaszewski <steev@kali.org> Fixes: 95d1deb0 ("drm/msm/gem: Add fenced vma unpin") Signed-off-by:
-
Rob Clark authored
I noticed while looking at some traces, that we could miss calls to msm_update_fence(), as the irq could have raced with retire_submits() which could have already popped the last submit on a ring out of the queue of in-flight submits. But walking the list of submits in the irq handler isn't really needed, as dma_fence_is_signaled() will dtrt. So lets just drop it entirely. v2: use spin_lock_irqsave/restore as we are no longer protected by the spin_lock_irqsave/restore() in update_fences() Reported-by:
-
- 15 Jun, 2022 2 commits
-
-
Rob Clark authored
Keep the warn, but drop the early return. If we do manage to hit this sort of issue, skipping the cleanup just makes things worse (dangling drm_mm_nodes when the msm_gem_vma is freed, etc). Whereas the worst that happens if we tear down a mapping the GPU is accessing is that we get GPU iova faults, but otherwise the world keeps spinning. Signed-off-by:
-
Rob Clark authored
Previously the BO_PINNED state in the submit was tracking two related but different things: (1) that the buffer object was pinned, and (2) that the vma (mapping within a set of pagetables) was pinned. But with fenced vma unpin (needed so that userspace couldn't race with retire path for releasing a vma) these two were decoupled. The fact that the BO_PINNED flag was already cleared meant that we leaked the bo pin count which should have been dropped when the submit was retired. So split this state into BO_OBJ_PINNED and BO_VMA_PINNED, so they can be dropped independently. Fixes: 95d1deb0 ("drm/msm/gem: Add fenced vma unpin") Signed-off-by:
-
- 14 Jun, 2022 1 commit
-
-
Jonathan Marek authored
The dma_map_sgtable() call (used to invalidate cache) overwrites sgt->nents with 1, so msm_iommu_pagetable_map maps only the first physical segment. To fix this problem use for_each_sgtable_sg(), which uses orig_nents. Fixes: b145c6e6 ("drm/msm: Add support to create a local pagetable") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Link: https://lore.kernel.org/r/20220613221019.11399-1-jonathan@marek.caSigned-off-by:
-
- 13 Jun, 2022 1 commit
-
-
Rob Clark authored
In msm_devfreq_suspend() we cancel idle_work synchronously so that it doesn't run after we power of the hw or in the resume path. But this means that we want to ensure that idle_work is not scheduled *after* we no longer hold a runpm ref. So switch the ordering of pm_runtime_put() vs msm_devfreq_idle(). v2. Only move the runpm _put_autosuspend, and not the _mark_last_busy() Fixes: 9bc95570 ("drm/msm: Devfreq tuning") Signed-off-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220608161334.2140611-1-robdclark@gmail.comSigned-off-by:
-
- 12 Jun, 2022 10 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'platform-drivers-x86-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: "Highlights: - Fix hp-wmi regression on HP Omen laptops introduced in 5.18 - Several hardware-id additions - A couple of other tiny fixes" * tag 'platform-drivers-x86-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86/intel: hid: Add Surface Go to VGBS allow list platform/x86: hp-wmi: Use zero insize parameter only when supported platform/x86: hp-wmi: Resolve WMI query failures on some devices platform/x86: gigabyte-wmi: Add support for B450M DS3H-CF platform/x86: gigabyte-wmi: Add Z690M AORUS ELITE AX DDR4 support platform/x86: barco-p50-gpio: Add check for platform_driver_register platform/x86/intel: pmc: Support Intel Raptorlake P platform/x86/intel: Fix pmt_crashlog array reference platform/mellanox: Add static in struct declaration. platform/mellanox: Spelling s/platfom/platform/
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds authored
Pull workqueue fixes from Tejun Heo: "Tetsuo's patch to trigger build warnings if system-wide wq's are flushed along with a TP type update and trivial comment update" * tag 'wq-for-5.19-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Switch to new kerneldoc syntax for named variable macro argument workqueue: Fix type of cpu in trace event workqueue: Wrap flush_workqueue() using a macro
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Make the *.mod build rule portable for POSIX awk - Fix regression of 'make nsdeps' - Make scripts/check-local-export working for older bash versions - Fix scripts/gdb to extract the .config data from vmlinux * tag 'kbuild-fixes-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: scripts/gdb: change kernel config dumping method scripts/check-local-export: avoid 'wait $!' for process substitution scripts/nsdeps: adjust to the format change of *.mod files kbuild: avoid regex RS for POSIX awk
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs client fixes from Steve French: "Three reconnect fixes, all for stable as well. One of these three reconnect fixes does address a problem with multichannel reconnect, but this does not include the additional fix (still being tested) for dynamically detecting multichannel adapter changes which will improve those reconnect scenarios even more" * tag '5.19-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: populate empty hostnames for extra channels cifs: return errors during session setup during reconnects cifs: fix reconnect on smb3 mount types
-
git://git.kernel.org/pub/scm/linux/kernel/git/crng/randomLinus Torvalds authored
Pull random number generator fixes from Jason Donenfeld: - A fix for a 5.19 regression for a case in which early device tree initializes the RNG, which flips a static branch. On most plaforms, jump labels aren't initialized until much later, so this caused splats. On a few mailing list threads, we cooked up easy fixes for arm64, arm32, and risc-v. But then things looked slightly more involved for xtensa, powerpc, arc, and mips. And at that point, when we're patching 7 architectures in a place before the console is even available, it seems like the cost/risk just wasn't worth it. So random.c works around it now by checking the already exported `static_key_initialized` boolean, as though somebody already ran into this issue in the past. I'm not super jazzed about that; it'd be prettier to not have to complicate downstream code. But I suppose it's practical. - A few small code nits and adding a missing __init annotation. - A change to the default config values to use the cpu and bootloader's seeds for initializing the RNG earlier. This brings them into line with what all the distros do (Fedora/RHEL, Debian, Ubuntu, Gentoo, Arch, NixOS, Alpine, SUSE, and Void... at least), and moreover will now give us test coverage in various test beds that might have caught the above device tree bug earlier. - A change to WireGuard CI's configuration to increase test coverage around the RNG. - A documentation comment fix to unrelated maintainerless CRC code that I was asked to take, I guess because it has to do with polynomials (which the RNG thankfully no longer uses). * tag 'random-5.19-rc2-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: wireguard: selftests: use maximum cpu features and allow rng seeding random: remove rng_has_arch_random() random: credit cpu and bootloader seeds by default random: do not use jump labels before they are initialized random: account for arch randomness in bits random: mark bootloader randomness code as __init random: avoid checking crng_ready() twice in random_init() crc-itu-t: fix typo in CRC ITU-T polynomial comment
-
Duke Lee authored
The Surface Go reports Chassis Type 9 (Laptop,) so the device needs to be added to dmi_vgbs_allow_list to enable tablet mode when an attached Type Cover is folded back. BugLink: https://github.com/linux-surface/linux-surface/issues/837Signed-off-by:
Duke Lee <krnhotwings@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220607213654.5567-1-krnhotwings@gmail.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Bedant Patnaik authored
commit be9d73e6 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls") and commit 12b19f14 ("platform/x86: hp-wmi: Fix hp_wmi_read_int() reporting error (0x05)") cause ACPI BIOS Error (bug): Attempt to CreateField of length zero (20211217/dsopcode-133) because of the ACPI method HWMC, which unconditionally creates a Field of size (insize*8) bits: CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN) In cases where args->insize = 0, the Field size is 0, resulting in an error. Fix this by using zero insize only if 0x5 error code is returned Tested on Omen 15 AMD (2020) board ID: 8786. Fixes: be9d73e6 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls") Signed-off-by:
Bedant Patnaik <bedant.patnaik@gmail.com> Tested-by:
Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/41be46743d21c78741232a47bbb5f1cdbcc3d21e.camel@gmail.comReviewed-by:
-
Jorge Lopez authored
WMI queries fail on some devices where the ACPI method HWMC unconditionally attempts to create Fields beyond the buffer if the buffer is too small, this breaks essential features such as power profiles: CreateByteField (Arg1, 0x10, D008) CreateByteField (Arg1, 0x11, D009) CreateByteField (Arg1, 0x12, D010) CreateDWordField (Arg1, 0x10, D032) CreateField (Arg1, 0x80, 0x0400, D128) In cases where args->data had zero length, ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D008] at bit offset/length 128/8 exceeds size of target Buffer (128 bits) (20211217/dsopcode-198) was obtained. ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D009] at bit offset/length 136/8 exceeds size of target Buffer (136bits) (20211217/dsopcode-198) The original code created a buffer size of 128 bytes regardless if the WMI call required a smaller buffer or not. This particular behavior occurs in older BIOS and reproduced in OMEN laptops. Newer BIOS handles buffer sizes properly and meets the latest specification requirements. This is the reason why testing with a dynamically allocated buffer did not uncover any failures with the test systems at hand. This patch was tested on several OMEN, Elite, and Zbooks. It was confirmed the patch resolves HPWMI_FAN GET/SET calls in an OMEN Laptop 15-ek0xxx. No problems were reported when testing on several Elite and Zbooks notebooks. Fixes: 4b4967cb ("platform/x86: hp-wmi: Changing bios_args.data to be dynamically allocated") Signed-off-by: -
Jonathan Neuschäfer authored
The syntax without dots is available since commit 43756e34 ("scripts/kernel-doc: Add support for named variable macro arguments"). The same HTML output is produced with and without this patch. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
- 11 Jun, 2022 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linuxLinus Torvalds authored
Pull gpio fixes from Bartosz Golaszewski: "A set of fixes. Most address the new warning we emit at build time when irq chips are not immutable with some additional tweaks to gpio-crystalcove from Andy and a small tweak to gpio-dwapd. - make irq_chip structs immutable in several Diolan and intel drivers to get rid of the new warning we emit when fiddling with irq chips - don't print error messages on probe deferral in gpio-dwapb" * tag 'gpio-fixes-for-v5.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: dwapb: Don't print error on -EPROBE_DEFER gpio: dln2: make irq_chip immutable gpio: sch: make irq_chip immutable gpio: merrifield: make irq_chip immutable gpio: wcove: make irq_chip immutable gpio: crystalcove: Join function declarations and long lines gpio: crystalcove: Use specific type and API for IRQ number gpio: crystalcove: make irq_chip immutable
-
