Running make savedefconfig highlights some useless flags.
Since 54a48aa3d558 ("Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK")
flag ENABLE_MUST_CHECK has been removed.
Since 35260cf545 ("Kconfig.debug: fix SCHED_DEBUG dependency")
SCHED_DEBUG depends on DEBUG_KERNEL and PROC_FS.
As PROC_FS is not set, SCHED_DEBUG reference can be removed.
Since 7801104268 ("scsi: bsg: Move bsg_scsi_ops to drivers/scsi/")
BLK_DEV_BSG depends on SCSI. As SCSI is not set, BLK_DEV_BSG reference
can be removed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241220125506.3157268-3-patrice.chotard@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Running make savedefconfig highlights some useless flags.
Remove FLASH_MEM_BASE and FLASH_SIZE as these 2 flags are only
used by CPU_ARM740T,CPU_ARM940T and CPU_ARM946E which is not the
case here for CPU_V7M.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241220125506.3157268-2-patrice.chotard@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* Fix rzg2l-usb-vbus-regulator lookup by assigning the proper of node
to the allocated platform device in the rzg2l-usbphy-ctrl driver.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCZ4FSSRcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwB3JAP9Jyz2KjaLJpFfY6cpgVd/cxcIm
X+1Hk2Aa7Nofecsd1gD5AX56C/2zpqeZ3yW6upzg0Dw7Kdfy9we/FFd2Kr1g/w8=
=FnoZ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeHvv8ACgkQYKtH/8kJ
UifxkRAAvhW3EbK0QkIYnwWyH3KIeMX2oNft88Um+OMswdgH3Z6TiFxIJdMFcMSD
vfNB3tRc6BYaBYgs3WotdgVbnWDh89Zm7sZHWcyMpjgLO7HC+nnhKSemfZZejKlZ
nmB5T6CKAbUluHxxLVnCyr+9FEnDtYMVRVAdtHD7gqinK0nJGUyyV6Y7JKG/yMxw
u5zQiTsA1ZyunkT3eOOD0VfjHNTDOMNPpNjQ8F+FGrjYGFqM+ZpwfHULiv4fBQ+P
yRxNVPgjpAnLu+08ka7Vh/JcBPS9BwQ3IsaLhKXkQMKAjro/3W4nx5uyvlICApZY
/UbEkYMz4C/4FyyAaSsBI+zGkmx1bVIYdtOusiYRAtiyxRt0xERvf+3j+DHN9D7W
vFS6gBJF9ncPQY2EfYzqGc+qzWcGUHt/4NgmvGvWJcYyH/QXr1TveFoLWMjEuxfF
vjFlpSbsm1uv+gh1WDeqG0WYp+QX9sHwoB60fnx+dShSMl+GveTn5El2WULVsKrB
LM+yJGbZSZHahr6QUqZhPaiAmr35khajuzF/zaFAOebJB5yTCUSJDO5F3X/cj87d
IcnRFuhkOhGV58Ph9CTw/wgY6wv6uOJx1U4RwgsE4Z7AT7OziMA7sqUKWj8brRzy
x8EkKPuJSDlfjkmlr1wOgjQwkzQiTL4R9pa7I3n/ld2wM1Bk6fk=
=IC5G
-----END PGP SIGNATURE-----
Merge tag 'reset-fixes-for-v6.13' of git://git.pengutronix.de/pza/linux into arm/fixes
Reset controller fixes for v6.13
* Fix rzg2l-usb-vbus-regulator lookup by assigning the proper of node
to the allocated platform device in the rzg2l-usbphy-ctrl driver.
* tag 'reset-fixes-for-v6.13' of git://git.pengutronix.de/pza/linux:
reset: rzg2l-usbphy-ctrl: Assign proper of node to the allocated device
Link: https://lore.kernel.org/r/20250113163642.1757160-1-p.zabel@pengutronix.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In 'cfg80211_scan_6ghz()', an instances of 'struct cfg80211_colocated_ap'
are allocated as if they would have 'ssid' as trailing VLA member. Since
this is not so, extra IEEE80211_MAX_SSID_LEN bytes are not needed.
Briefly tested with KUnit.
Fixes: c8cb5b854b ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://patch.msgid.link/20250113155417.552587-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We no longer use the prng, which leads to the following warning:
drivers/gpu/drm/tests/drm_buddy_test.c: In function
‘drm_test_buddy_alloc_clear’:
drivers/gpu/drm/tests/drm_buddy_test.c:264:23: error: unused variable
‘prng’ [-Werror=unused-variable]
264 | DRM_RND_STATE(prng, random_seed);
v2 (Thomas)
- Add Closes links
Reported-by: Jani Nikula <jani.nikula@intel.com>
Closes: https://lore.kernel.org/dri-devel/875xmggvcs.fsf@intel.com/
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Closes: https://lore.kernel.org/dri-devel/3f816555e6913fdbcb254523f65c98088d70581b.camel@intel.com/
Fixes: 8cb3a1e2b3 ("drm/buddy: Add a testcase to verify the multiroot fini")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250115124941.155990-2-matthew.auld@intel.com
Codec driver can implement .hw_params and/or .prepare from struct
snd_soc_dai_ops. For codec-to-codec links only the former (.hw_params)
callback has been called.
On platforms like Amlogic Meson8/8b/8m2 the SoC's sound card
(sound/soc/meson/gx-card.c) uses a codec-to-codec link for the HDMI
codec output because further digital routing is required after the
backend. The new DRM HDMI (audio) codec framework (which internally
uses sound/soc/codecs/hdmi-codec.c) relies on the .prepare callback
of the hdmi-codec to be called. Implement calls to
snd_soc_dai_prepare() so the .prepare callback is called. In this
case the mandatory part is the call to prepare the sink (which is
the hdmi-codec on those platforms). Also call snd_soc_dai_prepare()
for the source to stay consistent with the rest of the code (even
though it's not strictly necessary to make the DRM HDMI codec
framework work on Amlogic Meson8/8b/8m2).
For platforms or sound cards without a codec-to-codec link with
additional parameters (which applies to most hardware) this changes
nothing as the .prepare callback is already called via
snd_pcm_do_prepare() (as well as dpcm_fe_dai_prepare() and
dpcm_be_dai_prepare()) on those.
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://patch.msgid.link/20250114215617.336105-3-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new snd_soc_dai_prepare() which can be used (in an upcoming patch)
by soc-dapm.c. Use this new function internally in
snd_soc_pcm_dai_prepare() to avoid duplicating code.
Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20250114215617.336105-2-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As of commit cb18cd2603 ("ASoC: soc-core: do rtd->id trick at
snd_soc_add_pcm_runtime()") the ID stored in the PCM runtime data can
no longer be safely used to index the priv->dai_props array. This is
because the ID may be modified during snd_soc_add_pcm_runtime(), thus
resulting in an ID that's no longer a valid array index.
To fix this, use the position of the dai_link stored inside the PCM
runtime data relative to the start of the dai_link array as index into
the priv->dai_props array.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20250114184314.3583-2-laurentiumihalcea111@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Introduce diag310 and memory topology related subcodes.
Provide memory topology information obtanied from diag310 to userspace
via diag ioctl.
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Existing primitive has several problems:
1) calling conventions are clumsy - it returns a dentry reference
that is either identical to its second argument or is an ERR_PTR(-E...);
in both cases no refcount changes happen. Inconvenient for users and
bug-prone; it would be better to have it return 0 on success and -E... on
failure.
2) it allows cross-directory moves; however, no such caller have
ever materialized and considering the way debugfs is used, it's unlikely
to happen in the future. What's more, any such caller would have fun
issues to deal with wrt interplay with recursive removal. It also makes
the calling conventions clumsier...
3) tautological rename fails; the callers have no race-free way
to deal with that.
4) new name must have been formed by the caller; quite a few
callers have it done by sprintf/kasprintf/etc., ending up with considerable
boilerplate.
Proposed replacement: int debugfs_change_name(dentry, fmt, ...). All callers
convert to that easily, and it's simpler internally.
IMO debugfs_rename() should go; if we ever get a real-world use case for
cross-directory moves in debugfs, we can always look into the right way
to handle that.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lore.kernel.org/r/20250112080705.141166-21-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
use debugfs_{create_file,get}_aux_num() instead.
[and for fsck sake, don't call variables filp - especially the
ones that are not even struct file *]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lore.kernel.org/r/20250112080705.141166-19-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Set by debugfs_create_file_aux(name, mode, parent, data, aux, fops).
Plain debugfs_create_file() has it set to NULL.
Accessed by debugfs_get_aux(file).
Convenience macros for numeric opaque data - debugfs_create_file_aux_num
and debugfs_get_aux_num, resp.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20250112080705.141166-5-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The reason we need that crap is the dual use ->d_fsdata has there -
it's both holding a debugfs_fsdata reference after the first
debugfs_file_get() (actually, after the call of proxy ->open())
*and* it serves as a place to stash a reference to real file_operations
from object creation to the first open. Oh, and it's triple use,
actually - that stashed reference might be to debugfs_short_fops.
Bugger that for a game of solidiers - just put the operations
reference into debugfs-private augmentation of inode. And split
debugfs_full_file_operations into full and short cases, so that
debugfs_get_file() could tell one from another.
Voila - ->d_fsdata holds NULL until the first (successful) debugfs_get_file()
and a reference to struct debugfs_fsdata afterwards.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20250112080705.141166-4-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All it takes is having full_proxy_open() collect the information
about available methods and store it in debugfs_fsdata.
Wrappers are called only after full_proxy_open() has succeeded
calling debugfs_get_file(), so they are guaranteed to have
->d_fsdata already pointing to debugfs_fsdata.
As the result, they can check if method is absent and bugger off
early, without any atomic operations, etc. - same effect as what
we'd have from NULL method. Which makes the entire proxy_fops
contents unconditional, making it completely pointless - we can
just put those methods (unconditionally) into
debugfs_full_proxy_file_operations and forget about dynamic
allocation, replace_fops, etc.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20250112080705.141166-3-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
... and don't bother with debugfs_fsdata for those. Life's
simpler that way...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20250112080705.141166-2-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Embed them into container (struct debugfs_inode_info, with nothing
else in it at the moment), set the cache up, etc.
Just the infrastructure changes letting us augment debugfs inodes
here; adding stuff will come at the next step.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20250112080705.141166-1-viro@zeniv.linux.org.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Antonio Borneo <antonio.borneo@foss.st.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/20250114203602.1013275-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is a follow up fix for
https://patchwork.freedesktop.org/patch/msgid/20241203021929.1919730-1-oak.zeng@intel.com
The overall goal is to fail vm_bind when there is memory pressure. See more
details in the commit message of above patch. Abbove patch fixes the issue
when user pass in a vm_id parameter during gem_create. If user doesn't pass
in a vm_id during gem_create, above patch doesn't help.
This patch further reject BO eviction (which could be triggered by bo validation)
if BO is bound to the current VM. vm_bind could fail due to the eviction failure.
The BO to VM reverse mapping structure is used to determine whether BO is bound
to VM.
v2:
Move vm_bo definition from function scope to if(evict) clause (Thomas)
Further constraint the condition by adding ctx->resv (Thomas)
Add a short comment describe the change.
Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Oak Zeng <oak.zeng@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110210137.3181576-1-oak.zeng@intel.com
Fix a pair of bugs in the fallback handling for the YFS.RemoveFile2 RPC
call:
(1) Fix the abort code check to also look for RXGEN_OPCODE. The lack of
this masks the second bug.
(2) call->server is now not used for ordinary filesystem RPC calls that
have an operation descriptor. Fix to use call->op->server instead.
Fixes: e49c7b2f6d ("afs: Build an abstraction around an "operation" concept")
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/109541.1736865963@warthog.procyon.org.uk
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
If ccs_mode is being modified via
/sys/class/drm/cardX/device/tileY/gtY/ccs_mode
the asynchronous reset is triggered and the write returns immediately.
With that some test receive false information about number of CCS engines
or even fail if they proceed without delay after changing the ccs_mode.
Changing the ccs_mode change from async to sync to prevent failures in
tests.
Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Fixes: f3bc5bb4d5 ("drm/xe: Allow userspace to configure CCS mode")
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211111727.1481476-3-maciej.patelczyk@intel.com
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
(cherry picked from commit 480fb9806e)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Add synchronous version gt reset as there are few places where it
is expected.
Also add a wait helper to wait until gt reset is done.
Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Fixes: f3bc5bb4d5 ("drm/xe: Allow userspace to configure CCS mode")
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211111727.1481476-2-maciej.patelczyk@intel.com
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
(cherry picked from commit 155c77f45f)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
The guc_mmio_reg interface supports steering, but it is currently not
implemented. This will allow the GuC to control steering of MMIO
registers after save-restore and avoid reading from fused off MCR
register instances.
Fixes: 9c57bc0865 ("drm/xe/lnl: Drop force_probe requirement")
Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212190100.3768068-1-jesus.narvaez@intel.com
(cherry picked from commit ee5a1321df)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
The logic of GENERIC_PENDING_IRQ is backwards for historical reasons. Most
interrupt controllers allow to move the interrupt from arbitrary
contexts. If GENERIC_PENDING_IRQ is enabled by an architecture to support a
chip, which requires the affinity change to happen in interrupt context,
all other chips have to be marked with IRQF_MOVE_PCNTXT.
That's tedious and there is no real good reason for the extra flags in the
irq descriptor and the irq data status fields. In fact the decision whether
interrupts can be moved in arbitrary context or not is a property of the
interrupt chip.
To simplify adoption for RISC-V provide a new mechanism which is enabled
via a config switch and allows to add a flag to irq_chip::flags to request
that interrupt affinity changes are deferred. Setting the top level chip of
an interrupt evaluates the flag and maps it into the existing logic.
The config switch and the various PCNTXT flags are temporary until x86 is
converted over to this scheme. This intermediate step also allows trivial
backporting of the mechanism to plug the affinity change race of various
RISC-V interrupt controllers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20241210103335.500314436@linutronix.de
Nothing uses the actual functionality and the MCIP controller sets the
flags which disables the deferred affinity change. The other interrupt
controller does not support affinity setting at all.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Vineet Gupta <vgupta@kernel.org> # arch/arc/
Link: https://lore.kernel.org/all/20241210103335.373392568@linutronix.de
Commit 1b57d91b96 ("irqchip/gic-v2, v3: Prevent SW resends entirely")
sett the flag which enforces interrupt handling in interrupt context and
prevents software base resends for ARM GIC v2/v3.
But it missed that the helper function which checks the flag was hidden
behind CONFIG_GENERIC_PENDING_IRQ, which is not set by ARM[64].
Make the helper unconditionally available so that the enforcement actually
works.
Fixes: 1b57d91b96 ("irqchip/gic-v2, v3: Prevent SW resends entirely")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20241210101811.497716609@linutronix.de
Audio control requests that sets sampling frequency sometimes fail on
this card. Adding delay between control messages eliminates that problem.
usb 1-1: New USB device found, idVendor=0d8c, idProduct=0014
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: USB Audio Device
usb 1-1: Manufacturer: C-Media Electronics Inc.
Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/TYUPR06MB6217E94D922B9BF422A73F32D2192@TYUPR06MB6217.apcprd06.prod.outlook.com
platform_irqchip_probe() leaks a OF node when irq_init_cb() fails. Fix it
by declaring par_np with the __free(device_node) cleanup construct.
This bug was found by an experimental static analysis tool that I am
developing.
Fixes: f8410e6265 ("irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241215033945.3414223-1-joe@pf.is.s.u-tokyo.ac.jp
Because of patch[1] the graft behaviour changed
So the command:
tcq replace parent 100:1 handle 204:
Is no longer valid and will not delete 100:4 added by command:
tcq replace parent 100:4 handle 204: pfifo_fast
So to maintain the original behaviour, this patch manually deletes 100:4
and grafts 100:1
Note: This change will also work fine without [1]
[1] https://lore.kernel.org/netdev/20250111151455.75480-1-jhs@mojatatu.com/T/#u
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
avecintc_init() enables the Advanced Interrupt Controller (AVEC) of
the boot CPU node, but nothing enables the AVEC on secondary nodes.
Move the enablement to the CPU hotplug callback so that secondary nodes get
the AVEC enabled too. In theory enabling it once per node would be
sufficient, but redundant enabling does no hurt, so keep the code simple
and do it unconditionally.
Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/all/20250111023704.17285-1-zhangtianyang@loongson.cn
