December 2023 - Linux-stable-mirror

[PATCH v2 3/3] arm64: dts: armada-3720-turris-mox: set irq type for RTC

by Sjoerd Simons

The rtc on the mox shares its interrupt line with the moxtet bus. Set the interrupt type to be consistent between both devices. This ensures correct setup of the interrupt line regardless of probing order. Signed-off-by: Sjoerd Simons <sjoerd(a)collabora.com> Cc: stable(a)vger.kernel.org # v6.2+ Fixes: 21aad8ba615e ("arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC") --- (no changes since v1) arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts index 9eab2bb22134..805ef2d79b40 100644 --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts @@ -130,7 +130,7 @@ rtc@6f { compatible = "microchip,mcp7940x"; reg = <0x6f>; interrupt-parent = <&gpiosb>; - interrupts = <5 0>; /* GPIO2_5 */ + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; /* GPIO2_5 */ }; }; -- 2.43.0

2 years

2
1
0 0

[PATCH v2 2/3] bus: moxtet: Add spi device table

by Sjoerd Simons

The moxtet module fails to auto-load on. Add a SPI id table to allow it to do so. Signed-off-by: Sjoerd Simons <sjoerd(a)collabora.com> Cc: stable(a)vger.kernel.org --- (no changes since v1) drivers/bus/moxtet.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c index 48c18f95660a..e384fbc6c1d9 100644 --- a/drivers/bus/moxtet.c +++ b/drivers/bus/moxtet.c @@ -830,6 +830,12 @@ static void moxtet_remove(struct spi_device *spi) mutex_destroy(&moxtet->lock); } +static const struct spi_device_id moxtet_spi_ids[] = { + { "moxtet" }, + { }, +}; +MODULE_DEVICE_TABLE(spi, moxtet_spi_ids); + static const struct of_device_id moxtet_dt_ids[] = { { .compatible = "cznic,moxtet" }, {}, @@ -841,6 +847,7 @@ static struct spi_driver moxtet_spi_driver = { .name = "moxtet", .of_match_table = moxtet_dt_ids, }, + .id_table = moxtet_spi_ids, .probe = moxtet_probe, .remove = moxtet_remove, }; -- 2.43.0

2 years

2
1
0 0

[PATCH v2 1/3] bus: moxtet: Mark the irq as shared

by Sjoerd Simons

The Turris Mox shares the moxtet IRQ with various devices on the board, so mark the IRQ as shared in the driver as well. Without this loading the module will fail with: genirq: Flags mismatch irq 40. 00002002 (moxtet) vs. 00002080 (mcp7940x) Signed-off-by: Sjoerd Simons <sjoerd(a)collabora.com> Cc: stable(a)vger.kernel.org # v6.2+ --- (no changes since v1) drivers/bus/moxtet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c index 5eb0fe73ddc4..48c18f95660a 100644 --- a/drivers/bus/moxtet.c +++ b/drivers/bus/moxtet.c @@ -755,7 +755,7 @@ static int moxtet_irq_setup(struct moxtet *moxtet) moxtet->irq.masked = ~0; ret = request_threaded_irq(moxtet->dev_irq, NULL, moxtet_irq_thread_fn, - IRQF_ONESHOT, "moxtet", moxtet); + IRQF_SHARED | IRQF_ONESHOT, "moxtet", moxtet); if (ret < 0) goto err_free; -- 2.43.0

2 years

2
1
0 0

[PATCH] drm/amd/display: fix hw rotated modes when PSR-SU is enabled

by Hamza Mahfooz

We currently don't support dirty rectangles on hardware rotated modes. So, if a user is using hardware rotated modes with PSR-SU enabled, use PSR-SU FFU for all rotated planes (including cursor planes). Cc: stable(a)vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2952 Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++++ drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 1 + drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c | 12 ++++++++++-- .../gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 3 ++- 4 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index c146dc9cba92..79f8102d2601 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5208,6 +5208,7 @@ static void fill_dc_dirty_rects(struct drm_plane *plane, bool bb_changed; bool fb_changed; u32 i = 0; + *dirty_regions_changed = false; /* @@ -5217,6 +5218,9 @@ static void fill_dc_dirty_rects(struct drm_plane *plane, if (plane->type == DRM_PLANE_TYPE_CURSOR) return; + if (new_plane_state->rotation != DRM_MODE_ROTATE_0) + goto ffu; + num_clips = drm_plane_get_damage_clips_count(new_plane_state); clips = drm_plane_get_damage_clips(new_plane_state); diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h index 9649934ea186..e2a3aa8812df 100644 --- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h +++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h @@ -465,6 +465,7 @@ struct dc_cursor_mi_param { struct fixed31_32 v_scale_ratio; enum dc_rotation_angle rotation; bool mirror; + struct dc_stream_state *stream; }; /* IPP related types */ diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c index 139cf31d2e45..89c3bf0fe0c9 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c @@ -1077,8 +1077,16 @@ void hubp2_cursor_set_position( if (src_y_offset < 0) src_y_offset = 0; /* Save necessary cursor info x, y position. w, h is saved in attribute func. */ - hubp->cur_rect.x = src_x_offset + param->viewport.x; - hubp->cur_rect.y = src_y_offset + param->viewport.y; + if (param->stream->link->psr_settings.psr_version >= DC_PSR_VERSION_SU_1 && + param->rotation != ROTATION_ANGLE_0) { + hubp->cur_rect.x = 0; + hubp->cur_rect.y = 0; + hubp->cur_rect.w = param->stream->timing.h_addressable; + hubp->cur_rect.h = param->stream->timing.v_addressable; + } else { + hubp->cur_rect.x = src_x_offset + param->viewport.x; + hubp->cur_rect.y = src_y_offset + param->viewport.y; + } } void hubp2_clk_cntl(struct hubp *hubp, bool enable) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c index 2b8b8366538e..ce5613a76267 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c @@ -3417,7 +3417,8 @@ void dcn10_set_cursor_position(struct pipe_ctx *pipe_ctx) .h_scale_ratio = pipe_ctx->plane_res.scl_data.ratios.horz, .v_scale_ratio = pipe_ctx->plane_res.scl_data.ratios.vert, .rotation = pipe_ctx->plane_state->rotation, - .mirror = pipe_ctx->plane_state->horizontal_mirror + .mirror = pipe_ctx->plane_state->horizontal_mirror, + .stream = pipe_ctx->stream }; bool pipe_split_on = false; bool odm_combine_on = (pipe_ctx->next_odm_pipe != NULL) || -- 2.43.0

2 years

3
7
0 0

Re: [PATCH] drm/amd/display: fix hw rotated modes when PSR-SU is enabled

by Bin Li

Hi Mario, It's a false alarm from my side, after testing the 6.1.0-oem and 6.5.0-oem kernels, this patch works perfectly fine, sorry about that. On Thu, Dec 7, 2023 at 3:47 PM Bin Li <binli(a)gnome.org> wrote: > > Hi Mario, > > I found I missed the part in drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c with kai.heng's review. > I will rebuild a new kernel and test it again, and reply later, sorry about that. > > > > On Thu, Dec 7, 2023 at 2:58 PM Kai-Heng Feng <kai.heng.feng(a)canonical.com> wrote: >> >> On Thu, Dec 7, 2023 at 10:10 AM Mario Limonciello >> <mario.limonciello(a)amd.com> wrote: >> > >> > On 12/6/2023 20:07, Kai-Heng Feng wrote: >> > > On Thu, Dec 7, 2023 at 9:57 AM Mario Limonciello >> > > <mario.limonciello(a)amd.com> wrote: >> > >> >> > >> On 12/6/2023 19:23, Kai-Heng Feng wrote: >> > >>> On Wed, Dec 6, 2023 at 4:29 AM Mario Limonciello >> > >>> <mario.limonciello(a)amd.com> wrote: >> > >>>> >> > >>>> On 12/5/2023 14:17, Hamza Mahfooz wrote: >> > >>>>> We currently don't support dirty rectangles on hardware rotated modes. >> > >>>>> So, if a user is using hardware rotated modes with PSR-SU enabled, >> > >>>>> use PSR-SU FFU for all rotated planes (including cursor planes). >> > >>>>> >> > >>>> >> > >>>> Here is the email for the original reporter to give an attribution tag. >> > >>>> >> > >>>> Reported-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> >> > >>> >> > >>> For this particular issue, >> > >>> Tested-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> >> > >> >> > >> Can you confirm what kernel base you tested issue against? >> > >> >> > >> I ask because Bin Li (+CC) also tested it against 6.1 based LTS kernel >> > >> but ran into problems. >> > > >> > > The patch was tested against ADSN. >> > > >> > >> >> > >> I wonder if it's because of other dependency patches. If that's the >> > >> case it would be good to call them out in the Cc: @stable as >> > >> dependencies so when Greg or Sasha backport this 6.1 doesn't get broken. >> > > >> > > Probably. I haven't really tested any older kernel series. >> > >> > Since you've got a good environment to test it and reproduce it would >> > you mind double checking it against 6.7-rc, 6.5 and 6.1 trees? If we >> > don't have confidence it works on the older trees I think we'll need to >> > drop the stable tag. >> >> Not seeing issues here when the patch is applied against 6.5 and 6.1 >> (which needs to resolve a minor conflict). >> >> I am not sure what happened for Bin's case. >> >> Kai-Heng >> >> > > >> > > Kai-Heng >> > > >> > >> >> > >> Bin, >> > >> >> > >> Could you run ./scripts/decode_stacktrace.sh on your kernel trace to >> > >> give us a specific line number on the issue you hit? >> > >> >> > >> Thanks! >> > >>> >> > >>>> >> > >>>>> Cc: stable(a)vger.kernel.org >> > >>>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2952 >> > >>>>> Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") >> > >>>>> Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> >> > >>>>> --- >> > >>>>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++++ >> > >>>>> drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 1 + >> > >>>>> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c | 12 ++++++++++-- >> > >>>>> .../gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 3 ++- >> > >>>>> 4 files changed, 17 insertions(+), 3 deletions(-) >> > >>>>> >> > >>>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> > >>>>> index c146dc9cba92..79f8102d2601 100644 >> > >>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> > >>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> > >>>>> @@ -5208,6 +5208,7 @@ static void fill_dc_dirty_rects(struct drm_plane *plane, >> > >>>>> bool bb_changed; >> > >>>>> bool fb_changed; >> > >>>>> u32 i = 0; >> > >>>>> + >> > >>>> >> > >>>> Looks like a spurious newline here. >> > >>>> >> > >>>>> *dirty_regions_changed = false; >> > >>>>> >> > >>>>> /* >> > >>>>> @@ -5217,6 +5218,9 @@ static void fill_dc_dirty_rects(struct drm_plane *plane, >> > >>>>> if (plane->type == DRM_PLANE_TYPE_CURSOR) >> > >>>>> return; >> > >>>>> >> > >>>>> + if (new_plane_state->rotation != DRM_MODE_ROTATE_0) >> > >>>>> + goto ffu; >> > >>>>> + >> > >>>> >> > >>>> I noticed that the original report was specifically on 180°. Since >> > >>>> you're also covering 90° and 270° with this check it sounds like it's >> > >>>> actually problematic on those too? >> > >>> >> > >>> 90 & 270 are problematic too. But from what I observed the issue is >> > >>> much more than just cursors. >> > >> >> > >> Got it; thanks. >> > >> >> > >>> >> > >>> Kai-Heng >> > >>> >> > >>>> >> > >>>>> num_clips = drm_plane_get_damage_clips_count(new_plane_state); >> > >>>>> clips = drm_plane_get_damage_clips(new_plane_state); >> > >>>>> >> > >>>>> diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h >> > >>>>> index 9649934ea186..e2a3aa8812df 100644 >> > >>>>> --- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h >> > >>>>> +++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h >> > >>>>> @@ -465,6 +465,7 @@ struct dc_cursor_mi_param { >> > >>>>> struct fixed31_32 v_scale_ratio; >> > >>>>> enum dc_rotation_angle rotation; >> > >>>>> bool mirror; >> > >>>>> + struct dc_stream_state *stream; >> > >>>>> }; >> > >>>>> >> > >>>>> /* IPP related types */ >> > >>>>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c >> > >>>>> index 139cf31d2e45..89c3bf0fe0c9 100644 >> > >>>>> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c >> > >>>>> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c >> > >>>>> @@ -1077,8 +1077,16 @@ void hubp2_cursor_set_position( >> > >>>>> if (src_y_offset < 0) >> > >>>>> src_y_offset = 0; >> > >>>>> /* Save necessary cursor info x, y position. w, h is saved in attribute func. */ >> > >>>>> - hubp->cur_rect.x = src_x_offset + param->viewport.x; >> > >>>>> - hubp->cur_rect.y = src_y_offset + param->viewport.y; >> > >>>>> + if (param->stream->link->psr_settings.psr_version >= DC_PSR_VERSION_SU_1 && >> > >>>>> + param->rotation != ROTATION_ANGLE_0) { >> > >>>> >> > >>>> Ditto on above about 90° and 270°. >> > >>>> >> > >>>>> + hubp->cur_rect.x = 0; >> > >>>>> + hubp->cur_rect.y = 0; >> > >>>>> + hubp->cur_rect.w = param->stream->timing.h_addressable; >> > >>>>> + hubp->cur_rect.h = param->stream->timing.v_addressable; >> > >>>>> + } else { >> > >>>>> + hubp->cur_rect.x = src_x_offset + param->viewport.x; >> > >>>>> + hubp->cur_rect.y = src_y_offset + param->viewport.y; >> > >>>>> + } >> > >>>>> } >> > >>>>> >> > >>>>> void hubp2_clk_cntl(struct hubp *hubp, bool enable) >> > >>>>> diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c >> > >>>>> index 2b8b8366538e..ce5613a76267 100644 >> > >>>>> --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c >> > >>>>> +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c >> > >>>>> @@ -3417,7 +3417,8 @@ void dcn10_set_cursor_position(struct pipe_ctx *pipe_ctx) >> > >>>>> .h_scale_ratio = pipe_ctx->plane_res.scl_data.ratios.horz, >> > >>>>> .v_scale_ratio = pipe_ctx->plane_res.scl_data.ratios.vert, >> > >>>>> .rotation = pipe_ctx->plane_state->rotation, >> > >>>>> - .mirror = pipe_ctx->plane_state->horizontal_mirror >> > >>>>> + .mirror = pipe_ctx->plane_state->horizontal_mirror, >> > >>>>> + .stream = pipe_ctx->stream >> > >>>> >> > >>>> As a nit; I think it's worth leaving a harmless trailing ',' so that >> > >>>> there is less ping pong in the future when adding new members to a struct. >> > >>>> >> > >>>>> }; >> > >>>>> bool pipe_split_on = false; >> > >>>>> bool odm_combine_on = (pipe_ctx->next_odm_pipe != NULL) || >> > >>>> >> > >>>> >> > >> >> >

2 years

2
1
0 0

[PATCHv4] mmc: rpmb: fixes pause retune on all RPMB partitions.

by Jorge Ramirez-Ortiz

When RPMB was converted to a character device, it added support for multiple RPMB partitions (Commit 97548575bef3 ("mmc: block: Convert RPMB to a character device"). One of the changes in this commit was transforming the variable target_part defined in __mmc_blk_ioctl_cmd into a bitmask. This inadvertedly regressed the validation check done in mmc_blk_part_switch_pre() and mmc_blk_part_switch_post(). This commit fixes that regression. Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Cc: <stable(a)vger.kernel.org> # v4.14+ --- v2: fixes parenthesis around condition v3: adds stable to commit header v4: fixes the stable version to v4.14 adds Reviewed-by drivers/mmc/core/block.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 152dfe593c43..13093d26bf81 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -851,9 +851,10 @@ static const struct block_device_operations mmc_bdops = { static int mmc_blk_part_switch_pre(struct mmc_card *card, unsigned int part_type) { + const unsigned int mask = EXT_CSD_PART_CONFIG_ACC_RPMB; int ret = 0; - if (part_type == EXT_CSD_PART_CONFIG_ACC_RPMB) { + if ((part_type & mask) == mask) { if (card->ext_csd.cmdq_en) { ret = mmc_cmdq_disable(card); if (ret) @@ -868,9 +869,10 @@ static int mmc_blk_part_switch_pre(struct mmc_card *card, static int mmc_blk_part_switch_post(struct mmc_card *card, unsigned int part_type) { + const unsigned int mask = EXT_CSD_PART_CONFIG_ACC_RPMB; int ret = 0; - if (part_type == EXT_CSD_PART_CONFIG_ACC_RPMB) { + if ((part_type & mask) == mask) { mmc_retune_unpause(card->host); if (card->reenable_cmdq && !card->ext_csd.cmdq_en) ret = mmc_cmdq_enable(card); @@ -3143,4 +3145,3 @@ module_exit(mmc_blk_exit); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Multimedia Card (MMC) block device driver"); - -- 2.34.1

2 years

2
1
0 0

[PATCH net] nfp: flower: fix for take a mutex lock in soft irq context and rcu lock

by Louis Peens

From: Hui Zhou <hui.zhou(a)corigine.com> The neighbour event callback call the function nfp_tun_write_neigh, this function will take a mutex lock and it is in soft irq context, change the work queue to process the neighbour event. Move the nfp_tun_write_neigh function out of range rcu_read_lock/unlock() in function nfp_tunnel_request_route_v4 and nfp_tunnel_request_route_v6. Fixes: abc210952af7 ("nfp: flower: tunnel neigh support bond offload") CC: stable(a)vger.kernel.org # 6.2+ Signed-off-by: Hui Zhou <hui.zhou(a)corigine.com> Signed-off-by: Louis Peens <louis.peens(a)corigine.com> --- .../netronome/nfp/flower/tunnel_conf.c | 127 +++++++++++++----- 1 file changed, 95 insertions(+), 32 deletions(-) diff --git a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c index 060a77f2265d..e522845c7c21 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c +++ b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c @@ -160,6 +160,18 @@ struct nfp_tun_mac_addr_offload { u8 addr[ETH_ALEN]; }; +/** + * struct nfp_neigh_update_work - update neighbour information to nfp + * @work: Work queue for writing neigh to the nfp + * @n: neighbour entry + * @app: Back pointer to app + */ +struct nfp_neigh_update_work { + struct work_struct work; + struct neighbour *n; + struct nfp_app *app; +}; + enum nfp_flower_mac_offload_cmd { NFP_TUNNEL_MAC_OFFLOAD_ADD = 0, NFP_TUNNEL_MAC_OFFLOAD_DEL = 1, @@ -607,38 +619,30 @@ nfp_tun_write_neigh(struct net_device *netdev, struct nfp_app *app, nfp_flower_cmsg_warn(app, "Neighbour configuration failed.\n"); } -static int -nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event, - void *ptr) +static void +nfp_tun_release_neigh_update_work(struct nfp_neigh_update_work *update_work) { - struct nfp_flower_priv *app_priv; - struct netevent_redirect *redir; - struct neighbour *n; + neigh_release(update_work->n); + kfree(update_work); +} + +static void nfp_tun_neigh_update(struct work_struct *work) +{ + struct nfp_neigh_update_work *update_work; struct nfp_app *app; + struct neighbour *n; bool neigh_invalid; int err; - switch (event) { - case NETEVENT_REDIRECT: - redir = (struct netevent_redirect *)ptr; - n = redir->neigh; - break; - case NETEVENT_NEIGH_UPDATE: - n = (struct neighbour *)ptr; - break; - default: - return NOTIFY_DONE; - } - - neigh_invalid = !(n->nud_state & NUD_VALID) || n->dead; - - app_priv = container_of(nb, struct nfp_flower_priv, tun.neigh_nb); - app = app_priv->app; + update_work = container_of(work, struct nfp_neigh_update_work, work); + app = update_work->app; + n = update_work->n; if (!nfp_flower_get_port_id_from_netdev(app, n->dev)) - return NOTIFY_DONE; + goto out; #if IS_ENABLED(CONFIG_INET) + neigh_invalid = !(n->nud_state & NUD_VALID) || n->dead; if (n->tbl->family == AF_INET6) { #if IS_ENABLED(CONFIG_IPV6) struct flowi6 flow6 = {}; @@ -655,13 +659,11 @@ nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event, dst = ip6_dst_lookup_flow(dev_net(n->dev), NULL, &flow6, NULL); if (IS_ERR(dst)) - return NOTIFY_DONE; + goto out; dst_release(dst); } nfp_tun_write_neigh(n->dev, app, &flow6, n, true, false); -#else - return NOTIFY_DONE; #endif /* CONFIG_IPV6 */ } else { struct flowi4 flow4 = {}; @@ -678,17 +680,71 @@ nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event, rt = ip_route_output_key(dev_net(n->dev), &flow4); err = PTR_ERR_OR_ZERO(rt); if (err) - return NOTIFY_DONE; + goto out; ip_rt_put(rt); } nfp_tun_write_neigh(n->dev, app, &flow4, n, false, false); } -#else - return NOTIFY_DONE; #endif /* CONFIG_INET */ +out: + nfp_tun_release_neigh_update_work(update_work); +} - return NOTIFY_OK; +static struct nfp_neigh_update_work * +nfp_tun_alloc_neigh_update_work(struct nfp_app *app, struct neighbour *n) +{ + struct nfp_neigh_update_work *update_work; + + update_work = kzalloc(sizeof(*update_work), GFP_ATOMIC); + if (!update_work) + return NULL; + + INIT_WORK(&update_work->work, nfp_tun_neigh_update); + neigh_hold(n); + update_work->n = n; + update_work->app = app; + + return update_work; +} + +static int +nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event, + void *ptr) +{ + struct nfp_neigh_update_work *update_work; + struct nfp_flower_priv *app_priv; + struct netevent_redirect *redir; + struct neighbour *n; + struct nfp_app *app; + + switch (event) { + case NETEVENT_REDIRECT: + redir = (struct netevent_redirect *)ptr; + n = redir->neigh; + break; + case NETEVENT_NEIGH_UPDATE: + n = (struct neighbour *)ptr; + break; + default: + return NOTIFY_DONE; + } +#if IS_ENABLED(CONFIG_IPV6) + if (n->tbl != ipv6_stub->nd_tbl && n->tbl != &arp_tbl) +#else + if (n->tbl != &arp_tbl) +#endif + return NOTIFY_DONE; + + app_priv = container_of(nb, struct nfp_flower_priv, tun.neigh_nb); + app = app_priv->app; + update_work = nfp_tun_alloc_neigh_update_work(app, n); + if (!update_work) + return NOTIFY_DONE; + + queue_work(system_highpri_wq, &update_work->work); + + return NOTIFY_DONE; } void nfp_tunnel_request_route_v4(struct nfp_app *app, struct sk_buff *skb) @@ -706,6 +762,7 @@ void nfp_tunnel_request_route_v4(struct nfp_app *app, struct sk_buff *skb) netdev = nfp_app_dev_get(app, be32_to_cpu(payload->ingress_port), NULL); if (!netdev) goto fail_rcu_unlock; + dev_hold(netdev); flow.daddr = payload->ipv4_addr; flow.flowi4_proto = IPPROTO_UDP; @@ -725,13 +782,16 @@ void nfp_tunnel_request_route_v4(struct nfp_app *app, struct sk_buff *skb) ip_rt_put(rt); if (!n) goto fail_rcu_unlock; + rcu_read_unlock(); + nfp_tun_write_neigh(n->dev, app, &flow, n, false, true); neigh_release(n); - rcu_read_unlock(); + dev_put(netdev); return; fail_rcu_unlock: rcu_read_unlock(); + dev_put(netdev); nfp_flower_cmsg_warn(app, "Requested route not found.\n"); } @@ -749,6 +809,7 @@ void nfp_tunnel_request_route_v6(struct nfp_app *app, struct sk_buff *skb) netdev = nfp_app_dev_get(app, be32_to_cpu(payload->ingress_port), NULL); if (!netdev) goto fail_rcu_unlock; + dev_hold(netdev); flow.daddr = payload->ipv6_addr; flow.flowi6_proto = IPPROTO_UDP; @@ -766,14 +827,16 @@ void nfp_tunnel_request_route_v6(struct nfp_app *app, struct sk_buff *skb) dst_release(dst); if (!n) goto fail_rcu_unlock; + rcu_read_unlock(); nfp_tun_write_neigh(n->dev, app, &flow, n, true, true); neigh_release(n); - rcu_read_unlock(); + dev_put(netdev); return; fail_rcu_unlock: rcu_read_unlock(); + dev_put(netdev); nfp_flower_cmsg_warn(app, "Requested IPv6 route not found.\n"); } -- 2.34.1

2 years

2
1
0 0

[PATCH] wifi: mwifiex: fix STA cannot connect to AP

by David Lin

AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly. Signed-off-by: David Lin <yu-hao.lin(a)nxp.com> Fixes: 277b024e5e3d ("mwifiex: move under marvell vendor directory") Cc: stable(a)vger.kernel.org --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 7a15ea8072e6..3604abcbcff9 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -2047,6 +2047,8 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy, mwifiex_set_sys_config_invalid_data(bss_cfg); + memcpy(bss_cfg->mac_addr, priv->curr_addr, ETH_ALEN); + if (params->beacon_interval) bss_cfg->beacon_period = params->beacon_interval; if (params->dtim_period) diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h index 8e6db904e5b2..62f3c9a52a1d 100644 --- a/drivers/net/wireless/marvell/mwifiex/fw.h +++ b/drivers/net/wireless/marvell/mwifiex/fw.h @@ -165,6 +165,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER { #define TLV_TYPE_STA_MAC_ADDR (PROPRIETARY_TLV_BASE_ID + 32) #define TLV_TYPE_BSSID (PROPRIETARY_TLV_BASE_ID + 35) #define TLV_TYPE_CHANNELBANDLIST (PROPRIETARY_TLV_BASE_ID + 42) +#define TLV_TYPE_UAP_MAC_ADDRESS (PROPRIETARY_TLV_BASE_ID + 43) #define TLV_TYPE_UAP_BEACON_PERIOD (PROPRIETARY_TLV_BASE_ID + 44) #define TLV_TYPE_UAP_DTIM_PERIOD (PROPRIETARY_TLV_BASE_ID + 45) #define TLV_TYPE_UAP_BCAST_SSID (PROPRIETARY_TLV_BASE_ID + 48) diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h b/drivers/net/wireless/marvell/mwifiex/ioctl.h index 091e7ca79376..8be3a2714bf7 100644 --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h @@ -83,6 +83,7 @@ struct wep_key { #define MWIFIEX_OPERATING_CLASSES 16 struct mwifiex_uap_bss_param { + u8 mac_addr[ETH_ALEN]; u8 channel; u8 band_cfg; u16 rts_threshold; diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c index e78a201cd150..491e36611909 100644 --- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c @@ -468,6 +468,7 @@ void mwifiex_config_uap_11d(struct mwifiex_private *priv, static int mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) { + struct host_cmd_tlv_mac_addr *mac_tlv; struct host_cmd_tlv_dtim_period *dtim_period; struct host_cmd_tlv_beacon_period *beacon_period; struct host_cmd_tlv_ssid *ssid; @@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) int i; u16 cmd_size = *param_size; + mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv; + mac_tlv->header.type = cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS); + mac_tlv->header.len = cpu_to_le16(ETH_ALEN); + memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN); + cmd_size += sizeof(struct host_cmd_tlv_mac_addr); + tlv += sizeof(struct host_cmd_tlv_mac_addr); + if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID); base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c -- 2.25.1

2 years

1
0
0 0

[PATCH] wifi: mwifiex: fix STA cannot connect to AP

by David Lin

AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly. Signed-off-by: David Lin <yu-hao.lin(a)nxp.com> Fixes: 277b024e5e3d ("mwifiex: move under marvell vendor directory") Cc: stable(a)vger.kernel.org --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 7a15ea8072e6..3604abcbcff9 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -2047,6 +2047,8 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy, mwifiex_set_sys_config_invalid_data(bss_cfg); + memcpy(bss_cfg->mac_addr, priv->curr_addr, ETH_ALEN); + if (params->beacon_interval) bss_cfg->beacon_period = params->beacon_interval; if (params->dtim_period) diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h index 8e6db904e5b2..62f3c9a52a1d 100644 --- a/drivers/net/wireless/marvell/mwifiex/fw.h +++ b/drivers/net/wireless/marvell/mwifiex/fw.h @@ -165,6 +165,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER { #define TLV_TYPE_STA_MAC_ADDR (PROPRIETARY_TLV_BASE_ID + 32) #define TLV_TYPE_BSSID (PROPRIETARY_TLV_BASE_ID + 35) #define TLV_TYPE_CHANNELBANDLIST (PROPRIETARY_TLV_BASE_ID + 42) +#define TLV_TYPE_UAP_MAC_ADDRESS (PROPRIETARY_TLV_BASE_ID + 43) #define TLV_TYPE_UAP_BEACON_PERIOD (PROPRIETARY_TLV_BASE_ID + 44) #define TLV_TYPE_UAP_DTIM_PERIOD (PROPRIETARY_TLV_BASE_ID + 45) #define TLV_TYPE_UAP_BCAST_SSID (PROPRIETARY_TLV_BASE_ID + 48) diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h b/drivers/net/wireless/marvell/mwifiex/ioctl.h index 091e7ca79376..8be3a2714bf7 100644 --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h @@ -83,6 +83,7 @@ struct wep_key { #define MWIFIEX_OPERATING_CLASSES 16 struct mwifiex_uap_bss_param { + u8 mac_addr[ETH_ALEN]; u8 channel; u8 band_cfg; u16 rts_threshold; diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c index e78a201cd150..491e36611909 100644 --- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c @@ -468,6 +468,7 @@ void mwifiex_config_uap_11d(struct mwifiex_private *priv, static int mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) { + struct host_cmd_tlv_mac_addr *mac_tlv; struct host_cmd_tlv_dtim_period *dtim_period; struct host_cmd_tlv_beacon_period *beacon_period; struct host_cmd_tlv_ssid *ssid; @@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) int i; u16 cmd_size = *param_size; + mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv; + mac_tlv->header.type = cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS); + mac_tlv->header.len = cpu_to_le16(ETH_ALEN); + memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN); + cmd_size += sizeof(struct host_cmd_tlv_mac_addr); + tlv += sizeof(struct host_cmd_tlv_mac_addr); + if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID); base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c -- 2.25.1

2 years

1
1
0 0

Re: [tip: x86/urgent] x86/acpi: Ignore invalid x2APIC entries

by Andres Freund

Hi, On 2023-12-01 08:31:48 +0000, Zhang, Rui wrote: > As a quick fix, I'm not going to fix the "potential issue" describes > above because we have not seen a real problem caused by this yet. > > Can you please try the below patch to confirm if the problem is gone on > your system? > This patch falls back to the previous way as sent at > https://lore.kernel.org/lkml/87pm4bp54z.ffs@tglx/T/ I've just spent a couple hours bisecting why upgrading to 6.7-rc4 left me with just a single CPU core on my dual socket workstation. before: [ 0.000000] Linux version 6.6.0-andres-00003-g31255e072b2e ... ... [ 0.022960] ACPI: Using ACPI (MADT) for SMP configuration information ... [ 0.022968] smpboot: Allowing 40 CPUs, 0 hotplug CPUs ... [ 0.345921] smpboot: CPU0: Intel(R) Xeon(R) Gold 5215 CPU @ 2.50GHz (family: 0x6, model: 0x55, stepping: 0x7) ... [ 0.347229] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 [ 0.349082] .... node #1, CPUs: #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 [ 0.003190] smpboot: CPU 10 Converting physical 0 to logical die 1 [ 0.361053] .... node #0, CPUs: #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 [ 0.363990] .... node #1, CPUs: #30 #31 #32 #33 #34 #35 #36 #37 #38 #39 ... [ 0.370886] smp: Brought up 2 nodes, 40 CPUs [ 0.370891] smpboot: Max logical packages: 2 [ 0.370896] smpboot: Total of 40 processors activated (200000.00 BogoMIPS) [ 0.403905] node 0 deferred pages initialised in 32ms [ 0.408865] node 1 deferred pages initialised in 37ms after: [ 0.000000] Linux version 6.6.0-andres-00004-gec9aedb2aa1a ... ... [ 0.022935] ACPI: Using ACPI (MADT) for SMP configuration information ... [ 0.022942] smpboot: Allowing 1 CPUs, 0 hotplug CPUs ... [ 0.356424] smpboot: CPU0: Intel(R) Xeon(R) Gold 5215 CPU @ 2.50GHz (family: 0x6, model: 0x55, stepping: 0x7) ... [ 0.357098] smp: Bringing up secondary CPUs ... [ 0.357107] smp: Brought up 2 nodes, 1 CPU [ 0.357108] smpboot: Max logical packages: 1 [ 0.357110] smpboot: Total of 1 processors activated (5000.00 BogoMIPS) [ 0.726283] node 0 deferred pages initialised in 368ms [ 0.774704] node 1 deferred pages initialised in 418ms There does seem to be something off with the ACPI data, when booting without the patch, I do see messages like: [ 0.715228] APIC: NR_CPUS/possible_cpus limit of 40 reached. Processor 40/0x7f00 ignored. [ 0.715231] ACPI: Unable to map lapic to logical cpu number But other than that, the system has worked for a couple years. It's obviously not good to regress from 2x10/20 cores/threads to a single core. I guess it's at least somewhat funny to imagine a 2 socket system with a single core... It seems particularly worrying that this patch has apparently been selected for -stable: https://lore.kernel.org/all/20231122153212.852040-2-sashal@kernel.org/ Even if it didn't have these unintended consequences, it seems like a commit like this hardly is -stable material? I've attached .config, dmesg of a boot with gec9aedb2aa1a and one with gec9aedb2aa1a^. Greetings, Andres Freund

2 years

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023