summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-09arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max ↵Darren Hart
machines Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra family via the family field in the type#1 SMBIOS record. eMAG and Altra Max machines are similarly affected but not detected with the strict strcmp test. The type1_family smbios string is not an entirely reliable means of identifying systems with this issue as OEMs can, and do, use their own strings for these fields. However, until we have a better solution, capture the bulk of these systems by adding strcmp matching for "eMAG" and "Altra Max". Fixes: 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") Cc: <stable@vger.kernel.org> # 6.1.x Cc: Alexandru Elisei <alexandru.elisei@gmail.com> Signed-off-by: Darren Hart <darren@os.amperecomputing.com> Tested-by: Justin He <justin.he@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-02-09ARM: dts: s5pv210: add "gpios" suffix to wlf,ldo1ena on AriesKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. Link: https://lore.kernel.org/r/20230208172634.404452-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: add "gpios" suffix to wlf,ldo1ena on ArndaleKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. Link: https://lore.kernel.org/r/20230208172634.404452-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: add "gpios" suffix to wlf,ldo1ena on MidasKrzysztof Kozlowski
The GPIOs properties should end with "gpios" suffix and Linux gpiolib already handles both names, so switch to preferred one. While touching the lines, replace open-coded GPIO_ACTIVE_HIGH flag. Tested-by: Henrik Grimler <henrik@grimler.se> Link: https://lore.kernel.org/r/20230208172634.404452-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: correct SPI nor compatible in SMDK5250Krzysztof Kozlowski
SPI NOR flash compatible should come with generic jedec,spi-nor fallback and proper vendor prefix: exynos5250-smdk5250.dtb: /soc/spi@12d30000/flash@0: failed to match any schema with compatible: ['w25x80'] Link: https://lore.kernel.org/r/20230208164942.387390-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: correct SPI nor compatible in SMDKv310Krzysztof Kozlowski
SPI NOR flash compatible should come with generic jedec,spi-nor fallback and proper vendor prefix: exynos4210-smdkv310.dtb: /soc/spi@13940000/flash@0: failed to match any schema with compatible: ['w25x80'] Link: https://lore.kernel.org/r/20230208164942.387390-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: move I2C10 out of soc node on ArndaleKrzysztof Kozlowski
I2C10 is represented as i2c-gpio device, thus it is not really a part of soc MMIO bus: exynos5250-arndale.dtb: soc: i2c-10: {'pinctrl-names': ['default'], ... } should not be valid under {'type': 'object'} Link: https://lore.kernel.org/r/20230207210020.677007-7-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: drop redundant address/size cells from I2C10 on ArndaleKrzysztof Kozlowski
I2C10 does not have any children because it is used in HDMI DDC, so drop redundant address/size-cells. Link: https://lore.kernel.org/r/20230207210020.677007-6-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: drop default status from I2C10 on ArndaleKrzysztof Kozlowski
status=okay is by default for new nodes. Link: https://lore.kernel.org/r/20230207210020.677007-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09ARM: dts: exynos: align status led name with bindings on Origen4210Krzysztof Kozlowski
The "status" is a reserved keyword and LED nodes should have generic prefix: exynos4210-origen.dtb: leds: status: {'gpios': [[76, 3, 1]], 'function': ['heartbeat'], 'linux,default-trigger': ['heartbeat']} is not of type 'array' Link: https://lore.kernel.org/r/20230207210020.677007-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-02-09EDAC/amd64: Remove PCI Function 6Yazen Ghannam
PCI Function 6 is used on Family 17h and later to access scrub registers. With scrub access removed, this function has no other use. Remove all Function 6 PCI IDs and related code. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-4-yazen.ghannam@amd.com
2023-02-09EDAC/amd64: Remove scrub rate control for Family 17h and laterYazen Ghannam
The scrub registers on AMD Family 17h and later may be inaccessible to the OS. Furthermore, hardware designers recommend that the scrubbing feature is managed by the firmware. Remove support for the sdram_scrub_rate interface for AMD Family 17h systems and later by not setting the scrub function pointers. The EDAC MC core will then not expose the scrub files in sysfs. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-3-yazen.ghannam@amd.com
2023-02-09EDAC/amd64: Don't set up EDAC PCI control on Family 17h+Yazen Ghannam
EDAC PCI control is used to detect/report legacy PCI errors like "Parity" and "SERROR". Modern AMD systems use PCIe Advanced Error Reporting (AER), and legacy PCI errors should not be reported. Remove EDAC PCI control setup on AMD Family 17h and later systems. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230127170419.1824692-2-yazen.ghannam@amd.com
2023-02-09selftests: forwarding: lib: quote the sysctl valuesHangbin Liu
When set/restore sysctl value, we should quote the value as some keys may have multi values, e.g. net.ipv4.ping_group_range Fixes: f5ae57784ba8 ("selftests: forwarding: lib: Add sysctl_set(), sysctl_restore()") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20230208032110.879205-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09net: mscc: ocelot: fix all IPv6 getting trapped to CPU when PTP timestamping ↵Vladimir Oltean
is used While running this selftest which usually passes: ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] if I start PTP timestamping then run it again (debug prints added by me), the unknown IPv6 MC traffic is seen by the CPU port even when it should have been dropped: ~/selftests/drivers/net/dsa# ptp4l -i swp0 -2 -P -m ptp4l[225.410]: selected /dev/ptp1 as PTP clock [ 225.445746] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_add: port 0 adding L2 PTP trap [ 225.453815] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP event trap [ 225.462703] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP general trap [ 225.471768] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP event trap [ 225.480651] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP general trap ptp4l[225.488]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[225.488]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ^C ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [FAIL] reception succeeded, but should have failed TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] The PGID_MCIPV6 is configured correctly to not flood to the CPU, I checked that. Furthermore, when I disable back PTP RX timestamping (ptp4l doesn't do that when it exists), packets are RX filtered again as they should be: ~/selftests/drivers/net/dsa# hwstamp_ctl -i swp0 -r 0 [ 218.202854] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_del: port 0 removing L2 PTP trap [ 218.212656] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP event trap [ 218.222975] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP general trap [ 218.233133] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP event trap [ 218.242251] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP general trap current settings: tx_type 1 rx_filter 12 new settings: tx_type 1 rx_filter 0 ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] So it's clear that something in the PTP RX trapping logic went wrong. Looking a bit at the code, I can see that there are 4 typos, which populate "ipv4" VCAP IS2 key filter fields for IPv6 keys. VCAP IS2 keys of type OCELOT_VCAP_KEY_IPV4 and OCELOT_VCAP_KEY_IPV6 are handled by is2_entry_set(). OCELOT_VCAP_KEY_IPV4 looks at &filter->key.ipv4, and OCELOT_VCAP_KEY_IPV6 at &filter->key.ipv6. Simply put, when we populate the wrong key field, &filter->key.ipv6 fields "proto.mask" and "proto.value" remain all zeroes (or "don't care"). So is2_entry_set() will enter the "else" of this "if" condition: if (msk == 0xff && (val == IPPROTO_TCP || val == IPPROTO_UDP)) and proceed to ignore the "proto" field. The resulting rule will match on all IPv6 traffic, trapping it to the CPU. This is the reason why the local_termination.sh selftest sees it, because control traps are stronger than the PGID_MCIPV6 used for flooding (from the forwarding data path). But the problem is in fact much deeper. We trap all IPv6 traffic to the CPU, but if we're bridged, we set skb->offload_fwd_mark = 1, so software forwarding will not take place and IPv6 traffic will never reach its destination. The fix is simple - correct the typos. I was intentionally inaccurate in the commit message about the breakage occurring when any PTP timestamping is enabled. In fact it only happens when L4 timestamping is requested (HWTSTAMP_FILTER_PTP_V2_EVENT or HWTSTAMP_FILTER_PTP_V2_L4_EVENT). But ptp4l requests a larger RX timestamping filter than it needs for "-2": HWTSTAMP_FILTER_PTP_V2_EVENT. I wanted people skimming through git logs to not think that the bug doesn't affect them because they only use ptp4l in L2 mode. Fixes: 96ca08c05838 ("net: mscc: ocelot: set up traps for PTP packets") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230207183117.1745754-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09rds: rds_rm_zerocopy_callback() use list_first_entry()Pietro Borrello
rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Use list_first_entry() to actually access the first element of the rs_zcookie_queue list. Fixes: 9426bbc6de99 ("rds: use list structure to track information for zerocopy completion notification") Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Link: https://lore.kernel.org/r/20230202-rds-zerocopy-v3-1-83b0df974f9a@diag.uniroma1.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-09udf: Avoid directory type conversion failure due to ENOMEMJan Kara
When converting directory from in-ICB to normal format, the last iteration through the directory fixing up directory enteries can fail due to ENOMEM. We do not expect this iteration to fail since the directory is already verified to be correct and it is difficult to undo the conversion at this point. So just use GFP_NOFAIL to make sure the small allocation cannot fail. Reported-by: syzbot+111eaa994ff74f8d440f@syzkaller.appspotmail.com Fixes: 0aba4860b0d0 ("udf: Allocate name buffer in directory iterator on heap") Signed-off-by: Jan Kara <jack@suse.cz>
2023-02-09drm/vc4: crtc: Increase setup cost in core clock calculation to handle ↵Dom Cobley
extreme reduced blanking The formula that determines the core clock requirement based on pixel clock and blanking has been determined experimentally to minimise the clock while supporting all modes we've seen. A new reduced blanking mode (4kp60 at 533MHz rather than the standard 594MHz) has been seen that doesn't produce a high enough clock and results in "flip_done timed out" error. Increase the setup cost in the formula to make this work. The result is a reduced blanking mode increases by up to 7MHz while leaving the standard timing mode untouched Link: https://github.com/raspberrypi/linux/issues/4446 Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127145558.446123-1-maxime@cerno.tech
2023-02-09drm/vc4: hdmi: Always enable GCP with AVMUTE clearedDom Cobley
Issue is some displays go blank at the point of firmware to kms handover. Plugging/unplugging hdmi cable, power cycling display, or switching standby off/on typically resolve this case. Finally managed to find a display that suffers from this, and track down the issue. The firmware uses AVMUTE in normal operation. It will set AVMUTE before disabling hdmi clocks and phy. It will clear AVMUTE after clocks and phy are set up for a new hdmi mode. But with the hdmi handover from firmware to kms, AVMUTE will be set by firmware. kms driver typically has no GCP packet (except for deep colour modes). The spec isn't clear on whether to consider the AVMUTE as continuing indefinitely in the absence of a GCP packet, or to consider that state to have ended. Most displays behave as we want, but there are a number (from multiple manufacturers) which need to see AVMUTE cleared before displaying a picture. Lets just always enable GCP packet with AVMUTE cleared. That resolves the issue on problematic displays. From HDMI 1.4 spec: A CD field of zero (Color Depth not indicated) shall be used whenever the Sink does not indicate support for Deep Color. This value may also be used in Deep Color mode to transmit a GCP indicating only non-Deep Color information (e.g. AVMUTE). So use CD=0 where we were previously not enabling a GCP. Link: https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0 Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127161219.457058-1-maxime@cerno.tech
2023-02-09drm/vc4: Fix YUV plane handling when planes are in different buffersDave Stevenson
YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxime@cerno.tech
2023-02-09Merge tag 'amd-drm-fixes-6.2-2023-02-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.2-2023-02-08: amdgpu: - Flickering fixes for DCN 2.1, 3.1.2/3 - Re-enable S/G display on DCN 3.1.4 - Properly fix S/G display with AGP aperture enabled - Fix cursor offset with 180 rotation - SMU13 fixes - Use TGID for GPUVM traces - Fix oops on in fence error path - Don't run IB tests on hw rings when sw rings are in use Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209045321.565132-1-alexander.deucher@amd.com
2023-02-08Merge tag 'ipsec-2023-02-08' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== ipsec 2023-02-08 1) Fix policy checks for nested IPsec tunnels when using xfrm interfaces. From Benedict Wong. 2) Fix netlink message expression on 32=>64-bit messages translators. From Anastasia Belova. 3) Prevent potential spectre v1 gadget in xfrm_xlate32_attr. From Eric Dumazet. 4) Always consistently use time64_t in xfrm_timer_handler. From Eric Dumazet. 5) Fix KCSAN reported bug: Multiple cpus can update use_time at the same time. From Eric Dumazet. 6) Fix SCP copy from IPv4 to IPv6 on interfamily tunnel. From Christian Hopps. * tag 'ipsec-2023-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: fix bug with DSCP copy to v6 from v4 tunnel xfrm: annotate data-race around use_time xfrm: consistently use time64_t in xfrm_timer_handler() xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() xfrm: compat: change expression for switch in xfrm_xlate64 Fix XFRM-I support for nested ESP tunnels ==================== Link: https://lore.kernel.org/r/20230208114322.266510-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-08net: txgbe: Update support email addressJiawen Wu
Update new email address for Wangxun 10Gb NIC support team. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://lore.kernel.org/r/20230208023035.3371250-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-08arm64: dts: qcom: sc7280: Power herobrine's 3.3 eDP/TS rail more properlyDouglas Anderson
This is the equivalent of commit f5b4811e8758 ("arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time") and commit 23ff866987de ("arm64: dts: qcom: sc7180: Start the trogdor eDP/touchscreen regulator on"), but for herobrine instead of trogdor. The motivations for herobrine are the same as for trogdor. NOTES: * Currently for herobrine all boards are eDP, not MIPI. If/when we have herobrine derivatives that are MIPI they we can evaluate whether the same off-on-delay makes sense for them. For trogdor we didn't add the delay to MIPI panels because the problem was found late and nobody had complained about it. For herobrine defaulting to assuming the same 500ms makes sense and if we find we need to optimize later we can. * Currently there are no oddball herobrine boards like homestar where the panel really likes to be power cycled. If we have an oddball board it will need to split the eDP and touchscreen rail anyway (like homestar did) and we'll have to delete the "regulator-boot-on" from that board. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207163550.1.I5ff72b7746d5fca8f10ea61351bde4150ed1a7f8@changeid
2023-02-08arm64: dts: qcom: pmk8550: fix PON compatibleNeil Armstrong
The right compatible is qcom,pmk8350-pon, it matches the reg resources associated to the node and the subnodes compatible properties. Fixes: e9c0a4e48489 ("arm64: dts: qcom: Add PMK8550 pmic dtsi") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207-topic-sm8550-upstream-sm8550-dt-fix-v1-2-698d132ab285@linaro.org
2023-02-08arm64: dts: qcom: sm8550: fix DSI controller compatibleNeil Armstrong
Add missing sm8550 soc specific compatible before fallback to match the updated bindings. Fixes: d7da51db5b81 ("arm64: dts: qcom: sm8550: add display hardware devices") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230207-topic-sm8550-upstream-sm8550-dt-fix-v1-1-698d132ab285@linaro.org
2023-02-08arm64: dts: qcom: sc7280: Hook up the touchscreen IO rail on evokerDouglas Anderson
On older revisions of evoker, the touchscreen was either non-functional or needed special hardware magic to get it talking properly. It's been decided that the proper way going forward is to use L3C to power some buffers on the QCard and then configure the touchscreens for 1.8V. Let's do that. Note that this is safe to do even on older revs even if it might not make the touchscreen work there (because they didn't have a properly stuffed QCard). As talked about in the patch ("arm64: dts: qcom: sc7280: On QCard, regulator L3C should be 1.8V") the L3C regulator didn't go anywhere at all on older revs. This patch relies on the patch ("HID: i2c-hid: goodix: Add mainboard-vddio-supply") in order to function properly. Without that patch this one won't do any harm but it won't actually accomplish its goal. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230206184744.7.I2d960ed7f2445db0cf3d227fde985fbd740f3c4d@changeid
2023-02-08arm64: dts: qcom: sc7280: Hook up the touchscreen IO rail on villagerDouglas Anderson
On never revs of sc7280-herobrine-villager (rev2+) the L3C rail is provided to the touchscreen as the IO voltage rail. Let's add it in the device tree. NOTE: Even though this is only really needed on rev2+ villagers (-rev0 had non-functioning touchscreen and -rev1 had some hacky hardware magic), it doesn't actually hurt to do this for old villager revs. As talked about in the patch ("arm64: dts: qcom: sc7280: On QCard, regulator L3C should be 1.8V") the L3C regulator didn't go anywhere at all on older revs. That means that turning it on for older revs doesn't hurt other than drawing a tiny bit of extra power. Since -rev0 and -rev1 villagers will never make it to real customers and it's nice not to have too many old device trees, the better tradeoff seems to be to enable it everywhere. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230206184744.3.I740d409bc5bb69bf4a7b3c4568ea6e7a92f16ccd@changeid
2023-02-08arm64: dts: qcom: sc7280: Add 3ms ramp to herobrine's pp3300_left_in_mlbDouglas Anderson
The "pp3300_left_in_mlb" rail on herobrine eventually connects up to "vreg_edp_3p3" on the qcard. On several herobrine designs this rail has been measured to need more than 1ms to turn on. While technically a herobrine derivative (defined as anyone including the "herobrine.dtsi") could change the board to make the rail rise faster or slower, the fact that two boards (evoker and villager) both measured it as taking more than 1ms implies that it's probably going to be the norm. Thus, let's add a "regulator-enable-ramp-delay" straight into the herobrine.dtsi to handle this. If a particular derivative board needs a faster or slower one then they can override it, though that feels unlikely. While we measured something a bit over 1ms, we'll choose 3ms to give us a tiny bit of margin. This isn't a rail that turns off and on all the time anyway and 3ms is nothing compared to the total amount of time to power on a panel. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230206184744.2.I13814cefc5ab3e0a39ebd09f052e3fd25d4e8f1d@changeid
2023-02-08arm64: dts: qcom: sc7280: On QCard, regulator L3C should be 1.8VDouglas Anderson
On the first sc7280 QCards the L3C rail was never really used for anything. Stuffing options on the QCard meant that the QCard itself didn't use this rail for anything. This rail did get sent to the mainboard, but no existing mainboards ever did anything with it other that route it to a testpoint. On later sc7280 QCards, the L3C rail was repurposed. Instead of being a (nominally) 3.3V rail, it was decided to make it a 1.8V rail. It is now provided to the display connector (which might route it to the touchscreen) and also used to power some buffers relating to touchscreen IO. This rail is getting the additional tag "ts_avccio", though some places still refer to it as "vreg_l3c_3p0" despite the fact that the name now specifies the wrong voltage. Since it never hurts for this rail to be 1.8V (even on old QCards / old boards), let's just change it to 1.8V across the board and add the extra "ts_avccio" moniker as a label in the device tree. Future patches will start using this rail in their touchscreens. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230206184744.1.I784f4b3d7e4a06edafff4a3129f52e749889bc05@changeid
2023-02-08arm64: dts: qcom: sc8280xp: correct LPASS GPIO gpio-rangesKrzysztof Kozlowski
The SC8280XP LPASS pin controller has GPIOs 0-18, so correct the number of GPIOs in gpio-ranges. Fixes: c18773d162a6 ("arm64: dts: qcom: sc8280xp: add SoundWire and LPASS") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203164854.390080-5-krzysztof.kozlowski@linaro.org
2023-02-08arm64: dts: qcom: msm8992-lg-bullhead: Enable regulatorsPetr Vorel
Enable pm8994_s1, pm8994_l{26,29,30,32} regulators. Use values from downstream kernel on bullhead rev 1.01. NOTE: downstream kernel on angler rev 1.01 differences: * pm8994_l29: regulator-min-microvolt = <2700000> * pm8994_l{20,28,31}: use regulator-boot-on Verification: [ 1.832460] s1: Bringing 0uV into 1025000-1025000uV ... [ 2.057667] l26: Bringing 0uV into 987500-987500uV ... [ 2.075722] l29: Bringing 0uV into 2800000-2800000uV [ 2.076604] l30: Bringing 0uV into 1800000-1800000uV [ 2.082431] l31: Bringing 0uV into 1262500-1262500uV [ 2.095767] l32: Bringing 0uV into 1800000-1800000uV Fixes: f3b2c99e73be ("arm64: dts: Enable onboard SDHCI on msm8992") Signed-off-by: Petr Vorel <pvorel@suse.cz> Tested-by: Jamie Douglass <jamiemdouglass@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203100952.13857-1-pvorel@suse.cz
2023-02-08arm64: dts: qcom: sm6115: correct TLMM gpio-rangesKrzysztof Kozlowski
Correct the number of GPIOs in TLMM pin controller. Fixes: 97e563bf5ba1 ("arm64: dts: qcom: sm6115: Add basic soc dtsi") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Iskren Chernev <me@iskren.info> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-11-krzysztof.kozlowski@linaro.org
2023-02-08arm64: dts: qcom: msm8953: correct TLMM gpio-rangesKrzysztof Kozlowski
Correct the number of GPIOs in TLMM pin controller. Fixes: 9fb08c801923 ("arm64: dts: qcom: Add MSM8953 device tree") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-10-krzysztof.kozlowski@linaro.org
2023-02-08arm64: dts: qcom: msm8992-lg-bullhead: Correct memory overlaps with the SMEM ↵Jamie Douglass
and MPSS memory regions The memory region reserved by a previous commit (see fixes tag below) overlaps with the SMEM and MPSS memory regions, causing error messages in dmesg: OF: reserved mem: OVERLAP DETECTED! reserved@5000000 (0x0000000005000000--0x0000000007200000) overlaps with smem_region@6a00000 (0x0000000006a00000--0x0000000006c00000) OF: reserved mem: OVERLAP DETECTED! reserved@6c00000 (0x0000000006c00000--0x0000000007200000) overlaps with memory@7000000 (0x0000000007000000--0x000000000ca00000) This patch resolves both of these by splitting the previously reserved memory region into two sections either side of the SMEM region and by cutting off the second memory region to 0x7000000. Fixes: 22c7e1a0fa45 ("arm64: dts: msm8992-bullhead: add memory hole region") Signed-off-by: Jamie Douglass <jamiemdouglass@gmail.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Tested-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202054819.16079-1-jamiemdouglass@gmail.com
2023-02-08arm64: dts: qcom: sm8350-hdk: correct LT9611 pin functionKrzysztof Kozlowski
SM8350 pin controller does not have "normal" pin function, so use "gpio". Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Fixes: d96d8f9192be ("arm64: dts: qcom: sm8350-hdk: Enable lt9611uxc dsi-hdmi bridge") Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230201154321.276419-2-krzysztof.kozlowski@linaro.org
2023-02-08arm64: dts: qcom: sm8350-hdk: align pin config node names with bindingsKrzysztof Kozlowski
Bindings expect pins to be named with certain pattern. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Fixes: d96d8f9192be ("arm64: dts: qcom: sm8350-hdk: Enable lt9611uxc dsi-hdmi bridge") Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230201154321.276419-1-krzysztof.kozlowski@linaro.org
2023-02-08arm64: dts: qcom: sm6350: Use specific qmpphy compatibleLuca Weiss
The sc7180 phy compatible works fine for some cases, but it turns out sm6350 does need proper phy configuration in the driver, so use the newly added sm6350 compatible. Because the sm6350 compatible is using the new binding, we need to change the node quite a bit to match it. This fixes qmpphy init when no USB cable is plugged in during bootloader stage. Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230120-sm6350-usbphy-v4-3-4d700a90ba16@fairphone.com
2023-02-08arm64: dts: qcom: sm6115: Add smp2p nodesBhupesh Sharma
Add the adsp, cdsp and modem smp2p nodes to sm6115. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230121200454.1423567-1-bhupesh.sharma@linaro.org
2023-02-08arm64: dts: qcom: sm7225-fairphone-fp4: Enable CCI bussesLuca Weiss
Enable the CCI busses that have cameras connected to them. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221213-sm6350-cci-v2-4-15c2c14c34bb@fairphone.com
2023-02-08arm64: dts: qcom: sm6350: Add CCI nodesLuca Weiss
Add nodes for the two CCI blocks found on SM6350. The first contains two i2c busses and while the second one might also contains two busses, the downstream kernel only has one configured, and some boards use the GPIOs for the potential cci1_i2c1 one other purposes, so leave that one unconfigured. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221213-sm6350-cci-v2-3-15c2c14c34bb@fairphone.com
2023-02-08arm64: dts: qcom: sm6350: Add camera clock controllerLuca Weiss
Add a node for the camcc found on SM6350 SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221213-sm6350-cci-v2-2-15c2c14c34bb@fairphone.com
2023-02-08Merge branch '20221213152617.296426-1-konrad.dybcio@linaro.org' into HEADBjorn Andersson
Merge DT binding to gain Camera clock defines for SM6350
2023-02-08dt-bindings: clock: add QCOM SM6350 camera clock bindingsKonrad Dybcio
Add device tree bindings for camera clock controller for Qualcomm Technology Inc's SM6350 SoC. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221213152617.296426-1-konrad.dybcio@linaro.org
2023-02-08ARM: dts: qcom: align OPP table names with DT schemaKrzysztof Kozlowski
DT schema expects names of operating points tables to match certain pattern: qcom-ipq4018-ap120c-ac.dtb: opp_table0: $nodename:0: 'opp_table0' does not match '^opp-table(-[a-z0-9]+)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230120072113.138656-1-krzysztof.kozlowski@linaro.org
2023-02-08drm/amdgpu/smu: skip pptable init under sriovJane Jian
sriov does not need to init pptable from amdgpu driver we finish it from PF Signed-off-by: Jane Jian <Jane.Jian@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
2023-02-08amd/amdgpu: remove test ib on hw ringJesseZhang
test ib function is not necessary on hw ring, so remove it. v2: squash in NULL check fix Signed-off-by: JesseZhang <Jesse.Zhang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-08drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/finiGuilherme G. Piccoli
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/ Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)") Suggested-by: Christian König <christian.koenig@amd.com> Cc: Guchun Chen <guchun.chen@amd.com> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-02-08drm/amdgpu: Use the TGID for trace_amdgpu_vm_update_ptesFriedrich Vock
The pid field corresponds to the result of gettid() in userspace. However, userspace cannot reliably attribute PTE events to processes with just the thread id. This patch allows userspace to easily attribute PTE update events to specific processes by comparing this field with the result of getpid(). For attributing events to specific threads, the thread id is also contained in the common fields of each trace event. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-02-08drm/amdgpu: Add unique_id support for GC 11.0.1/2Kent Russell
These can support unique_id, so create the sysfs file for them Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x
generated by cgit (git 2.34.1) at 2025-09-13 12:38:32 +0000