Commits · steev/linux

The introduction of high resolution PWM support moved the parenthesis of the divisions in the calculation of min and max period. The result in both divisions is in most cases truncation to 0, which limits the period to the range of [0, 0]. Both numerators (and denominators) are within 64 bits, so the whole expression can be put directly into the div64_u64, instead of doing it partially. Fixes: b00d2ed ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230512165524.3367443-1-quic_bjorande@quicinc.com

The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230512150425.3171122-1-quic_bjorande@quicinc.com

The UEFI reset service hangs on reboot and power off on the CRD and X13s. Disable it so that we fall back to PSCI. This is needed until the boot firmware provides an RT_PROP table that describes the supported services. An alternative is to disable all runtime services by booting with 'efi=noruntime'. Not-signed-off-by: Johan Hovold <johan+linaro@kernel.org>

Keeping these enabled prevents the sc8280xp from booting. This is needed until the firmware has been fixed. An alternative is to boot with 'arm64.nopauth'. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [ johan: amend commit message with rationale and alternative ] Not-signed-off-by: Johan Hovold <johan+linaro@kernel.org>

Following the CRD, connect the two QMP phys inbetween the USB Type-C connectors and the DisplayPort controller, to handle orientation switching. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-9-quic_bjorande@quicinc.com

With support for the QMP combo phy to react to USB Type-C switch events, introduce it as the next hop for the SuperSpeed lanes of the two USB Type-C connectors, and connect the output of the DisplayPort controller to the QMP combo phy. This allows the TCPM to perform orientation switching of both USB and DisplayPort signals. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-8-quic_bjorande@quicinc.com

The QMP combo PHY sits in an of_graph connected between the DisplayPort controller and a USB Type-C connector (or possibly a redriver). The TCPM needs to be able to convey the HPD signal to the DisplayPort controller, but no directly link is provided by DeviceTree so the signal needs to "pass through" the QMP combo phy. Handle this by introducing a drm_bridge which upon initialization finds the next bridge (i.e. the usb-c-connector) and chain this together. This way HPD changes in the connector will propagate to the DisplayPort driver. The connector bridge is resolved lazily, as the TCPM is expected to be able to resolve the typec mux and switch at probe time, so the QMP combo phy will probe before the TCPM. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-7-quic_bjorande@quicinc.com

The data lanes of the QMP PHY is swapped in order to handle changing orientation of the USB Type-C cable. Register a typec_switch device to allow a TCPM to configure the orientation. The newly introduced orientation variable is adjusted based on the request, and the initialized components are brought down and up again. To keep track of what parts needs to be cycled new variables to keep track of the individual init_count is introduced. Both the USB and the DisplayPort altmode signals are properly switched. For DisplayPort the controller will after the TCPM having established orientation power on the PHY, so this is not done implicitly, but for USB the PHY typically is kept initialized across the switch, and must therefore then be reinitialized. This is based on initial work by Wesley Cheng. Link: https://lore.kernel.org/r/20201009082843.28503-3-wcheng@codeaurora.org/ Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-6-quic_bjorande@quicinc.com

In multiple places throughout the driver code has been written in prepration for handling of orientation switching. Introduce a typec_orientation in qmp_combo and fill out the various "placeholders" with the associated logic. By initializing the orientation to "normal" this change has no functional impact, but reduces the size of the upcoming introduction of dynamic orientation switching. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-5-quic_bjorande@quicinc.com

The phy core ensures mutual exclusion across the ops for a given phy, but the upcoming introduction of USB Type-C orientation switching might race with the DisplayPort phy operations. So extend the mutual exclusion to cover the remaining ops as well, to avoid concurrent reconfiguration of the hardware. Reported-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230510031930.1996020-4-quic_bjorande@quicinc.com

With the upcoming introduction of USB Type-C orientation switching the region of mutual exclusion needs to be extended to cover both the common init/exit as well as the individual functions. So move the phy_mutex one step up the stack. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Link: https://lore.kernel.org/r/20230510031930.1996020-3-quic_bjorande@quicinc.com

…n-switch The QMP combo phy can be connected to a TCPM, a USB controller and a DisplayPort controller for handling USB Type-C orientation switching and propagating HPD signals. Extend the binding to allow these connections to be described. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230510031930.1996020-2-quic_bjorande@quicinc.com

SoCs making use of Qcom PCIe controller IP v2.1.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-9-manivannan.sadhasivam@linaro.org

SoCs making use of Qcom PCIe controller IP v1.0.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-8-manivannan.sadhasivam@linaro.org

The post init sequence of IP v2.4.0 is same as v2.3.2. So let's reuse the v2.3.2 sequence which now also disables hotplug capability of the controller as it is not at all supported on any SoCs making use of this IP. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-7-manivannan.sadhasivam@linaro.org

SoCs making use of Qcom PCIe controller IP v2.3.2 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-6-manivannan.sadhasivam@linaro.org

SoCs making use of Qcom PCIe controller IPs v2.3.3 and v2.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's not set the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@gmail.com> Link: https://lore.kernel.org/r/20230506073139.8789-5-manivannan.sadhasivam@linaro.org

SoCs making use of Qcom PCIe controller IPs v2.7.0 and v1.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-4-manivannan.sadhasivam@linaro.org

In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. Fixes: 0cf7c2e ("PCI: qcom: Add IPQ60xx support") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@gmail.com> Link: https://lore.kernel.org/r/20230506073139.8789-3-manivannan.sadhasivam@linaro.org

DWC core already exposes dw_pcie_dbi_ro_wr_{en/dis} helper APIs for enabling and disabling the write access to read only DBI registers. So let's use them instead of doing it manually. Also, the existing code doesn't disable the write access when it's done. This is also fixed now. Fixes: 5d76117 ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230506073139.8789-2-manivannan.sadhasivam@linaro.org

The init counter is not decremented on initialisation errors, which prevents retrying initialisation. Add the missing decrement on initialisation errors so that the counter reflects the state of the device. Fixes: e78f3d1 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Cc: stable@vger.kernel.org # 4.12 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502103810.12061-3-johan+linaro@kernel.org

The init counter is not decremented on initialisation errors, which prevents retrying initialisation and can lead to the runtime suspend callback attempting to disable resources that have never been enabled. Add the missing decrement on initialisation errors so that the counter reflects the state of the device. Fixes: e78f3d1 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Cc: stable@vger.kernel.org # 4.12 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502103810.12061-2-johan+linaro@kernel.org

For errors after msm_submitqueue_get(), we need to drop the submitqueue reference. Additionally after get_unused_fd() we need to drop the fd. The ordering for dropping the queue lock and put_unused_fd() is not important, so just move this all into out_post_unlock. v2: Only drop queue ref if submit doesn't take it Reported-by: pinkperfect2021@gmail.com Fixes: f0de40a drm/msm: ("Reorder lock vs submit alloc") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230501181327.1618596-1-robdclark@gmail.com

Allow EFI systems to override the set of supported runtime services declared via the RT_PROP table, by checking for the existence of a 'OverrideSupported' EFI variable of the appropriate size under the RT_PROP table GUID, and if it does, combine the supported mask using logical AND. (This means the override can only remove support, not add it back). Cc: Jeffrey Hugo <jhugo@codeaurora.org>, Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

while binding the code always registers a audio driver, however there is no corresponding unregistration done in unbind. This leads to multiple redundant audio platform devices if dp_display_bind and dp_display_unbind happens multiple times during startup. On X13s platform this resulted in 6 to 9 audio codec device instead of just 3 codec devices for 3 dp ports. Fix this by unregistering codecs on unbind. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230421145657.12186-1-srinivas.kandagatla@linaro.org

Fedora, the one true distro, relies on this, else NTP (chronyd) fails to work. Let us not upset the true distro. Enable it. Signed-off-by: Andrew Halaney <ahalaney@redhat.com>

…ECAPP The config got dropped out when updating the defconfig in the prior commit due to it being renamed. Let's enable this again! Signed-off-by: Andrew Halaney <ahalaney@redhat.com>

Patchsets change, options change, and so do configs! Before adding things to enable in the current tree, let's update the defconfig to avoid churn in later patches: [root@halaney-x13s linux]# make laptop_defconfig [root@halaney-x13s linux]# make savedefconfig [root@halaney-x13s linux]# cp defconfig arch/arm64/configs/laptop_defconfig cp: overwrite 'arch/arm64/configs/laptop_defconfig'? y Signed-off-by: Andrew Halaney <ahalaney@redhat.com>

For a similar reason as commit f2c7ca8 ("drm/atomic-helper: Don't set deadline for modesets"), we need the crtc to be already active in order to compute a target vblank time for an async commit. Otherwise we get this splat reminding us that we are doing it wrong: ------------[ cut here ]------------ msm_dpu ae01000.mdp: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) WARNING: CPU: 7 PID: 1923 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370 Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc cros_ec_typec typec qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 xt_cgroup qcom_vadc_common qcom_stats hci_uart btqca xt_MASQUERADE venus_core 8021q coresight_tmc coresight_funnel coresight_etm4x coresight_replicator snd_soc_lpass_sc7180 coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cfg80211 cros_ec_sensors cros_ec_sensors_core ecdh_generic industrialio_triggered_buffer ecc kfifo_buf cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii lzo_rle lzo_compress zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev CPU: 7 PID: 1923 Comm: DrmThread Not tainted 5.15.107-18853-g3be267609a0b-dirty torvalds#16 a1ffc1a66e79c21c3536d8c9a42e819236e39714 Hardware name: Google Wormdingler rev1+ BOE panel board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370 lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x144/0x370 sp : ffffffc012e2b800 x29: ffffffc012e2b840 x28: ffffff8083676094 x27: ffffffc012e2bb28 x26: ffffff8084539800 x25: 0000000000000000 x24: ffffff8083676000 x23: ffffffd3c8cdc5a0 x22: ffffff80845b9d00 x21: ffffffc012e2b8b4 x20: ffffffc012e2b910 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000010 x15: ffffffd3c8451a88 x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 x11: c0000000ffffdfff x10: ffffffd3c973ef58 x9 : 8ea3526b3cc95900 x8 : 8ea3526b3cc95900 x7 : 0000000000000000 x6 : 000000000000003a x5 : ffffffd3c99676cd x4 : 0000000000000000 x3 : ffffffc012e2b4b8 x2 : ffffffc012e2b4c0 x1 : 00000000ffffdfff x0 : 0000000000000000 Call trace: drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370 drm_crtc_vblank_helper_get_vblank_timestamp+0x20/0x30 drm_crtc_get_last_vbltimestamp+0x68/0xb0 drm_crtc_next_vblank_start+0x5c/0xa8 msm_atomic_commit_tail+0x264/0x664 commit_tail+0xac/0x160 drm_atomic_helper_commit+0x160/0x168 drm_atomic_commit+0xfc/0x128 drm_atomic_helper_disable_plane+0x8c/0x110 __setplane_atomic+0x10c/0x138 drm_mode_cursor_common+0x3a8/0x410 drm_mode_cursor_ioctl+0x48/0x70 drm_ioctl_kernel+0xe0/0x158 drm_ioctl+0x25c/0x4d8 __arm64_sys_ioctl+0x98/0xd0 invoke_syscall+0x4c/0x100 el0_svc_common+0x98/0x104 do_el0_svc+0x30/0x90 el0_svc+0x20/0x50 el0t_64_sync_handler+0x78/0x108 el0t_64_sync+0x1a4/0x1a8 ---[ end trace a0f587e1ab9589e8 ]--- Fixes: 52ff0d3 ("drm/msm/atomic: Switch to vblank_start helper") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230418164158.549873-1-robdclark@gmail.com

GIC child node is supposed to be named msi-controller: sa8295p-adp.dtb: interrupt-controller@17a00000: gic-its@17a40000: False schema does not allow Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416151311.346596-4-krzysztof.kozlowski@linaro.org

Qualcomm PCI express root complex does not use snps,dw-pcie fallback: ['qcom,pcie-sm8150', 'snps,dw-pcie'] is too long Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416151311.346596-3-krzysztof.kozlowski@linaro.org

Since commit 6c84bbd ("dt-bindings: arm-smmu: Add generic qcom,smmu-500 bindings") the SMMU is supposed to use qcom,smmu-500 compatible fallback: ['qcom,sm8150-smmu-500', 'qcom,adreno-smmu', 'qcom,smmu-500', 'arm,mmu-500'] is too long Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416151311.346596-2-krzysztof.kozlowski@linaro.org

Add required cache-unified properties to fix warnings like: qcom-ipq4019-ap.dk01.1-c1.dtb: l2-cache: 'cache-unified' is a required property Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416101134.95686-4-krzysztof.kozlowski@linaro.org

Add required cache-level and cache-unified properties to fix warnings like: qdu1000-idp.dtb: l3-cache: 'cache-unified' is a required property qdu1000-idp.dtb: l2-cache: 'cache-level' is a required property Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416101134.95686-3-krzysztof.kozlowski@linaro.org

Cache level is by convention a decimal number, not hex. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230416101134.95686-2-krzysztof.kozlowski@linaro.org

Commits on May 12, 2023