July 2024 - Linux-stable-mirror

[PATCH v1 1/1] mfd: rk8xx: Fix shutdown handler

by Sebastian Reichel

When I converted rk808 to device managed resources I converted the rk808 specific pm_power_off handler to devm_register_sys_off_handler() using SYS_OFF_MODE_POWER_OFF_PREPARE, which is allowed to sleep. I did this because the driver's poweroff function makes use of regmap and the backend of that might sleep. But the PMIC poweroff function will kill off the board power and the kernel does some extra steps after the prepare handler. Thus the prepare handler should not be used for the PMIC's poweroff routine. Instead the normal SYS_OFF_MODE_POWER_OFF phase should be used. The old pm_power_off method is also being called from there, so this would have been a cleaner conversion anyways. But it still makes sense to investigate the sleep handling and check if there are any issues. Apparently the Rockchip and Meson I2C drivers (the only platforms using the PMICs handled by this driver) both have support for atomic transfers and thus may be called from the proper poweroff context. Things are different on the SPI side. That is so far only used by rk806 and that one is only used by Rockchip RK3588. Unfortunately the Rockchip SPI driver does not support atomic transfers. That means using the normal POWER_OFF handler would introduce the following error splash during shutdown on all RK3588 boards currently supported upstream: [ 13.761353] ------------[ cut here ]------------ [ 13.761764] Voluntary context switch within RCU read-side critical section! [ 13.761776] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:330 rcu_note_context_switch+0x3ac/0x404 [ 13.763219] Modules linked in: [ 13.763498] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.10.0-12284-g2818a9a19514 #1499 [ 13.764297] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) [ 13.764812] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 13.765427] pc : rcu_note_context_switch+0x3ac/0x404 [ 13.765871] lr : rcu_note_context_switch+0x3ac/0x404 [ 13.766314] sp : ffff800084f4b5b0 [ 13.766609] x29: ffff800084f4b5b0 x28: ffff00040139b800 x27: 00007dfb4439ae80 [ 13.767245] x26: ffff00040139bc80 x25: 0000000000000000 x24: ffff800082118470 [ 13.767880] x23: 0000000000000000 x22: ffff000400300000 x21: ffff000400300000 [ 13.768515] x20: ffff800083a9d600 x19: ffff0004fee48600 x18: fffffffffffed448 [ 13.769151] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000048 [ 13.769787] x14: fffffffffffed490 x13: ffff80008473b3c0 x12: 0000000000000900 [ 13.770421] x11: 0000000000000300 x10: ffff800084797bc0 x9 : ffff80008473b3c0 [ 13.771057] x8 : 00000000ffffefff x7 : ffff8000847933c0 x6 : 0000000000000300 [ 13.771692] x5 : 0000000000000301 x4 : 40000000fffff300 x3 : 0000000000000000 [ 13.772328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000400300000 [ 13.772964] Call trace: [ 13.773184] rcu_note_context_switch+0x3ac/0x404 [ 13.773598] __schedule+0x94/0xb0c [ 13.773907] schedule+0x34/0x104 [ 13.774198] schedule_timeout+0x84/0xfc [ 13.774544] wait_for_completion_timeout+0x78/0x14c [ 13.774980] spi_transfer_one_message+0x588/0x690 [ 13.775403] __spi_pump_transfer_message+0x19c/0x4ec [ 13.775846] __spi_sync+0x2a8/0x3c4 [ 13.776161] spi_write_then_read+0x120/0x208 [ 13.776543] rk806_spi_bus_read+0x54/0x88 [ 13.776905] _regmap_raw_read+0xec/0x16c [ 13.777257] _regmap_bus_read+0x44/0x7c [ 13.777601] _regmap_read+0x60/0xd8 [ 13.777915] _regmap_update_bits+0xf4/0x13c [ 13.778289] regmap_update_bits_base+0x64/0x98 [ 13.778686] rk808_power_off+0x70/0xfc [ 13.779024] sys_off_notify+0x40/0x6c [ 13.779356] atomic_notifier_call_chain+0x60/0x90 [ 13.779776] do_kernel_power_off+0x54/0x6c [ 13.780146] machine_power_off+0x18/0x24 [ 13.780499] kernel_power_off+0x70/0x7c [ 13.780845] __do_sys_reboot+0x210/0x270 [ 13.781198] __arm64_sys_reboot+0x24/0x30 [ 13.781558] invoke_syscall+0x48/0x10c [ 13.781897] el0_svc_common+0x3c/0xe8 [ 13.782228] do_el0_svc+0x20/0x2c [ 13.782528] el0_svc+0x34/0xd8 [ 13.782806] el0t_64_sync_handler+0x120/0x12c [ 13.783197] el0t_64_sync+0x190/0x194 [ 13.783527] ---[ end trace 0000000000000000 ]--- To avoid this we keep the SYS_OFF_MODE_POWER_OFF_PREPARE handler for the SPI backend. This is not great, but at least avoids regressions and the fix should be small enough to allow backporting. As a side-effect this also works around a shutdown problem on the Asus C201. For reasons unknown that skips calling the prepare handler and directly calls the final shutdown handler. Fixes: 4fec8a5a85c49 ("mfd: rk808: Convert to device managed resources") Cc: stable(a)vger.kernel.org Reported-by: Urja <urja(a)urja.dev> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> --- drivers/mfd/rk8xx-core.c | 15 +++++++++++++-- drivers/mfd/rk8xx-i2c.c | 2 +- drivers/mfd/rk8xx-spi.c | 2 +- include/linux/mfd/rk808.h | 2 +- 4 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/rk8xx-core.c b/drivers/mfd/rk8xx-core.c index 5eda3c0dbbdf..757ef8181328 100644 --- a/drivers/mfd/rk8xx-core.c +++ b/drivers/mfd/rk8xx-core.c @@ -692,10 +692,11 @@ void rk8xx_shutdown(struct device *dev) } EXPORT_SYMBOL_GPL(rk8xx_shutdown); -int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap *regmap) +int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap *regmap, bool is_spi) { struct rk808 *rk808; const struct rk808_reg_data *pre_init_reg; + enum sys_off_mode pwr_off_mode = SYS_OFF_MODE_POWER_OFF; const struct mfd_cell *cells; int dual_support = 0; int nr_pre_init_regs; @@ -785,10 +786,20 @@ int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap if (ret) return dev_err_probe(dev, ret, "failed to add MFD devices\n"); + /* + * Currently the Rockchip SPI driver always sleeps when doing SPI + * transfers. This is not allowed in the SYS_OFF_MODE_POWER_OFF + * handler, so we are using the prepare handler as a workaround. + * This should be removed once the Rockchip SPI driver has been + * adapted. + */ + if (is_spi) + pwr_off_mode = SYS_OFF_MODE_POWER_OFF_PREPARE; + if (device_property_read_bool(dev, "rockchip,system-power-controller") || device_property_read_bool(dev, "system-power-controller")) { ret = devm_register_sys_off_handler(dev, - SYS_OFF_MODE_POWER_OFF_PREPARE, SYS_OFF_PRIO_HIGH, + pwr_off_mode, SYS_OFF_PRIO_HIGH, &rk808_power_off, rk808); if (ret) return dev_err_probe(dev, ret, diff --git a/drivers/mfd/rk8xx-i2c.c b/drivers/mfd/rk8xx-i2c.c index 69a6b297d723..a2029decd654 100644 --- a/drivers/mfd/rk8xx-i2c.c +++ b/drivers/mfd/rk8xx-i2c.c @@ -189,7 +189,7 @@ static int rk8xx_i2c_probe(struct i2c_client *client) return dev_err_probe(&client->dev, PTR_ERR(regmap), "regmap initialization failed\n"); - return rk8xx_probe(&client->dev, data->variant, client->irq, regmap); + return rk8xx_probe(&client->dev, data->variant, client->irq, regmap, false); } static void rk8xx_i2c_shutdown(struct i2c_client *client) diff --git a/drivers/mfd/rk8xx-spi.c b/drivers/mfd/rk8xx-spi.c index 3405fb82ff9f..20f9428f94bb 100644 --- a/drivers/mfd/rk8xx-spi.c +++ b/drivers/mfd/rk8xx-spi.c @@ -94,7 +94,7 @@ static int rk8xx_spi_probe(struct spi_device *spi) return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Failed to init regmap\n"); - return rk8xx_probe(&spi->dev, RK806_ID, spi->irq, regmap); + return rk8xx_probe(&spi->dev, RK806_ID, spi->irq, regmap, true); } static const struct of_device_id rk8xx_spi_of_match[] = { diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h index 69cbea78b430..be15b84cff9e 100644 --- a/include/linux/mfd/rk808.h +++ b/include/linux/mfd/rk808.h @@ -1349,7 +1349,7 @@ struct rk808 { }; void rk8xx_shutdown(struct device *dev); -int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap *regmap); +int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap *regmap, bool is_spi); int rk8xx_suspend(struct device *dev); int rk8xx_resume(struct device *dev); -- 2.43.0

2 months, 2 weeks

6
9
0 0

[PATCH 1/5] HID: wacom: Defer calculation of resolution until resolution_code is known

by Gerecke, Jason

From: Jason Gerecke <jason.gerecke(a)wacom.com> The Wacom driver maps the HID_DG_TWIST usage to ABS_Z (rather than ABS_RZ) for historic reasons. When the code to support twist was introduced in commit 50066a042da5 ("HID: wacom: generic: Add support for height, tilt, and twist usages"), we were careful to write it in such a way that it had HID calculate the resolution of the twist axis assuming ABS_RZ instead (so that we would get correct angular behavior). This was broken with the introduction of commit 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets"), which moved the resolution calculation to occur *before* the adjustment from ABS_Z to ABS_RZ occurred. This commit moves the calculation of resolution after the point that we are finished setting things up for its proper use. Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> Fixes: 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets") Cc: stable(a)vger.kernel.org --- drivers/hid/wacom_wac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c index 1f4564982b958..2541fa2e0fa3b 100644 --- a/drivers/hid/wacom_wac.c +++ b/drivers/hid/wacom_wac.c @@ -1878,12 +1878,14 @@ static void wacom_map_usage(struct input_dev *input, struct hid_usage *usage, int fmax = field->logical_maximum; unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid); int resolution_code = code; - int resolution = hidinput_calc_abs_res(field, resolution_code); + int resolution; if (equivalent_usage == HID_DG_TWIST) { resolution_code = ABS_RZ; } + resolution = hidinput_calc_abs_res(field, resolution_code); + if (equivalent_usage == HID_GD_X) { fmin += features->offset_left; fmax -= features->offset_right; -- 2.45.2

2 months, 2 weeks

3
3
0 0

FAILED: patch "[PATCH] ipv4: fix source address selection with route leak" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 6807352353561187a718e87204458999dbcbba1b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072916-pastrami-suction-5192@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 680735235356 ("ipv4: fix source address selection with route leak") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6807352353561187a718e87204458999dbcbba1b Mon Sep 17 00:00:00 2001 From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Date: Wed, 10 Jul 2024 10:14:27 +0200 Subject: [PATCH] ipv4: fix source address selection with route leak By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address. Let's add a check against the output interface and call the appropriate function to select the source address. CC: stable(a)vger.kernel.org Fixes: 8cbb512c923d ("net: Add source address lookup op for VRF") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://patch.msgid.link/20240710081521.3809742-2-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index f669da98d11d..8956026bc0a2 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -2270,6 +2270,15 @@ void fib_select_path(struct net *net, struct fib_result *res, fib_select_default(fl4, res); check_saddr: - if (!fl4->saddr) - fl4->saddr = fib_result_prefsrc(net, res); + if (!fl4->saddr) { + struct net_device *l3mdev; + + l3mdev = dev_get_by_index_rcu(net, fl4->flowi4_l3mdev); + + if (!l3mdev || + l3mdev_master_dev_rcu(FIB_RES_DEV(*res)) == l3mdev) + fl4->saddr = fib_result_prefsrc(net, res); + else + fl4->saddr = inet_select_addr(l3mdev, 0, RT_SCOPE_LINK); + } }

2 months, 2 weeks

2
1
0 0

[PATCH 1/3] drm/amdgpu: Forward soft recovery errors to userspace

by Joshua Ashton

As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ Signed-off-by: Joshua Ashton <joshua(a)froggi.es> Cc: Friedrich Vock <friedrich.vock(a)gmx.de> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Christian König <christian.koenig(a)amd.com> Cc: André Almeida <andrealmeid(a)igalia.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index 4b3000c21ef2..aebf59855e9f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -262,9 +262,8 @@ amdgpu_job_prepare_job(struct drm_sched_job *sched_job, struct dma_fence *fence = NULL; int r; - /* Ignore soft recovered fences here */ r = drm_sched_entity_error(s_entity); - if (r && r != -ENODATA) + if (r) goto error; if (!fence && job->gang_submit) -- 2.44.0

2 months, 2 weeks

5
10
0 0

[PATCH net v1] net: wan: fsl_qmc_hdlc: Discard received CRC

by Herve Codina

Received frame from QMC contains the CRC. Upper layers don't need this CRC and tcpdump mentioned trailing junk data due to this CRC presence. As some other HDLC driver, simply discard this CRC. Fixes: d0f2258e79fd ("net: wan: Add support for QMC HDLC") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/net/wan/fsl_qmc_hdlc.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/net/wan/fsl_qmc_hdlc.c b/drivers/net/wan/fsl_qmc_hdlc.c index 64b4bfa6fea7..8fcfbde31a1c 100644 --- a/drivers/net/wan/fsl_qmc_hdlc.c +++ b/drivers/net/wan/fsl_qmc_hdlc.c @@ -250,6 +250,7 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl struct qmc_hdlc_desc *desc = context; struct net_device *netdev; struct qmc_hdlc *qmc_hdlc; + size_t crc_size; int ret; netdev = desc->netdev; @@ -268,15 +269,26 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl if (flags & QMC_RX_FLAG_HDLC_CRC) /* CRC error */ netdev->stats.rx_crc_errors++; kfree_skb(desc->skb); - } else { - netdev->stats.rx_packets++; - netdev->stats.rx_bytes += length; + goto re_queue; + } - skb_put(desc->skb, length); - desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); - netif_rx(desc->skb); + /* Discard the CRC */ + crc_size = qmc_hdlc->is_crc32 ? 4 : 2; + if (length < crc_size) { + netdev->stats.rx_length_errors++; + kfree_skb(desc->skb); + goto re_queue; } + length -= crc_size; + + netdev->stats.rx_packets++; + netdev->stats.rx_bytes += length; + + skb_put(desc->skb, length); + desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); + netif_rx(desc->skb); +re_queue: /* Re-queue a transfer using the same descriptor */ ret = qmc_hdlc_recv_queue(qmc_hdlc, desc, desc->dma_size); if (ret) { -- 2.45.0

2 months, 2 weeks

4
3
0 0

[PATCH net 0/7] mptcp: fix endpoints with 'signal' and 'subflow' flags

by Matthieu Baerts (NGI0)

When looking at improving the user experience around the MPTCP endpoints setup, I noticed that setting an endpoint with both the 'signal' and the 'subflow' flags -- as it has been done in the past by users according to bug reports we got -- was resulting on only announcing the endpoint, but not using it to create subflows: the 'subflow' flag was then ignored. My initial thought was to modify IPRoute2 to warn the user when the two flags were set, but it doesn't sound normal to ignore one of them. I then looked at modifying the kernel not to allow having the two flags set, but when discussing about that with Mat, we thought it was maybe not ideal to do that, as there might be use-cases, we might break some configs. Then I saw it was working before v5.17. So instead, I fixed the support on the kernel side (patch 5) using Paolo's suggestion. This also includes a fix on the options side (patch 1: for v5.11+), an explicit deny of some options combinations (patch 2: for v5.18+), and some refactoring (patches 3 and 4) to ease the inclusion of the patch 5. While at it, I added a new selftest (patch 7) to validate this case -- including a modification of the chk_add_nr helper to inverse the sides were the counters are checked (patch 6) -- and allowed ADD_ADDR echo just after the MP_JOIN 3WHS. The selftests modification have the same Fixes tag as the previous commit, but no 'Cc: Stable': if the backport can work, that's good -- but it still need to be verified by running the selftests -- if not, no need to worry, many CIs will use the selftests from the last stable version to validate previous stable releases. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (7): mptcp: fully established after ADD_ADDR echo on MPJ mptcp: pm: deny endp with signal + subflow + port mptcp: pm: reduce indentation blocks mptcp: pm: don't try to create sf if alloc failed mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set selftests: mptcp: join: ability to invert ADD_ADDR check selftests: mptcp: join: test both signal & subflow net/mptcp/options.c | 3 +- net/mptcp/pm_netlink.c | 47 +++++++++++++-------- tools/testing/selftests/net/mptcp/mptcp_join.sh | 55 ++++++++++++++++++------- 3 files changed, 73 insertions(+), 32 deletions(-) --- base-commit: 0bf50cead4c4710d9f704778c32ab8af47ddf070 change-id: 20240731-upstream-net-20240731-mptcp-endp-subflow-signal-181d640cf5e8 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 months, 2 weeks

2
5
0 0

[PATCH iwl-net 2/3] idpf: fix memleak in vport interrupt configuration

by Alexander Lobakin

From: Michal Kubiak <michal.kubiak(a)intel.com> The initialization of vport interrupt consists of two functions: 1) idpf_vport_intr_init() where a generic configuration is done 2) idpf_vport_intr_req_irq() where the irq for each q_vector is requested. The first function used to create a base name for each interrupt using "kasprintf()" call. Unfortunately, although that call allocated memory for a text buffer, that memory was never released. Fix this by removing creating the interrupt base name in 1). Instead, always create a full interrupt name in the function 2), because there is no need to create a base name separately, considering that the function 2) is never called out of idpf_vport_intr_init() context. Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Cc: stable(a)vger.kernel.org # 6.7 Signed-off-by: Michal Kubiak <michal.kubiak(a)intel.com> Reviewed-by: Pavan Kumar Linga <pavan.kumar.linga(a)intel.com> Signed-off-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> --- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index af2879f03b8d..a2f9f252694a 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -3780,13 +3780,15 @@ void idpf_vport_intr_update_itr_ena_irq(struct idpf_q_vector *q_vector) /** * idpf_vport_intr_req_irq - get MSI-X vectors from the OS for the vport * @vport: main vport structure - * @basename: name for the vector */ -static int idpf_vport_intr_req_irq(struct idpf_vport *vport, char *basename) +static int idpf_vport_intr_req_irq(struct idpf_vport *vport) { struct idpf_adapter *adapter = vport->adapter; + const char *drv_name, *if_name, *vec_name; int vector, err, irq_num, vidx; - const char *vec_name; + + drv_name = dev_driver_string(&adapter->pdev->dev); + if_name = netdev_name(vport->netdev); for (vector = 0; vector < vport->num_q_vectors; vector++) { struct idpf_q_vector *q_vector = &vport->q_vectors[vector]; @@ -3804,8 +3806,8 @@ static int idpf_vport_intr_req_irq(struct idpf_vport *vport, char *basename) else continue; - name = kasprintf(GFP_KERNEL, "%s-%s-%d", basename, vec_name, - vidx); + name = kasprintf(GFP_KERNEL, "%s-%s-%s-%d", drv_name, if_name, + vec_name, vidx); err = request_irq(irq_num, idpf_vport_intr_clean_queues, 0, name, q_vector); @@ -4326,7 +4328,6 @@ int idpf_vport_intr_alloc(struct idpf_vport *vport) */ int idpf_vport_intr_init(struct idpf_vport *vport) { - char *int_name; int err; err = idpf_vport_intr_init_vec_idx(vport); @@ -4340,11 +4341,7 @@ int idpf_vport_intr_init(struct idpf_vport *vport) if (err) goto unroll_vectors_alloc; - int_name = kasprintf(GFP_KERNEL, "%s-%s", - dev_driver_string(&vport->adapter->pdev->dev), - vport->netdev->name); - - err = idpf_vport_intr_req_irq(vport, int_name); + err = idpf_vport_intr_req_irq(vport); if (err) goto unroll_vectors_alloc; -- 2.45.2

2 months, 2 weeks

3
2
0 0

[PATCH v4 0/2] Rust and the shadow call stack sanitizer

by Alice Ryhl

This patch series makes it possible to use Rust together with the shadow call stack sanitizer. The first patch is intended to be backported to ensure that people don't try to use SCS with Rust on older kernel versions. The second patch makes it possible to use Rust with the shadow call stack sanitizer. The second patch in this series depends on the next version of [1], which Miguel will send soon. Link: https://lore.kernel.org/rust-for-linux/20240709160615.998336-12-ojeda@kerne… [1] Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- Changes in v4: - Move `depends on` to CONFIG_RUST. - Rewrite commit messages to include more context. - Link to v3: https://lore.kernel.org/r/20240704-shadow-call-stack-v3-0-d11c7a6ebe30@goog… Changes in v3: - Use -Zfixed-x18. - Add logic to reject unsupported rustc versions. - Also include a fix to be backported. - Link to v2: https://lore.kernel.org/rust-for-linux/20240305-shadow-call-stack-v2-1-c7b4… Changes in v2: - Add -Cforce-unwind-tables flag. - Link to v1: https://lore.kernel.org/rust-for-linux/20240304-shadow-call-stack-v1-1-f055… --- Alice Ryhl (2): rust: SHADOW_CALL_STACK is incompatible with Rust rust: support for shadow call stack sanitizer Makefile | 1 + arch/arm64/Makefile | 3 +++ init/Kconfig | 1 + 3 files changed, 5 insertions(+) --- base-commit: 9cde54ad2f7ac3cf84f65df605570c5a00afc82f change-id: 20240304-shadow-call-stack-9c197a4361d9 Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

2 months, 2 weeks

3
3
0 0

[PATCH v2 0/2] media: imx335: Fix reset-gpio handling

by Umang Jain

These couple of patches intends to fix the reset-gpio handling for imx335 driver. Patch 1/2 mentions reset-gpio polarity in DT binding example. It is ACTIVE_LOW according to the data sheet. Patch 2/2 fixes the logical value of reset-gpio during power-on/power-off sequence. -- Changes in v2: - Also include reset-gpio polarity, mention in DT binding - Add Fixes tag in 2/2 - Set the reset line to high during init time in 2/2 Link to v1: https://lore.kernel.org/linux-media/tyo5etjwsfznuk6vzwqmcphbu4pz4lskrg3fjie… Umang Jain (2): dt-bindings: imx335: Mention reset-gpio polarity media: imx335: Fix reset-gpio handling .../devicetree/bindings/media/i2c/sony,imx335.yaml | 2 ++ drivers/media/i2c/imx335.c | 8 ++++---- 2 files changed, 6 insertions(+), 4 deletions(-) -- 2.45.0

2 months, 2 weeks

6
19
0 0

[PATCH V3 0/8] Add camera clock controller support for SM8150

by Satya Priya Kakitapalli

Add camcc support and Regera PLL ops. Also, fix the pll post div mask. Changes in V3: - Split the fixes into separate patches, remove RETAIN_FF flag for gdscs and document the BIT(15) of pll alpha value. - Link to v2: https://lore.kernel.org/all/20240702-camcc-support-sm8150-v2-1-4baf54ec7333… Changes in v2: - As per Konrad's comments, re-use the zonda pll code for regera, as both are mostly same. - Fix the zonda_set_rate API and also the pll_post_div shift used in trion pll post div set rate API - Link to v1: https://lore.kernel.org/r/20240229-camcc-support-sm8150-v1-0-8c28c6c87990@q… Satya Priya Kakitapalli (7): clk: qcom: clk-alpha-pll: Fix the pll post div mask clk: qcom: clk-alpha-pll: Fix the trion pll postdiv set rate API clk: qcom: clk-alpha-pll: Fix zonda set_rate failure when PLL is disabled clk: qcom: clk-alpha-pll: Update set_rate for Zonda PLL dt-bindings: clock: qcom: Add SM8150 camera clock controller clk: qcom: Add camera clock controller driver for SM8150 arm64: dts: qcom: Add camera clock controller for sm8150 Taniya Das (1): clk: qcom: clk-alpha-pll: Add support for Regera PLL ops .../bindings/clock/qcom,sm8150-camcc.yaml | 77 + arch/arm64/boot/dts/qcom/sa8155p.dtsi | 4 + arch/arm64/boot/dts/qcom/sm8150.dtsi | 13 + drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/camcc-sm8150.c | 2159 +++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.c | 57 +- drivers/clk/qcom/clk-alpha-pll.h | 5 + include/dt-bindings/clock/qcom,sm8150-camcc.h | 135 ++ 9 files changed, 2456 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/qcom,sm8150-camcc.yaml create mode 100644 drivers/clk/qcom/camcc-sm8150.c create mode 100644 include/dt-bindings/clock/qcom,sm8150-camcc.h -- 2.25.1

2 months, 2 weeks

4
15
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024