- Linux-stable-mirror - lists.linaro.org

Re: Patch "[PATCH 6.1.y] drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute" has been added to the 5.4-stable tree

by Sasha Levin

[ Sasha's backport helper bot ] Hi, The upstream commit SHA1 provided is correct: fcf6a49d79923a234844b8efe830a61f3f0584e4 WARNING: Author mismatch between patch and upstream commit: Backport author: <gregkh(a)linuxfoundation.org> Commit author: Wayne Lin <wayne.lin(a)amd.com> Status in newer kernel trees: 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: c7e65cab54a8) 6.1.y | Not found Note: The patch differs from the upstream commit: --- 1: fcf6a49d79923 ! 1: 79f06b6c107fd drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute @@ ## Metadata ## -Author: Wayne Lin <wayne.lin(a)amd.com> +Author: gregkh(a)linuxfoundation.org <gregkh(a)linuxfoundation.org> ## Commit message ## - drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute + Patch "[PATCH 6.1.y] drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute" has been added to the 5.4-stable tree + + This is a note to let you know that I've just added the patch titled + + [PATCH 6.1.y] drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute + + to the 5.4-stable tree which can be found at: + http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… + + The filename of the patch is: + drm-amd-display-don-t-refer-to-dc_sink-in-is_dsc_need_re_compute.patch + and it can be found in the queue-5.4 subdirectory. + + If you, or anyone else, feels it should not be added to the stable tree, + please let <stable(a)vger.kernel.org> know about it. + + From jianqi.ren.cn(a)windriver.com Thu Dec 12 13:11:21 2024 + From: <jianqi.ren.cn(a)windriver.com> + Date: Wed, 11 Dec 2024 18:15:44 +0800 + Subject: [PATCH 6.1.y] drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute + To: <wayne.lin(a)amd.com>, <gregkh(a)linuxfoundation.org> + Cc: <patches(a)lists.linux.dev>, <jerry.zuo(a)amd.com>, <zaeem.mohamed(a)amd.com>, <daniel.wheeler(a)amd.com>, <alexander.deucher(a)amd.com>, <stable(a)vger.kernel.org>, <harry.wentland(a)amd.com>, <sunpeng.li(a)amd.com>, <Rodrigo.Siqueira(a)amd.com>, <christian.koenig(a)amd.com>, <airlied(a)gmail.com>, <daniel(a)ffwll.ch>, <Jerry.Zuo(a)amd.com>, <amd-gfx(a)lists.freedesktop.org>, <dri-devel(a)lists.freedesktop.org>, <linux-kernel(a)vger.kernel.org> + Message-ID: <20241211101544.2121147-1-jianqi.ren.cn(a)windriver.com> + + From: Wayne Lin <wayne.lin(a)amd.com> + + [ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ] [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. @@ Commit message Signed-off-by: Wayne Lin <wayne.lin(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> + Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> ## drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c ## @@ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c: amdgpu_dm_mst_connector_early_unregister(struct drm_connector *connector) @@ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c: dm_dp_mst_detect(st amdgpu_dm_set_mst_status(&aconnector->mst_status, MST_REMOTE_EDID | MST_ALLOCATE_NEW_PAYLOAD | MST_CLEAR_ALLOCATED_PAYLOAD, -@@ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c: static bool is_dsc_need_re_compute( - if (!aconnector || !aconnector->dsc_aux) - continue; - -- /* -- * check if cached virtual MST DSC caps are available and DSC is supported -- * as per specifications in their Virtual DPCD registers. -- */ -- if (!(aconnector->dc_sink->dsc_caps.dsc_dec_caps.is_dsc_supported || -- aconnector->dc_link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_PASSTHROUGH_SUPPORT)) -- continue; -- - stream_on_link[new_stream_on_link_num] = aconnector; - new_stream_on_link_num++; - --- Results of testing on various branches: | Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.1.y | Success | Success | | stable/linux-5.4.y | Failed | N/A |

12 months

1
0
0 0

Re: Patch "rtla/timerlat: Make timerlat_top_cpu->*_count unsigned long long" has been added to the 6.6-stable tree

by Tomas Glozar

út 10. 12. 2024 v 22:04 odesílatel Sasha Levin <sashal(a)kernel.org> napsal: > > This is a note to let you know that I've just added the patch titled > > rtla/timerlat: Make timerlat_top_cpu->*_count unsigned long long > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > rtla-timerlat-make-timerlat_top_cpu-_count-unsigned-.patch > and it can be found in the queue-6.6 subdirectory. > Could you also add "rtla/timerlat: Make timerlat_hist_cpu->*_count unsigned long long", too (76b3102148135945b013797fac9b20), just like we already have in-queue for 6.12? It makes no sense to do one fix but not the other (clearly autosel AI won't take over the world yet). > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 0b8030ad5be8c39c4ad0f27fa740b3140a31023b > Author: Tomas Glozar <tglozar(a)redhat.com> > Date: Fri Oct 11 14:10:14 2024 +0200 > > rtla/timerlat: Make timerlat_top_cpu->*_count unsigned long long > > [ Upstream commit 4eba4723c5254ba8251ecb7094a5078d5c300646 ] > > Most fields of struct timerlat_top_cpu are unsigned long long, but the > fields {irq,thread,user}_count are int (32-bit signed). > > This leads to overflow when tracing on a large number of CPUs for a long > enough time: > $ rtla timerlat top -a20 -c 1-127 -d 12h > ... > 0 12:00:00 | IRQ Timer Latency (us) | Thread Timer Latency (us) > CPU COUNT | cur min avg max | cur min avg max > 1 #43200096 | 0 0 1 2 | 3 2 6 12 > ... > 127 #43200096 | 0 0 1 2 | 3 2 5 11 > ALL #119144 e4 | 0 5 4 | 2 28 16 > > The average latency should be 0-1 for IRQ and 5-6 for thread, but is > reported as 5 and 28, about 4 to 5 times more, due to the count > overflowing when summed over all CPUs: 43200096 * 127 = 5486412192, > however, 1191444898 (= 5486412192 mod MAX_INT) is reported instead, as > seen on the last line of the output, and the averages are thus ~4.6 > times higher than they should be (5486412192 / 1191444898 = ~4.6). > > Fix the issue by changing {irq,thread,user}_count fields to unsigned > long long, similarly to other fields in struct timerlat_top_cpu and to > the count variable in timerlat_top_print_sum. > > Link: https://lore.kernel.org/20241011121015.2868751-1-tglozar@redhat.com > Reported-by: Attila Fazekas <afazekas(a)redhat.com> > Signed-off-by: Tomas Glozar <tglozar(a)redhat.com> > Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/tools/tracing/rtla/src/timerlat_top.c b/tools/tracing/rtla/src/timerlat_top.c > index a84f43857de14..0915092057f85 100644 > --- a/tools/tracing/rtla/src/timerlat_top.c > +++ b/tools/tracing/rtla/src/timerlat_top.c > @@ -49,9 +49,9 @@ struct timerlat_top_params { > }; > > struct timerlat_top_cpu { > - int irq_count; > - int thread_count; > - int user_count; > + unsigned long long irq_count; > + unsigned long long thread_count; > + unsigned long long user_count; > > unsigned long long cur_irq; > unsigned long long min_irq; > @@ -237,7 +237,7 @@ static void timerlat_top_print(struct osnoise_tool *top, int cpu) > /* > * Unless trace is being lost, IRQ counter is always the max. > */ > - trace_seq_printf(s, "%3d #%-9d |", cpu, cpu_data->irq_count); > + trace_seq_printf(s, "%3d #%-9llu |", cpu, cpu_data->irq_count); > > if (!cpu_data->irq_count) { > trace_seq_printf(s, "%s %s %s %s |", no_value, no_value, no_value, no_value); > Thanks, Tomas

12 months

2
1
0 0

Re: [PATCH 6.12 000/466] 6.12.5-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

12 months

1
0
0 0

[PATCH v9 1/9] HID: hid-sensor-hub: don't use stale platform-data on remove

by Heiko Stuebner

The hid-sensor-hub creates the individual device structs and transfers them to the created mfd platform-devices via the platform_data in the mfd_cell. Before e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") the sensor-hub was managing access centrally, with one "completion" in the hub's data structure, which needed to be finished on removal at the latest. The mentioned commit then moved this central management to each hid sensor device, resulting on a completion in each struct hid_sensor_hub_device. The remove procedure was adapted to go through all sensor devices and finish any pending "completion". What this didn't take into account was, platform_device_add_data() that is used by mfd_add{_hotplug}_devices() does a kmemdup on the submitted platform-data. So the data the platform-device gets is a copy of the original data, meaning that the device worked on a different completion than what sensor_hub_remove() currently wants to access. To fix that, use device_for_each_child() to go through each child-device similar to how mfd_remove_devices() unregisters the devices later and with that get the live platform_data to finalize the correct completion. Fixes: e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") Cc: stable(a)vger.kernel.org Acked-by: Benjamin Tissoires <bentiss(a)kernel.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/hid/hid-sensor-hub.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 7bd86eef6ec7..4c94c03cb573 100644 --- a/drivers/hid/hid-sensor-hub.c +++ b/drivers/hid/hid-sensor-hub.c @@ -730,23 +730,30 @@ static int sensor_hub_probe(struct hid_device *hdev, return ret; } +static int sensor_hub_finalize_pending_fn(struct device *dev, void *data) +{ + struct hid_sensor_hub_device *hsdev = dev->platform_data; + + if (hsdev->pending.status) + complete(&hsdev->pending.ready); + + return 0; +} + static void sensor_hub_remove(struct hid_device *hdev) { struct sensor_hub_data *data = hid_get_drvdata(hdev); unsigned long flags; - int i; hid_dbg(hdev, " hardware removed\n"); hid_hw_close(hdev); hid_hw_stop(hdev); + spin_lock_irqsave(&data->lock, flags); - for (i = 0; i < data->hid_sensor_client_cnt; ++i) { - struct hid_sensor_hub_device *hsdev = - data->hid_sensor_hub_client_devs[i].platform_data; - if (hsdev->pending.status) - complete(&hsdev->pending.ready); - } + device_for_each_child(&hdev->dev, NULL, + sensor_hub_finalize_pending_fn); spin_unlock_irqrestore(&data->lock, flags); + mfd_remove_devices(&hdev->dev); mutex_destroy(&data->mutex); } -- 2.45.2

12 months

5
10
0 0

[PATCH v2] usb: gadget: configfs: Ignore trailing LF for user strings to cdev

by Ingo Rohloff

Since commit c033563220e0f7a8 ("usb: gadget: configfs: Attach arbitrary strings to cdev") a user can provide extra string descriptors to a USB gadget via configfs. For "manufacturer", "product", "serialnumber", setting the string via configfs ignores a trailing LF. For the arbitrary strings the LF was not ignored. This patch ignores a trailing LF to make this consistent with the existing behavior for "manufacturer", ... string descriptors. Fixes: c033563220e0 ("usb: gadget: configfs: Attach arbitrary strings to cdev") Cc: stable(a)vger.kernel.org Signed-off-by: Ingo Rohloff <ingo.rohloff(a)lauterbach.com> --- drivers/usb/gadget/configfs.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c index 6499a88d346c..fba2a56dae97 100644 --- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -827,11 +827,15 @@ static ssize_t gadget_string_s_store(struct config_item *item, const char *page, { struct gadget_string *string = to_gadget_string(item); int size = min(sizeof(string->string), len + 1); + ssize_t cpy_len; if (len > USB_MAX_STRING_LEN) return -EINVAL; - return strscpy(string->string, page, size); + cpy_len = strscpy(string->string, page, size); + if (cpy_len > 0 && string->string[cpy_len - 1] == '\n') + string->string[cpy_len - 1] = 0; + return len; } CONFIGFS_ATTR(gadget_string_, s); -- 2.47.1

12 months

1
0
0 0

[PATCH net v2] net: dsa: tag_ocelot_8021q: fix broken reception

by Robert Hodaszi

The blamed commit changed the dsa_8021q_rcv() calling convention to accept pre-populated source_port and switch_id arguments. If those are not available, as in the case of tag_ocelot_8021q, the arguments must be pre-initialized with -1. Due to the bug of passing uninitialized arguments in tag_ocelot_8021q, dsa_8021q_rcv() does not detect that it needs to populate the source_port and switch_id, and this makes dsa_conduit_find_user() fail, which leads to packet loss on reception. Fixes: dcfe7673787b ("net: dsa: tag_sja1105: absorb logic for not overwriting precise info into dsa_8021q_rcv()") Signed-off-by: Robert Hodaszi <robert.hodaszi(a)digi.com> --- Cc: stable(a)vger.kernel.org --- net/dsa/tag_ocelot_8021q.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dsa/tag_ocelot_8021q.c b/net/dsa/tag_ocelot_8021q.c index 8e8b1bef6af6..11ea8cfd6266 100644 --- a/net/dsa/tag_ocelot_8021q.c +++ b/net/dsa/tag_ocelot_8021q.c @@ -79,7 +79,7 @@ static struct sk_buff *ocelot_xmit(struct sk_buff *skb, static struct sk_buff *ocelot_rcv(struct sk_buff *skb, struct net_device *netdev) { - int src_port, switch_id; + int src_port = -1, switch_id = -1; dsa_8021q_rcv(skb, &src_port, &switch_id, NULL, NULL); -- 2.43.0

12 months

3
2
0 0

[PATCH 6.1.y] net: napi: Prevent overflow of napi_defer_hard_irqs

by jianqi.ren.cn＠windriver.com

From: Joe Damato <jdamato(a)fastly.com> [ Upstream commit 08062af0a52107a243f7608fd972edb54ca5b7f8 ] In commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature") napi_defer_irqs was added to net_device and napi_defer_irqs_count was added to napi_struct, both as type int. This value never goes below zero, so there is not reason for it to be a signed int. Change the type for both from int to u32, and add an overflow check to sysfs to limit the value to S32_MAX. The limit of S32_MAX was chosen because the practical limit before this patch was S32_MAX (anything larger was an overflow) and thus there are no behavioral changes introduced. If the extra bit is needed in the future, the limit can be raised. Before this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' $ cat /sys/class/net/eth4/napi_defer_hard_irqs -2147483647 After this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' bash: line 0: echo: write error: Numerical result out of range Similarly, /sys/class/net/XXXXX/tx_queue_len is defined as unsigned: include/linux/netdevice.h: unsigned int tx_queue_len; And has an overflow check: dev_change_tx_queue_len(..., unsigned long new_len): if (new_len != (unsigned int)new_len) return -ERANGE; Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Joe Damato <jdamato(a)fastly.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20240904153431.307932-1-jdamato@fastly.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> --- include/linux/netdevice.h | 4 ++-- net/core/net-sysfs.c | 6 +++++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index fbbd0df1106b..8379e938cd89 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -352,7 +352,7 @@ struct napi_struct { unsigned long state; int weight; - int defer_hard_irqs_count; + u32 defer_hard_irqs_count; unsigned long gro_bitmask; int (*poll)(struct napi_struct *, int); #ifdef CONFIG_NETPOLL @@ -2193,7 +2193,7 @@ struct net_device { struct bpf_prog __rcu *xdp_prog; unsigned long gro_flush_timeout; - int napi_defer_hard_irqs; + u32 napi_defer_hard_irqs; #define GRO_LEGACY_MAX_SIZE 65536u /* TCP minimal MSS is 8 (TCP_MIN_GSO_SIZE), * and shinfo->gso_segs is a 16bit field. diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index 8a06f97320e0..4ce57e75d139 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -30,6 +30,7 @@ #ifdef CONFIG_SYSFS static const char fmt_hex[] = "%#x\n"; static const char fmt_dec[] = "%d\n"; +static const char fmt_uint[] = "%u\n"; static const char fmt_ulong[] = "%lu\n"; static const char fmt_u64[] = "%llu\n"; @@ -405,6 +406,9 @@ NETDEVICE_SHOW_RW(gro_flush_timeout, fmt_ulong); static int change_napi_defer_hard_irqs(struct net_device *dev, unsigned long val) { + if (val > S32_MAX) + return -ERANGE; + WRITE_ONCE(dev->napi_defer_hard_irqs, val); return 0; } @@ -418,7 +422,7 @@ static ssize_t napi_defer_hard_irqs_store(struct device *dev, return netdev_store(dev, attr, buf, len, change_napi_defer_hard_irqs); } -NETDEVICE_SHOW_RW(napi_defer_hard_irqs, fmt_dec); +NETDEVICE_SHOW_RW(napi_defer_hard_irqs, fmt_uint); static ssize_t ifalias_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t len) -- 2.25.1

12 months

5
6
0 0

[PATCH v8 0/3] clk: qcom: Add support for multiple power-domains for a clock controller.

by Bryan O'Donoghue

Changes in v8: - Picks up change I agreed with Vlad but failed to cherry-pick into my b4 tree - Vlad/Bod - Rewords the commit log for patch #3. As I read it I decided I might translate bits of it from thought-stream into English - Bod - Link to v7: https://lore.kernel.org/r/20241211-b4-linux-next-24-11-18-clock-multiple-po… Changes in v7: - Expand commit log in patch #3 I've discussed with Bjorn on IRC and video what to put into the log here and captured most of what we discussed. Mostly the point here is voting for voltages in the power-domain list is up to the drivers to do with performance states/opp-tables not for the GDSC code. - Bjorn/Bryan - Link to v6: https://lore.kernel.org/r/20241129-b4-linux-next-24-11-18-clock-multiple-po… Changes in v6: - Passes NULL to second parameter of devm_pm_domain_attach_list - Vlad - Link to v5: https://lore.kernel.org/r/20241128-b4-linux-next-24-11-18-clock-multiple-po… Changes in v5: - In-lines devm_pm_domain_attach_list() in probe() directly - Vlad - Link to v4: https://lore.kernel.org/r/20241127-b4-linux-next-24-11-18-clock-multiple-po… v4: - Adds Bjorn's RB to first patch - Bjorn - Drops the 'd' in "and int" - Bjorn - Amends commit log of patch 3 to capture a number of open questions - Bjorn - Link to v3: https://lore.kernel.org/r/20241126-b4-linux-next-24-11-18-clock-multiple-po… v3: - Fixes commit log "per which" - Bryan - Link to v2: https://lore.kernel.org/r/20241125-b4-linux-next-24-11-18-clock-multiple-po… v2: The main change in this version is Bjorn's pointing out that pm_runtime_* inside of the gdsc_enable/gdsc_disable path would be recursive and cause a lockdep splat. Dmitry alluded to this too. Bjorn pointed to stuff being done lower in the gdsc_register() routine that might be a starting point. I iterated around that idea and came up with patch #3. When a gdsc has no parent and the pd_list is non-NULL then attach that orphan GDSC to the clock controller power-domain list. Existing subdomain code in gdsc_register() will connect the parent GDSCs in the clock-controller to the clock-controller subdomain, the new code here does that same job for a list of power-domains the clock controller depends on. To Dmitry's point about MMCX and MCX dependencies for the registers inside of the clock controller, I have switched off all references in a test dtsi and confirmed that accessing the clock-controller regs themselves isn't required. On the second point I also verified my test branch with lockdep on which was a concern with the pm_domain version of this solution but I wanted to cover it anyway with the new approach for completeness sake. Here's the item-by-item list of changes: - Adds a patch to capture pm_genpd_add_subdomain() result code - Bryan - Changes changelog of second patch to remove singleton and generally to make the commit log easier to understand - Bjorn - Uses demv_pm_domain_attach_list - Vlad - Changes error check to if (ret < 0 && ret != -EEXIST) - Vlad - Retains passing &pd_data instead of NULL - because NULL doesn't do the same thing - Bryan/Vlad - Retains standalone function qcom_cc_pds_attach() because the pd_data enumeration looks neater in a standalone function - Bryan/Vlad - Drops pm_runtime in favour of gdsc_add_subdomain_list() for each power-domain in the pd_list. The pd_list will be whatever is pointed to by power-domains = <> in the dtsi - Bjorn - Link to v1: https://lore.kernel.org/r/20241118-b4-linux-next-24-11-18-clock-multiple-po… v1: On x1e80100 and it's SKUs the Camera Clock Controller - CAMCC has multiple power-domains which power it. Usually with a single power-domain the core platform code will automatically switch on the singleton power-domain for you. If you have multiple power-domains for a device, in this case the clock controller, you need to switch those power-domains on/off yourself. The clock controllers can also contain Global Distributed Switch Controllers - GDSCs which themselves can be referenced from dtsi nodes ultimately triggering a gdsc_en() in drivers/clk/qcom/gdsc.c. As an example: cci0: cci@ac4a000 { power-domains = <&camcc TITAN_TOP_GDSC>; }; This series adds the support to attach a power-domain list to the clock-controllers and the GDSCs those controllers provide so that in the case of the above example gdsc_toggle_logic() will trigger the power-domain list with pm_runtime_resume_and_get() and pm_runtime_put_sync() respectively. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> --- Bryan O'Donoghue (3): clk: qcom: gdsc: Capture pm_genpd_add_subdomain result code clk: qcom: common: Add support for power-domain attachment clk: qcom: Support attaching GDSCs to multiple parents drivers/clk/qcom/common.c | 6 ++++++ drivers/clk/qcom/gdsc.c | 41 +++++++++++++++++++++++++++++++++++++++-- drivers/clk/qcom/gdsc.h | 1 + 3 files changed, 46 insertions(+), 2 deletions(-) --- base-commit: 744cf71b8bdfcdd77aaf58395e068b7457634b2c change-id: 20241118-b4-linux-next-24-11-18-clock-multiple-power-domains-a5f994dc452a Best regards, -- Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>

12 months

2
2
0 0

FAILED: patch "[PATCH] scsi: ufs: qcom: Only free platform MSIs when ESI is enabled" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 64506b3d23a337e98a74b18dcb10c8619365f2bd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121240-props-brittle-f872@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 64506b3d23a337e98a74b18dcb10c8619365f2bd Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Date: Mon, 11 Nov 2024 23:18:31 +0530 Subject: [PATCH] scsi: ufs: qcom: Only free platform MSIs when ESI is enabled Otherwise, it will result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: mutex_lock+0xc/0x54 platform_device_msi_free_irqs_all+0x14/0x20 ufs_qcom_remove+0x34/0x48 [ufs_qcom] platform_remove+0x28/0x44 device_remove+0x4c/0x80 device_release_driver_internal+0xd8/0x178 driver_detach+0x50/0x9c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom] __arm64_sys_delete_module+0x180/0x260 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xdc el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x190/0x194 Cc: stable(a)vger.kernel.org # 6.3 Fixes: 519b6274a777 ("scsi: ufs: qcom: Add MCQ ESI config vendor specific ops") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Link: https://lore.kernel.org/r/20241111-ufs_bug_fix-v1-2-45ad8b62f02e@linaro.org Reviewed-by: Bean Huo <beanhuo(a)micron.com> Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c index 3b592492e152..5220ec78021d 100644 --- a/drivers/ufs/host/ufs-qcom.c +++ b/drivers/ufs/host/ufs-qcom.c @@ -1861,10 +1861,12 @@ static int ufs_qcom_probe(struct platform_device *pdev) static void ufs_qcom_remove(struct platform_device *pdev) { struct ufs_hba *hba = platform_get_drvdata(pdev); + struct ufs_qcom_host *host = ufshcd_get_variant(hba); pm_runtime_get_sync(&(pdev)->dev); ufshcd_remove(hba); - platform_device_msi_free_irqs_all(hba->dev); + if (host->esi_enabled) + platform_device_msi_free_irqs_all(hba->dev); } static const struct of_device_id ufs_qcom_of_match[] __maybe_unused = {

12 months

1
0
0 0

stable-rc: queue/6.6: drivers/ufs/host/ufs-qcom.c:1929:13: error: 'host' undeclared (first use in this function)

by Naresh Kamboju

The arm64 builds failed on Linux stable-rc queues/6.6 due to following build warnings / errors. arm64: * build/gcc-13-defconfig-lkftconfig First seen on Linux stable-rc queues/6.6 Good: v6.6.65 Bad: v6.6.65-348-g690f793e86f4 Build log: ----------- drivers/ufs/host/ufs-qcom.c: In function 'ufs_qcom_remove': drivers/ufs/host/ufs-qcom.c:1929:13: error: 'host' undeclared (first use in this function) 1929 | if (host->esi_enabled) | ^~~~ drivers/ufs/host/ufs-qcom.c:1929:13: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [scripts/Makefile.build:243: drivers/ufs/host/ufs-qcom.o] Error 1 the commit that causes this build regression is, scsi: ufs: qcom: Only free platform MSIs when ESI is enabled commit 64506b3d23a337e98a74b18dcb10c8619365f2bd upstream. Links: ------- - https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… - https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… - https://qa-reports.linaro.org/lkft/linux-stable-rc-queues-queue_6.6/build/v… Steps to reproduce: ------------ # tuxmake --runtime podman \ --target-arch arm64 \ --toolchain gcc-13 \ --kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2q7Ekivz3juYAyrxbUVA… metadata: ---- git describe: v6.6.65-348-g690f793e86f4 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git sha: 690f793e86f4efa31ddf26a48f4af8c28d2f8402 kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2q7Ekivz3juYAyrxbUVA… build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2q7Ekivz3juYAyrxbUVA… toolchain: gcc-13 config: gcc-13-defconfig-lkftconfig arch: arm64 -- Linaro LKFT https://lkft.linaro.org

12 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror