December 2024 - Linux-stable-mirror

[PATCH v6 1/6] PCI: dwc: ep: Write BAR_MASK before iATU registers in pci_epc_set_bar()

by Niklas Cassel

The "DesignWare Cores PCI Express Controller Register Descriptions, Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i", fields LWR_TARGET_RW and LWR_TARGET_HW both state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested BAR size (which is supplied in the struct pci_epf_bar which is passed to pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent. Thus, if the struct pci_epf_bar requests a BAR size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.1

9 months

1
0
0 0

[PATCH v2] soc: qcom: llcc: Enable LLCC_WRCACHE at boot on X1

by Konrad Dybcio

From: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Do so in accordance with the internal recommendations. Fixes: b3cf69a43502 ("soc: qcom: llcc: Add configuration data for X1E80100") Cc: stable(a)vger.kernel.org Reviewed-by: Rajendra Nayak <quic_rjendra(a)quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> --- Changes in v2: - Cc stable - Add more context lines - Pick up r-b - Link to v1: https://lore.kernel.org/r/20241207-topic-llcc_x1e_wrcache-v1-1-232e6aff49e4… --- drivers/soc/qcom/llcc-qcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c index 32c3bc887cefb87c296e3ba67a730c87fa2fa346..1560db00a01248197e5c2936e785a5ea77f74ad8 100644 --- a/drivers/soc/qcom/llcc-qcom.c +++ b/drivers/soc/qcom/llcc-qcom.c @@ -2997,20 +2997,21 @@ static const struct llcc_slice_config x1e80100_data[] = { .bonus_ways = 0xfff, .cache_mode = 0, }, { .usecase_id = LLCC_WRCACHE, .slice_id = 31, .max_cap = 1024, .priority = 1, .fixed_size = true, .bonus_ways = 0xfff, .cache_mode = 0, + .activate_on_init = true, }, { .usecase_id = LLCC_CAMEXP0, .slice_id = 4, .max_cap = 256, .priority = 4, .fixed_size = true, .bonus_ways = 0x3, .cache_mode = 0, }, { .usecase_id = LLCC_CAMEXP1, --- base-commit: 3e42dc9229c5950e84b1ed705f94ed75ed208228 change-id: 20241207-topic-llcc_x1e_wrcache-647070e2d130 Best regards, -- Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com>

9 months

3
3
0 0

[PATCH v4 0/7] drm: Add DSI/DP support for Renesas r8a779h0 V4M and grey-hawk board

by Tomi Valkeinen

Add everything needed to support the DSI output on Renesas r8a779h0 (V4M) SoC, and the DP output (via sn65dsi86 DSI to DP bridge) on the Renesas grey-hawk board. Overall the DSI and the board design is almost identical to Renesas r8a779g0 and white-hawk board. Note: the v4 no longer has the dts and the clk patches, as those have been merged to renesas-devel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas(a)ideasonboard.com> --- Changes in v4: - Dropped patches merged to renesas-devel - Added new patch "dt-bindings: display: renesas,du: Add missing maxItems" to fix the bindings - Add the missing maxItems to "dt-bindings: display: renesas,du: Add r8a779h0" - Link to v3: https://lore.kernel.org/r/20241206-rcar-gh-dsi-v3-0-d74c2166fa15@ideasonboa… Changes in v3: - Update "Write DPTSR only if there are more than one crtc" patch to "Write DPTSR only if the second source exists" - Add Laurent's Rb - Link to v2: https://lore.kernel.org/r/20241205-rcar-gh-dsi-v2-0-42471851df86@ideasonboa… Changes in v2: - Add the DT binding with a new conditional block, so that we can set only the port@0 as required - Drop port@1 from r8a779h0.dtsi (there's no port@1) - Add a new patch to write DPTSR only if num_crtcs > 1 - Drop RCAR_DU_FEATURE_NO_DPTSR (not needed anymore) - Add Cc: stable to the fix, and move it as first patch - Added the tags from reviews - Link to v1: https://lore.kernel.org/r/20241203-rcar-gh-dsi-v1-0-738ae1a95d2a@ideasonboa… --- Tomi Valkeinen (7): drm/rcar-du: dsi: Fix PHY lock bit check drm/rcar-du: Write DPTSR only if the second source exists dt-bindings: display: renesas,du: Add missing maxItems dt-bindings: display: renesas,du: Add r8a779h0 dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779h0 drm/rcar-du: dsi: Add r8a779h0 support drm/rcar-du: Add support for r8a779h0 .../display/bridge/renesas,dsi-csi2-tx.yaml | 1 + .../devicetree/bindings/display/renesas,du.yaml | 63 ++++++++++++++++++++-- drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 +++++++ drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 24 ++++++--- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 4 +- .../gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 1 - 6 files changed, 99 insertions(+), 12 deletions(-) --- base-commit: adc218676eef25575469234709c2d87185ca223a change-id: 20241008-rcar-gh-dsi-9c01f5deeac8 Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

9 months

1
1
0 0

[PATCH] fs: fix is_mnt_ns_file()

by Miklos Szeredi

Commit 1fa08aece425 ("nsfs: convert to path_from_stashed() helper") reused nsfs dentry's d_fsdata, which no longer contains a pointer to proc_ns_operations. Fix the remaining use in is_mnt_ns_file(). Fixes: 1fa08aece425 ("nsfs: convert to path_from_stashed() helper") Cc: <stable(a)vger.kernel.org> # v6.9 Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> --- Came across this while getting the mnt_ns in fsnotify_mark(), tested the fix in that context. I don't have a test for mainline, though. fs/namespace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 23e81c2a1e3f..6eec7794f707 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2055,9 +2055,15 @@ SYSCALL_DEFINE1(oldumount, char __user *, name) static bool is_mnt_ns_file(struct dentry *dentry) { + struct ns_common *ns; + /* Is this a proxy for a mount namespace? */ - return dentry->d_op == &ns_dentry_operations && - dentry->d_fsdata == &mntns_operations; + if (dentry->d_op != &ns_dentry_operations) + return false; + + ns = d_inode(dentry)->i_private; + + return ns->ops == &mntns_operations; } struct ns_common *from_mnt_ns(struct mnt_namespace *mnt) -- 2.47.0

9 months

4
3
0 0

[PATCH 0/3] scsi: ufs: qcom: Suspend fixes

by Manivannan Sadhasivam via B4 Relay

Hi, This series fixes the several suspend issues on Qcom platforms. Patch 1 fixes the resume failure with spm_lvl=5 suspend on most of the Qcom platforms. For this patch, I couldn't figure out the exact commit that caused the issue. So I used the commit that introduced reinit support as a placeholder. Patch 3 fixes the suspend issue on SM8550 and SM8650 platforms where UFS PHY retention is not supported. Hence the default spm_lvl=3 suspend fails. So this patch configures spm_lvl=5 as the default suspend level to force UFSHC/ device powerdown during suspend. This supersedes the previous series [1] that tried to fix the issue in clock drivers. This series is tested on Qcom SM8550 MTP and Qcom RB5 boards. [1] https://lore.kernel.org/linux-arm-msm/20241107-ufs-clk-fix-v1-0-6032ff22a05… Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- Manivannan Sadhasivam (3): scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence() scsi: ufs: qcom: Allow passing platform specific OF data scsi: ufs: qcom: Power down the controller/device during system suspend for SM8550/SM8650 SoCs drivers/ufs/core/ufshcd-priv.h | 6 ------ drivers/ufs/core/ufshcd.c | 1 - drivers/ufs/host/ufs-qcom.c | 31 +++++++++++++++++++------------ drivers/ufs/host/ufs-qcom.h | 5 +++++ include/ufs/ufshcd.h | 2 -- 5 files changed, 24 insertions(+), 21 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241211-ufs-qcom-suspend-fix-5618e9c56d93 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>

9 months

3
4
0 0

Re: [syzbot] [tipc?] kernel BUG in __pskb_pull_tail

by syzbot

syzbot has bisected this issue to: commit de4f5fed3f231a8ff4790bf52975f847b95b85ea Author: Jens Axboe <axboe(a)kernel.dk> Date: Wed Mar 29 14:52:15 2023 +0000 iov_iter: add iter_iovec() helper bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17424730580000 start commit: 96b6fcc0ee41 Merge branch 'net-dsa-cleanup-eee-part-1' git tree: net-next final oops: https://syzkaller.appspot.com/x/report.txt?x=14c24730580000 console output: https://syzkaller.appspot.com/x/log.txt?x=10c24730580000 kernel config: https://syzkaller.appspot.com/x/.config?x=1362a5aee630ff34 dashboard link: https://syzkaller.appspot.com/bug?extid=4f66250f6663c0c1d67e syz repro: https://syzkaller.appspot.com/x/repro.syz?x=166944f8580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1287ecdf980000 Reported-by: syzbot+4f66250f6663c0c1d67e(a)syzkaller.appspotmail.com Fixes: de4f5fed3f23 ("iov_iter: add iter_iovec() helper") For information about bisection process see: https://goo.gl/tpsmEJ#bisection

9 months

2
1
0 0

FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Tue, 3 Dec 2024 11:16:30 +0100 Subject: [PATCH] clocksource: Make negative motion detection more robust Guenter reported boot stalls on a emulated ARM 32-bit platform, which has a 24-bit wide clocksource. It turns out that the calculated maximal idle time, which limits idle sleeps to prevent clocksource wrap arounds, is close to the point where the negative motion detection triggers. max_idle_ns: 597268854 ns negative motion tripping point: 671088640 ns If the idle wakeup is delayed beyond that point, the clocksource advances far enough to trigger the negative motion detection. This prevents the clock to advance and in the worst case the system stalls completely if the consecutive sleeps based on the stale clock are delayed as well. Cure this by calculating a more robust cut-off value for negative motion, which covers 87.5% of the actual clocksource counter width. Compare the delta against this value to catch negative motion. This is specifically for clock sources with a small counter width as their wrap around time is close to the half counter width. For clock sources with wide counters this is not a problem because the maximum idle time is far from the half counter width due to the math overflow protection constraints. For the case at hand this results in a tripping point of 1174405120ns. Note, that this cannot prevent issues when the delay exceeds the 87.5% margin, but that's not different from the previous unchecked version which allowed arbitrary time jumps. Systems with small counter width are prone to invalid results, but this problem is unlikely to be seen on real hardware. If such a system completely stalls for more than half a second, then there are other more urgent problems than the counter wrapping around. Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Link: https://lore.kernel.org/all/8734j5ul4x.ffs@tglx Closes: https://lore.kernel.org/all/387b120b-d68a-45e8-b6ab-768cd95d11c2@roeck-us.n… diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h index ef1b16da6ad5..65b7c41471c3 100644 --- a/include/linux/clocksource.h +++ b/include/linux/clocksource.h @@ -49,6 +49,7 @@ struct module; * @archdata: Optional arch-specific data * @max_cycles: Maximum safe cycle value which won't overflow on * multiplication + * @max_raw_delta: Maximum safe delta value for negative motion detection * @name: Pointer to clocksource name * @list: List head for registration (internal) * @freq_khz: Clocksource frequency in khz. @@ -109,6 +110,7 @@ struct clocksource { struct arch_clocksource_data archdata; #endif u64 max_cycles; + u64 max_raw_delta; const char *name; struct list_head list; u32 freq_khz; diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index aab6472853fa..7304d7cf47f2 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -24,7 +24,7 @@ static void clocksource_enqueue(struct clocksource *cs); static noinline u64 cycles_to_nsec_safe(struct clocksource *cs, u64 start, u64 end) { - u64 delta = clocksource_delta(end, start, cs->mask); + u64 delta = clocksource_delta(end, start, cs->mask, cs->max_raw_delta); if (likely(delta < cs->max_cycles)) return clocksource_cyc2ns(delta, cs->mult, cs->shift); @@ -993,6 +993,15 @@ static inline void clocksource_update_max_deferment(struct clocksource *cs) cs->max_idle_ns = clocks_calc_max_nsecs(cs->mult, cs->shift, cs->maxadj, cs->mask, &cs->max_cycles); + + /* + * Threshold for detecting negative motion in clocksource_delta(). + * + * Allow for 0.875 of the counter width so that overly long idle + * sleeps, which go slightly over mask/2, do not trigger the + * negative motion detection. + */ + cs->max_raw_delta = (cs->mask >> 1) + (cs->mask >> 2) + (cs->mask >> 3); } static struct clocksource *clocksource_find_best(bool oneshot, bool skipcur) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 0ca85ff4fbb4..3d128825d343 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -755,7 +755,8 @@ static void timekeeping_forward_now(struct timekeeper *tk) u64 cycle_now, delta; cycle_now = tk_clock_read(&tk->tkr_mono); - delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask); + delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask, + tk->tkr_mono.clock->max_raw_delta); tk->tkr_mono.cycle_last = cycle_now; tk->tkr_raw.cycle_last = cycle_now; @@ -2230,7 +2231,8 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode) return false; offset = clocksource_delta(tk_clock_read(&tk->tkr_mono), - tk->tkr_mono.cycle_last, tk->tkr_mono.mask); + tk->tkr_mono.cycle_last, tk->tkr_mono.mask, + tk->tkr_mono.clock->max_raw_delta); /* Check if there's really nothing to do */ if (offset < real_tk->cycle_interval && mode == TK_ADV_TICK) diff --git a/kernel/time/timekeeping_internal.h b/kernel/time/timekeeping_internal.h index 63e600e943a7..8c9079108ffb 100644 --- a/kernel/time/timekeeping_internal.h +++ b/kernel/time/timekeeping_internal.h @@ -30,15 +30,15 @@ static inline void timekeeping_inc_mg_floor_swaps(void) #endif -static inline u64 clocksource_delta(u64 now, u64 last, u64 mask) +static inline u64 clocksource_delta(u64 now, u64 last, u64 mask, u64 max_delta) { u64 ret = (now - last) & mask; /* - * Prevent time going backwards by checking the MSB of mask in - * the result. If set, return 0. + * Prevent time going backwards by checking the result against + * @max_delta. If greater, return 0. */ - return ret & ~(mask >> 1) ? 0 : ret; + return ret > max_delta ? 0 : ret; } /* Semi public for serialization of non timekeeper VDSO updates. */

9 months

4
9
0 0

Re: [PATCH v5.10.277] wifi: mac80211: Avoid address calculations via out of bounds array indexing

by Greg KH

On Mon, Oct 28, 2024 at 05:00:02PM +0530, Hardik Gohil wrote: > On Mon, Oct 21, 2024 at 3:10 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > > > On Sat, Oct 19, 2024 at 11:06:40AM +0530, Hardik Gohil wrote: > > > From: Kenton Groombridge <concord(a)gentoo.org> > > > > > > [ Upstream commit 2663d0462eb32ae7c9b035300ab6b1523886c718 ] > > > > We can't take patches for 5.10 that are not already in 5.15. Please fix > > up and resend for ALL relevent trees. > > > > thanks, > > > > greg k-h > > I have just confirmed those are applicable to v5.15 and v5.10. > > Request to add those patches. Please send tested backports. thanks, greg k-h

9 months

3
5
0 0

[PATCH] drm/panel: st7701: Add prepare_prev_first flag to drm_panel

by Marek Vasut

The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. This fixes the panel operation on NXP i.MX8MP SoC / Samsung DSIM DSI host. Fixes: 849b2e3ff969 ("drm/panel: Add Sitronix ST7701 panel driver") Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Chris Morgan <macromorgan(a)hotmail.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Hironori KIKUCHI <kikuchan98(a)gmail.com> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Jessica Zhang <quic_jesszhan(a)quicinc.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Neil Armstrong <neil.armstrong(a)linaro.org> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: dri-devel(a)lists.freedesktop.org Cc: stable(a)vger.kernel.org # v6.2+ --- Note that the prepare_prev_first flag was added in Linux 6.2.y commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel"), hence the CC stable v6.2+, even if the Fixes tag points to a commit in Linux 5.1.y . --- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c b/drivers/gpu/drm/panel/panel-sitronix-st7701.c index eef03d04e0cd2..1f72ef7ca74c9 100644 --- a/drivers/gpu/drm/panel/panel-sitronix-st7701.c +++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c @@ -1177,6 +1177,7 @@ static int st7701_probe(struct device *dev, int connector_type) return dev_err_probe(dev, ret, "Failed to get orientation\n"); drm_panel_init(&st7701->panel, dev, &st7701_funcs, connector_type); + st7701->panel.prepare_prev_first = true; /** * Once sleep out has been issued, ST7701 IC required to wait 120ms -- 2.45.2

9 months

3
2
0 0

[PATCH v2] usb: typec: ucsi: Set orientation as none when connector is unplugged

by Abel Vesa

The current implementation of the ucsi glink client connector_status() callback is only relying on the state of the gpio. This means that even when the cable is unplugged, the orientation propagated to the switches along the graph is "orientation normal", instead of "orientation none", which would be the correct one in this case. One of the Qualcomm DP-USB PHY combo drivers, which needs to be aware of the orientation change, is relying on the "orientation none" to skip the reinitialization of the entire PHY. Since the ucsi glink client advertises "orientation normal" even when the cable is unplugged, the mentioned PHY is taken down and reinitialized when in fact it should be left as-is. This triggers a crash within the displayport controller driver in turn, which brings the whole system down on some Qualcomm platforms. Propagating "orientation none" from the ucsi glink client on the connector_status() callback hides the problem of the mentioned PHY driver away for now. But the "orientation none" is nonetheless the correct one to be used in this case. So propagate the "orientation none" instead when the connector status flags says cable is disconnected. Fixes: 76716fd5bf09 ("usb: typec: ucsi: glink: move GPIO reading into connector_status callback") Cc: stable(a)vger.kernel.org # 6.10 Reviewed-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong(a)linaro.org> Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v2: - Re-worded the commit message to explain a bit more what is happening. - Added Fixes tag and CC'ed stable. - Dropped the RFC prefix. - Used the new UCSI_CONSTAT macro which did not exist when v1 was sent. - Link to v1: https://lore.kernel.org/r/20241017-usb-typec-ucsi-glink-add-orientation-non… --- drivers/usb/typec/ucsi/ucsi_glink.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/typec/ucsi/ucsi_glink.c b/drivers/usb/typec/ucsi/ucsi_glink.c index 90948cd6d2972402465a2adaba3e1ed055cf0cfa..fed39d45809050f1e08dc1d34008b5c561461391 100644 --- a/drivers/usb/typec/ucsi/ucsi_glink.c +++ b/drivers/usb/typec/ucsi/ucsi_glink.c @@ -185,6 +185,11 @@ static void pmic_glink_ucsi_connector_status(struct ucsi_connector *con) struct pmic_glink_ucsi *ucsi = ucsi_get_drvdata(con->ucsi); int orientation; + if (!UCSI_CONSTAT(con, CONNECTED)) { + typec_set_orientation(con->port, TYPEC_ORIENTATION_NONE); + return; + } + if (con->num > PMIC_GLINK_MAX_PORTS || !ucsi->port_orientation[con->num - 1]) return; --- base-commit: 3e42dc9229c5950e84b1ed705f94ed75ed208228 change-id: 20241017-usb-typec-ucsi-glink-add-orientation-none-73f1f2522999 Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024