| Age | Commit message (Collapse) | Author |
|---|
|
Now that all users of SCSI sense codes have been modified to use macro
definitions and the 16-bit sense code instead of separate 8-bit ASC and
ASCQ, remove the now unused asc and ascq fields of struct scsi_failure and
struct scsi_sense_hdr, and the old (and incomplete) definitions of SCSI
additional sense codes and sense code qualifiers in scsi_proto.h.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-40-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Refactor the SCSI core code to use the 16-bit sense_code field of struct
scsi_sense_hdr and struct scsi_failure and replace all hard-coded
additional sense codes and additional sense code qualifiers with the enum
values defined in include/scsi/scsi_sense.h. This helps with code clarity
as the sense codes being processed are easier to test and self-documented.
No functional change intended, with the exception of a correction of the
array any_sense_failure_defs in scsi_lib_test_any_sense() which erroenously
sets result to SCMD_FAILURE_RESULT_ANY instead of SAM_STAT_CHECK_CONDITION
and does not sets sense_key to SCMD_FAILURE_SENSE_KEY_ANY.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-8-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Instead of passing the sense key, additional sense code and additional
sense code qualifier as separate parameters, change the functions
scsi_extd_sense_format(), scsi_format_extd_sense(), and
usb_stor_show_sense() to take a pointer to a struct scsi_sense_hdr to
access the sense key and sense code with a single argument.
No functional change intended.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-7-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
In preparation for handling sense codes and their qualifers as a single
16-bit sense code field, with the values defined as macros in
include/scsi/scsi_sense.h, modify the definition of the structures
scsi_failure and scsi_sense_hdr to introduce a 16-bit sense_code field as a
union with the existing 8-bit asc and ascq fields.
This temporary modification allows accessing either the asc and ascq fields
individually, or their combination as the 16-bit sense_code field.
The helper functions scsi_sense_asc(), scsi_sense_ascq() are defined to
allow accessing the 8-bit ASC and ASCQ values from the sense_code filed of
struct scsi_sense_hdr. The helper functions scsi_failure_asc() and
scsi_failure_ascq() provide the same for the sense code field of struct
scsi_failure.
The helper functions scsi_set_sense_buffer() and scsi_set_sense() are also
added to wrap calls to scsi_build_sense_buffer() and scsi_build_sense()
using a 16-bit sense code argument instead of the 8-bit ASC and ASCQ
arguments.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-6-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Rename the sense field of struct scsi_failure to sense_key. This makes it
clear that this field stores the sense key, and also unifies this structure
field names with the names used in struct scsi_sense_hdr.
To be consistent with this change, the macro SCMD_FAILURE_SENSE_ANY is
renamed SCMD_FAILURE_SENSE_KEY_ANY.
Of note is that the definition of the array any_sense_failure_defs in
scsi_lib_test_any_sense() is modified to change the initialization of the
result field to use SCMD_FAILURE_RESULT_ANY and add the .sense_key field
initialization to SCMD_FAILURE_SENSE_KEY_ANY to match the test target case.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-5-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Introduce the file include/scsi/scsi_sense.h to define all existing
additional sense codes and their combinations with additional sense code
qualifiers, according to the most current T10 list available at
https://www.t10.org/lists/asc-num.txt.
Additional sense codes (ASCs) are individually defined as an 8-bit value
with the ASC_ name prefix. The combination of all ASCs with T10 defined
possible code qualifiers are defined as 16-bit values without any name
prefix. The 16-bit value for ASCs with a zero ASCQ are defined together
with the ASC 8-code using the ASC() macro. For names that may potentially
create conflicts with other subsystems (e.g. WARNING or WRITE_ERROR), the
SSC_ prefix is added to the sense code name.
The sense key macro definitions in include/scsi/scsi_proto.h are also moved
into this new file and scsi_sense.h is included in scsi_proto.h. The
helper function scsi_sense_code() is defined to facilitate generating a
16-bit sense code from the 8-bit ASC and ASCQ. The accessors
scsi_sense_code_asc() and scsi_sense_code_ascq() are defined for the
reverse operations, that is, to respectively extract an ASC and an ASCQ
from a 16-bit sense code.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Link: https://patch.msgid.link/20260908090308.1085097-2-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
PME capabiliy need to be assessed very early during runtime suspend
routine to avoid resetting HPDs during IRQ resets. As display
runtime pm routines are being executed in the independent intel
display driver entry points, we need to have independent access
to the pme status as well. Add a provision to query the optional
pme_enabled to the parent interface so that it could be called
independently based on xe/i915's pme_enabled() implementation.
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-3-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Eliminate all kernel-doc warnings in <linux/ccp.h>:
- add Returns: for function return values
- use the enum keyword when describing an enum in kernel-doc
- add missing enum value descriptions
- add or repair missing struct member descriptions
- use nested struct notation as needed
Warning: include/linux/ccp.h:30 No description found for return value
of 'ccp_present'
Warning: include/linux/ccp.h:42 No description found for return value
of 'ccp_version'
Warning: include/linux/ccp.h:67 No description found for return value
of 'ccp_enqueue_cmd'
Warning: include/linux/ccp.h:97 cannot understand function prototype:
'enum ccp_aes_type'
Warning: include/linux/ccp.h:114 cannot understand function prototype:
'enum ccp_aes_mode'
Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GHASH' not
described in enum 'ccp_aes_mode'
Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GCTR' not
described in enum 'ccp_aes_mode'
Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GCM' not
described in enum 'ccp_aes_mode'
Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GMAC' not
described in enum 'ccp_aes_mode'
Warning: include/linux/ccp.h:134 cannot understand function prototype:
'enum ccp_aes_action'
Warning: include/linux/ccp.h:190 struct member 'authsize' not described
in 'ccp_aes_engine'
Warning: include/linux/ccp.h:190 struct member 'aad_len' not described
in 'ccp_aes_engine'
Warning: include/linux/ccp.h:202 cannot understand function prototype:
'enum ccp_xts_aes_unit_size'
Warning: include/linux/ccp.h:245 struct member 'type' not described in
'ccp_xts_aes_engine'
Warning: include/linux/ccp.h:255 cannot understand function prototype:
'enum ccp_sha_type'
Warning: include/linux/ccp.h:394 cannot understand function prototype:
'enum ccp_passthru_bitwise'
Warning: include/linux/ccp.h:410 cannot understand function prototype:
'enum ccp_passthru_byteswap'
Warning: include/linux/ccp.h:472 struct member 'src_dma' not described
in 'ccp_passthru_nomap_engine'
Warning: include/linux/ccp.h:472 struct member 'dst_dma' not described
in 'ccp_passthru_nomap_engine'
Warning: include/linux/ccp.h:472 Excess struct member 'src' description in
'ccp_passthru_nomap_engine' (did you mean one of: 'src_len', 'src_dma')
Warning: include/linux/ccp.h:472 Excess struct member 'dst' description in
'ccp_passthru_nomap_engine' (did you mean one of: 'dst_dma')
Warning: include/linux/ccp.h:489 cannot understand function prototype:
'enum ccp_ecc_function'
Warning: include/linux/ccp.h:587 struct member 'u' not described in
'ccp_ecc_engine'
Warning: include/linux/ccp.h:587 Excess struct member 'mm' description in
'ccp_ecc_engine' (did you mean one of: 'u.mm')
Warning: include/linux/ccp.h:587 Excess struct member 'pm' description in
'ccp_ecc_engine' (did you mean one of: 'u.pm')
Warning: include/linux/ccp.h:602 cannot understand function prototype:
'enum ccp_engine'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
struct vgetrandom_opaque_params contains size_of_opaque_state, but its
kernel-doc describes size_per_opaque_state. This leaves the real member
undescribed and adds a nonexistent member to the generated
documentation.
Use the member's actual name.
Fixes: 4ad10a5f5f78 ("random: introduce generic vDSO getrandom() implementation")
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Drop the second 'to', reported by checkpatch.pl as a possible repeated
word. Only touches a comment, no code changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Use the correct function parameter names and add function return
value descriptions to avoid kernel-doc warnings:
Warning: include/linux/siphash.h:82 function parameter 'len' not described
in 'siphash'
Warning: include/linux/siphash.h:82 No description found for return value
of 'siphash'
Warning: include/linux/siphash.h:132 function parameter 'len' not
described in 'hsiphash'
Warning: include/linux/siphash.h:132 No description found for return value
of 'hsiphash'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Some gpio-regmap consumers share their regmap with a parent device that
may be runtime suspended. GPIO register accesses must resume that device
first.
Add an optional pm_dev field and acquire it before register translation
or access. Release it using runtime autosuspend after each operation.
Keep the device active across the complete direction-output sequence and
propagate failure when setting the initial output value.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260910-ad7768-gpio-v8-2-6aaaa15adeb3@analog.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
For MLD stations, userspace may need to explicitly transmit a frame to
a specific link address. In that case, it needs to ensure that no
address translation happens.
In the reverse case of an RX, userspace may need to know the link
address for a frame. By passing the information whether a STA is known
for the frame, userspace knows whether link translation happened and
can do the reverse lookup when needed.
This is important for flows where a STA is still registered but the
connection has been lost and it is returning again.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.f12af80b1972.I4cfd3db83ba3dc0267575f919ba613ea5d10abd5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The link ID for one frequency may be different between VIFs. As such,
the sensible thing is to set the link ID later in the flow once the SKB
is duplicated for each VIF. As the link ID is not passed in from outside
mac80211 it is always valid and the corresponding bit can be dropped.
Also switch a few more places to pass the link STA as that is a natural
way to pass the link information around.
This fixes the per-link statistics when frames are reordered.
Note that this patch deliberately leaves some places unchanged and even
incorrect as this will be addressed by further refactorings.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.467593bc1105.I8abe3601d0335dca22d48bcee864817cfccf0de0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If a station is passed then the link ID also needs to be known. As such,
it is a more natural API to simply pass the link station directly rather
than pushing the link information into the RX status.
Furthermore, having the link ID in the RX status is not actually correct
because the link IDs are VIF specific and there may be multiple VIFs. In
the case of a station this relationship is clear, but then one may as
well use the link station.
This patch only changes the API and emulates the old (incorrect)
behaviour for now. The mac80211 RX code will be updated in later
patches.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260915151925.06f41565116a.I4a2d45609e94b52654b10ec572e59a45d09c41f4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Backmerging to get drm-misc-fixes up to v7.3-rc3.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
All crtc drivers now implement the atomic_create_state hook instead of
the reset hook for initial state creation. The reset hook conflated
initial state allocation at probe time with hardware and software reset
during suspend/resume, making error handling difficult since it is not
fallible.
Remove the reset hook from struct drm_crtc_funcs and the associated
call in drm_mode_config_reset().
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-11-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
All users of __drm_atomic_helper_crtc_reset() have been converted to use
__drm_atomic_helper_crtc_state_init() and atomic_create_state.
Remove the now unused helper.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-10-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
All users of drm_atomic_helper_crtc_reset() have been converted to
drm_atomic_helper_crtc_create_state().
Remove the now unused helper.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-9-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Most of the struct definitions for a given IOCTL definition immediately
preceded that definition. The struct tee_ioctl_shm_register_data is an
exception as it is placed above the TEE_IOC_SHM_REGISTER_FD definition,
not the TEE_IOC_SHM_REGISTER one it is to be used with. Move it down
to match the others.
This is a non-functional change for consistency and to help prevent
someone from accidentally using the wrong struct with the wrong IOCTL
based on the struct's location.
Fix a couple small spelling issues while here.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
|
|
The hardware provides valid HWC destination vRQ and vRCQ IDs for all PFs
and VFs. Use these IDs unconditionally in mana_hwc_send_request(), as
the PF-specific gate is not required.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260910014427.54272-1-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Paolo pointed out an issue flagged at low priority by Sashiko -
we're currently not handling BE{16,32} attributes in policy dumps.
Commit 3f4285d741b4 ("netlink: specs: fou: local-v4 and peer-v4 are big
endian") flipped two fou attributes from NLA_U32 to NLA_BE32.
This made them vanish from the policy dump.
Follow the YAML spec format and treat byte order as a property of
a u16 / u32 rather than a type of its own. I don't have a strong
preference either way. The YNL format "feels cleaner" but the
kernel's separate type is easier when handling decoding.
I don't think that the policy type is actually usable for decoding
(since it only contains input types) so I went with YNL and added
the separate attr.
A missing byte order means host order, again like in the YAML specs.
Link: https://lore.kernel.org/ab90f970-0ebb-4c07-b7b1-db3f91395116@redhat.com
Link: https://patch.msgid.link/20260912202401.141336-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add WMI device ID 0x00120097 (ASUS_WMI_DEVID_DGPU_POWER_STATE) to the
asus-wmi platform header. This device ID is used on ASUS ROG laptops to
query the discrete GPU (dGPU) power state level.
Suggested-by: Denis Benato <denis.benato@linux.dev>
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260805183131.3075-2-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The kernel-doc comment of page_pool_free_va() refers to
page_pool_allo_va, which does not exist. The name is page_pool_alloc_va.
Say page_pool_alloc_va.
The wrong name came in with commit 8ab32fa1c794 ("page_pool: update
document about fragment API").
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260912060019.39902-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL reject
non-zero lineinfo.padding with -EINVAL; align the uapi comment with
gpio_v2_line_request.padding.
Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260831143125.151360-4-ivanrwcm25@gmail.com>
|
|
hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers
queue dump_rx without holding an hdev reference. Unregister leaves both
works live, so disconnecting during an active dump lets them access hdev
after hci_release_dev() frees it.
Shut down coredump processing during unregister. Close the producer gate
under dump_q.lock before disabling both works, then free the active buffer
and queued packets under hci_dev_lock. Serializing the gate with enqueue
prevents controller-specific workers from adding packets after the final
purge.
Fixes: 9695ef876fd1 ("Bluetooth: Add support for hci devcoredump")
Reported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a
Reported-by: Aby Sam Ross <abysamross@gmail.com>
Link: https://lore.kernel.org/r/20260322210849.68743-1-abysamross@gmail.com
Suggested-by: Aby Sam Ross <abysamross@gmail.com>
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Link: https://lore.kernel.org/r/20260814231248.3096377-1-tristmd@gmail.com
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: OpenAI Codex:gpt-5
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
bcom_gen_bd_rx_init() and bcom_gen_bd_tx_init() are only called from
the PSC wrapper functions in gen_bd.c, so make them static, drop
their now-unneeded exports, and remove the corresponding header
declarations.
These had use before commit 7d3ee229ea51
("powerpc: Drop MPC5200 LocalPlus bus FIFO driver")
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/20260913194804.39939-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add an SCMI transport for ACPI-described systems using PCCT PCC
subspaces through the Linux PCC mailbox layer.
Parse the SCMI Device Properties _DSD packages defined by Arm document
111115A v1.0, sections 2.2.1.1, 2.2.2.1 and 2.2.3. Map transport
UIDs to PCC subspaces for common and protocol-exclusive A2P and P2A
channels, validate the mappings, and cache them for channel setup.
Support the Powercap and System Telemetry protocol properties and add
the System Telemetry protocol ID. Implement PCC channel management,
message framing, shared-memory bounds validation, and response and
notification delivery.
Add the corresponding Kconfig, module and ARML0001 ACPI matching
plumbing.
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-7-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Chancel Liu <chancel.liu@oss.nxp.com> says:
simple_util_init_jack() acquires a jack detection GPIO with
gpiod_get_optional() and passes it to snd_soc_jack_add_gpios(), which
also installs an IRQ handler, a PM notifier, a delayed work and a sysfs
export for it. None of simple-card, audio-graph-card or
audio-graph-card2 implements a card->remove() callback, so none of this
is ever released.
That goes unnoticed while the card is only torn down together with its
platform device, because the devres cleanup registered by
snd_soc_jack_add_gpios() is tied to that platform device. It becomes a
problem once the card alone is unregistered and registered again while
the platform device stays bound - for instance when a codec component is
unbound and bound again. card->probe() then runs a second time and
gpiod_get_optional() fails with -EBUSY, because the descriptor is still
held by the previous bind. The card is not registered again and audio
stays broken until the platform device itself is unbound.
Patch 1 adds the simple_util_remove_jack() helper, patches 2-4 wire it
up in the three generic card drivers.
Verified with audio-graph-card2 and a wm8962 codec using hp-det-gpios.
Before the series, the first
echo 3-001a > /sys/bus/i2c/drivers/wm8962/unbind
echo 3-001a > /sys/bus/i2c/drivers/wm8962/bind
leaves the GPIO line and IRQ claimed while the card is gone, and the
re-bind fails with
ASoC error (-16): at graph_util_card_probe()
ASoC error (-16): at snd_soc_card_probe() on wm8962-audio
after which the sound card never comes back. With the series applied,
both codec unbind/bind and platform unbind/bind cycles release the GPIO
and IRQ on unbind and fully restore the card.
Link: https://patch.msgid.link/20260913102502.2805912-1-chancel.liu@oss.nxp.com
|
|
graph_util_card_probe() sets up the headphone and microphone jacks,
which takes a reference on the jack detection GPIO and registers an IRQ,
a PM notifier, a delayed work and a sysfs export for it. audio-graph-card
has no card->remove() callback, so none of this is released when the card
is torn down.
This goes unnoticed while the card is only torn down together with its
platform device, because the devres cleanup registered by
snd_soc_jack_add_gpios() is tied to that platform device. It becomes a
problem once the card alone is unregistered and registered again while
the platform device stays bound - for example when a codec component is
unbound and bound again. card->probe() then runs a second time and
gpiod_get_optional() fails with -EBUSY, because the descriptor is still
held by the previous bind. The card is not registered again and audio
stays broken until the platform device itself is unbound.
Add graph_util_card_remove() as the counterpart of
graph_util_card_probe() and hook it to card->remove. It lives in
simple-card-utils.c so that audio-graph-card2 can use it as well.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20260913102502.2805912-4-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
simple_util_init_jack() acquires a GPIO descriptor with
gpiod_get_optional() and hands it to snd_soc_jack_add_gpios(), which
additionally installs an IRQ handler, a PM notifier, a delayed work and
a sysfs export for it. simple-card-utils has no counterpart that
releases any of this again.
Add simple_util_remove_jack(), the counterpart of
simple_util_init_jack(). It releases the jack GPIO and everything
snd_soc_jack_add_gpios() installed for it via snd_soc_jack_free_gpios(),
and clears sjack->gpio.desc so the descriptor is not left dangling after
it has been put.
This gives the generic card drivers a card->remove() path to release the
jack when the card goes away. The devres cleanup alone is not enough:
it is tied to the platform device, so it does not run when the card is
unregistered and re-registered while the platform device stays bound -
for example when a codec component is unbound and bound again.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20260913102502.2805912-2-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The current dma_chan structure contains both "device" and "dev". So
chan->device->dev refers to the DMA engine device.
chan->dev->device refers to the per-channel device instance.
Their similar naming makes the distinction unclear and increases reader
confusion.
Add union dma_chan::chan_dev to make its purpose explicit and clearly
identify it as the per-channel device. After all user switch to chan_dev,
union and dma_chan::dev will be removed.
Update the kernel-doc accordingly. Besides its sysfs usage, the per-channel
device is also used by some DMA engine drivers for IOMMU mapping and
therefore deserves a more accurate description.
No functional change intended.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-4-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add a new helper function (dmaengine|vchan)_chan_dev() to access the DMA
channel device embedded in struct dma_chan_dev (chan->dev->device). This
provides a cleaner API instead of open-coding &chan->dev->device throughout
the drivers.
Replay private chan2dev() and dchan2dev() with this new common APIs in
indivial DMA engine drivers.
Prepare rename dma_chan::dev field.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-3-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Use the existing dma_chan_name() helper to obtain the per-channel device
name instead of open-coding: dev_name(chan->dev->device) /
dev_name(chan2dev()).
Simplify the code, improve consistency and reduce line wrapping where
possible.
No functional change intended.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com> # For STM32
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-2-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
HDMA supports configurable DMA channel register space
separation which ranges from 256B to 32KB. Current implementation
supports 256B as default for DMA channel register space.
CPM6 supports the selection of channel register space via VSEC.
The default value for channel register space for CPM6 is 512B.
Updated the functions and methods to calculate the DMA channel
registers base address as per the selected channel separation
available as part of 'ch_space_sz'. Removed the unused function
__dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs.
Signed-off-by: Devendra K Verma <devverma@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260907101213.1917064-3-devverma@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Make the type fixed to u32.
This then means we need to fix the helper macro omap_mbox_message so it
doesn't cast to u32 twice. What this macro should be doing is converting
from the message type returned from the mailbox framework into the
omap-mailbox type. When fixing this we should add a macro for the other
direction (from omap-mailbox type to something that can be used with
mbox_send_message).
After these changes, make use of the new macros as appropriate.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Drivers can offload FT or OKC roaming without necessarily advertising
full 802.1X 4-way handshake offload. Add an extended feature bit for
that capability and allow PMK configuration when it is present.
This gives userspace a way to provide PMK or PMK-R0 material needed by
fast roaming firmware implementations while keeping the existing 4-way
handshake offload capability unchanged.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-2-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The zone related fields of struct gendisk can be modified by
blk_revalidate_disk_zones() either on the first scan of the disk, or
during user triggered scans or device revalidation, if some
characteristics of the disk has changed (e.g. the disk capacity). Changes
to these fields are always done with the disk request queue frozen so that
BIO processing does not see any inconsistent state of the zones. This
implies a contract that reading these zone related fields must always be
done while holding a usage count on the request queue of the disk.
However, increasing the usage count of the disk request queue cannot be
done from the context of blk_revalidate_disk_zones() itself, as that would
prevent freezing the disk queue and result in a deadlock. This prevents
blk_revalidate_disk_zones() from consulting the zone related fields of
struct gendisk to detect, for instance, a change in the number of zones of
the disk. For such case, we want to detect the change, take appropriate
measures and revalidate exclusively revalidate the zones to avoid
concurrent revalidation calls to see the same change while corrections are
already on-going.
A simple solution to avoid this issue is to introduce a mutex to serialize
calls to blk_revalidate_disk_zones() and ensure only a single context at a
time can modify the zone related fields of a gendisk. In preparation for
handling disk capacity revalidation in blk_revalidate_disk_zones(), do so
with the mutex zone_revalidate_mutex. This mutex is initialized in
disk_init_zone_resources(), destroyed in disk_release_zone_resources() and
taken and released only in blk_revalidate_disk_zones() to serialize the
execution of this function.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260908085745.1082697-10-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Currently, bdev_zone_is_seq() identifies a sequential zone by looking at
the zone condition, assuming that any zone that does not have the
condition BLK_ZONE_COND_NOT_WP is a sequential write required zone. That
is correct only as long as the target zoned device does not support
storage element depopulation (aka HDD head depopulation), which is a
feature that can transition conventional zones to the read-only or offline
condition. For such device, we cannot distinguish anymore between
conventional and sequential zones using the zone condition as both zone
types can have the same conditions.
Prepare for fully supporting storage element depopulation and restoration
by caching the type of a zone in addition to its condition. This is
implemented by reformating the zones_cond array using a more compact zone
condition representation with the new enum blk_zstate. This zone condition
representation only uses the lower 4 bits of a byte for the condition
values, thus leaving the high order 4 bits of each byte entry of the
array for flags. The flag BLK_ZFLAG_CONV is defined to indicate
conventional zones.
The helper functions blk_zstate_to_zone_cond() and
blk_zone_cond_to_zstate() are implemented using lookup tables to convert
between enum blk_zone_condition values and enum blk_zstate zone condition
values. The helper blk_zstate_set() can be used to set a zones_state
entry with a zone condition and zone type flags, safely in accordance to
the size of the zone state array being accessed. This helper is used in
disk_zone_set_cond() to update a zone condition.
bdev_zone_is_seq() is modified to use the flags of the zones_state array
entries to identify sequential zones. The zones_state array initialization
and revalidation is unchanged from the former zones_cond array.
Overall, any zone condition that is being considered outside of the
zones_state array always uses the enum blk_zone_condition values as
before, thus minimizing the number of changes.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://patch.msgid.link/20260908085745.1082697-6-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
struct ip_tunnel.net is the netns where encapsulated packets
flow into.
struct ip_tunnel is linked to ip_tunnel_net.tunnels[] of netns.
During netns dismantle or module unload, ip_tunnel_delete_net()
iterates the list and queues devices for destruction regardless
of the devices' netns.
Thus, once RTNL is removed, the list can be modified concurrently
from different netns due to device removal.
Let's protect it with per-netns mutex.
Note that dev_siocdevprivate() calls netdev_lock_ops() but
it must be NOP for tunnel devices to avoid AB-BA deadlock.
DEBUG_NET_WARN_ON_ONCE() is added to annotate the locking
explicitly.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-7-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
ip_tunnel_delete_net() no longer uses the 3rd argument,
struct rtnl_link_ops *ops.
Let's remove it.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-4-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Correct spelling mistakes in comments. No functional change.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260915084424.1007757-7-hemanth.selam@gmail.com
|
|
Correct spelling mistakes in comments. No functional change.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260915084424.1007757-6-hemanth.selam@gmail.com
|
|
ata_host_start() registers ata_host_stop() as a devres action as soon as
it has succeeded, which hands the release of the host resources over to
devres: ->port_stop() and ->host_stop() are then called by the driver
core when probe() fails.
ata_host_activate() and ahci_host_activate_multi_irqs() can both fail
after ata_host_start() has succeeded, e.g. if devm_request_irq() or
ata_host_register() fails, and they return the error with the devres
action still registered. A driver which releases the host resources in
its probe() error path therefore releases them twice: once itself and
once through ->host_stop().
All ahci-platform drivers are in that situation, e.g. ahci_probe() calls
ahci_platform_disable_resources() while ahci_host_stop() does the same
through devres. This gives refcount underflow warnings from the clk,
regulator and phy cores and, for shared resources, can disable resources
which are still in use by other devices.
Add ata_host_undo_start(), which stops the ports and drops the devres
action without calling ->host_stop(), and call it from both activation
helpers when they fail. Releasing the host resources on failure is then
always left to the caller, which is what all callers having a probe()
error path already assume.
This changes the semantics for the drivers which implement ->host_stop()
while also completely lacking error handling for the activate host call.
Add activate host error handling for sata_qstor and sata_fsl. For
sata_fsl this also means that hcr_base and host_priv are now released
when activating the host fails, which ->host_stop() did not do when
ata_host_start() itself failed.
Note that ata_pci_sff_activate_host() is deliberately left as is: none of
its callers releases the host resources in its probe() error path, they
all rely on ->host_stop() being called by devres, including
ata_pci_init_one(), which releases the devres group of the host itself.
Fixes: 1896b15eddb4 ("ahci_platform: perform platform exit in host_stop() hook")
Cc: stable@vger.kernel.org
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20260915084127.692494-13-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
|
|
__drm_gem_reset_shadow_plane() is no longer used: all callers now go
through __drm_gem_shadow_plane_state_init() or
drm_gem_create_shadow_plane_state(). Remove it.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260908-drm-no-more-plane-reset-v4-4-a31b3fcfc989@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Commit 7f879284390c ("drm/simple-kms: Switch to atomic_create_state")
replaced drm_simple_kms_plane_reset() with
drm_simple_kms_plane_create_state(), removing the only user of the
reset_plane hook. However, the hook itself was left behind in struct
drm_simple_display_pipe_funcs.
Remove it.
Fixes: 7f879284390c ("drm/simple-kms: Switch to atomic_create_state")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260908-drm-no-more-plane-reset-v4-1-a31b3fcfc989@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
container_of_const is more flexible than container_of when
it comes to mixing pointers constness. Switch to it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20260907-drm-state-readout-v5-3-5fa1ac7a5148@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
A number of state iterator macros trigger a compiler warning if an
iterator parameter isn't used in the code block.
Add a similar workaround than in most other macros.
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20260907-drm-state-readout-v5-1-5fa1ac7a5148@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference"
changed the check to test for the ops pointer instead of the signaled
bit to avoid a potential NULL dereference when the ops pointer has been
cleared.
The problem is now that the ops pointer is cleared only when neither the
release nor the wait callback is implemented and this isn't true for a lot
of dma_fence implementations yet. So those implementations lost the RCU
protection after signaling of the returned string resulting in potential
use after free.
Add the signaling check additional to the ops pointer check so that we
have both the protection against NULL dereference as well as the RCU
protection after signaling for the returned string.
v2: improve comments to note RCU protection and explain why we check
both signaling state and ops pointer
v3: some comment improvements suggested by Philip
Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference")
CC: stable@vger.kernel.org # 7.2+
Reported-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
Tested-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20260914182740.1587-1-christian.koenig@amd.com
|
|
There exist OS-accessible USB4 and Thunderbolt PHYs that need specific
configuration. Define a new phy_mode for them.
Currently, USB4 and TBT3 are defined as submodes, because they're quite
distinct, most visibly in the electrical/analog aspects (slightly
different frequencies, timings, etc.). This results in a need to make
the PHY aware of the actual mode needed (at least in the Qualcomm
implementation, but I believe that'll be a general need).
Newer versions of TBT are basically supersets of USB4 with higher
host-side requirements, so these are not defined. This can always be
changed as necessary.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908-topic-usb4phy-v5-2-73aac69578ef@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
