However, many existing device trees place NAND chip properties directly
within the controller node because those controllers support only a single
chip. This layout is still widely used by older platforms and by other DT
consumers such as U-Boot. Migrating all existing users to the new layout
will take time.
Several kernel drivers, such as ams-delta.c, davinci_nand.c and
fsmc_nand.c, still expect the legacy layout where raw NAND properties are
defined in the controller node.
To support both layouts during the transition:
- Extract NAND chip-related properties into separate schemas
(nand-property.yaml and raw-nand-property.yaml) from
nand-chip.yaml and raw-nand-chip.yaml.
- Introduce nand-controller-legacy.yaml to allow both the
legacy and modern layouts.
- Add a select condition in nand-controller.yaml to prevent
node name pattern matching for fsl,* NAND controllers.
Keep compatibility with existing device trees while allowing gradual
migration to the modern binding structure.
Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Miquel Raynal [Wed, 18 Mar 2026 10:47:50 +0000 (11:47 +0100)]
mtd: spinand: winbond: Clarify when to enable the HS bit
Above 104MHz when in fast dual or quad I/O reads, the delay between
address and data cycles is too short. It is possible to reach higher
frequencies, up to 166MHz, by adding a few more dummy cycles through the
setting of the HS bit. Improve the condition for enabling this bit, and
also make sure we set it at soon as we go over 104MHz.
Richard Genoud [Tue, 17 Mar 2026 14:24:37 +0000 (15:24 +0100)]
mtd: rawnand: sunxi: introduce maximize variable user data length
In Allwinner SoCs, user data can be added in OOB before each ECC data.
For older SoCs like A10, the user data size was the size of a register
(4 bytes) and was mandatory before each ECC step.
So, the A10 OOB Layout is:
[4Bytes USER_DATA_STEP0] [ECC_STEP0 bytes]
[4bytes USER_DATA_STEP1] [ECC_STEP1 bytes]
...
NB: the BBM is stored at the beginning of the USER_DATA_STEP0.
Now, for H6/H616 NAND flash controller, this user data can have a
different size for each step.
So, we are maximizing the user data length to use as many OOB bytes as
possible.
Fixes: 88fd4e4deae8 ("mtd: rawnand: sunxi: Add support for H616 nand controller") Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Richard Genoud [Tue, 17 Mar 2026 14:24:35 +0000 (15:24 +0100)]
mtd: rawnand: sunxi: change error prone variable name
In sunxi_nand_hw_ecc_ctrl_init(), i is used as a loop index variable and
at the same time as the value used to set ECC mode in ECC control
register.
To prevent it from being re-used as a loop variable, let's change the
naming to ecc_mode.
No functional change.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Richard Genoud [Tue, 17 Mar 2026 14:24:32 +0000 (15:24 +0100)]
mtd: rawnand: sunxi: replace hard coded value by a define - take2
The user data length (4) has been replaced almost all over the file, but
2 places were forgotten.
The user data is placed before the ECC, for each step.
So, in sunxi_nfc_hw_ecc_read_extra_oob(), the offset of the user data in
OOB is indeed ((ecc->bytes + USER_DATA_SZ) * ecc->steps);
And in sunxi_nand_ooblayout_ecc(), the offset of the ECC chunk in OOB is
the same offset plus the current user data size:
section * (ecc->bytes + USER_DATA_SZ) + USER_DATA_SZ;
Richard Genoud [Tue, 17 Mar 2026 14:24:31 +0000 (15:24 +0100)]
mtd: rawnand: sunxi: do not count BBM bytes twice
BBM is already part of USER_DATA section, so we should not remove it twice
This was working ok because we are on the safe size, advertising that
there was 2 bytes less available than in reality.
But we can't change old platforms, since it may lead to a different ECC
strength, so, introduce a legacy flag for old platforms, and switch the
new platforms to the correct count.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
*cur_off (offset from the beginning of the page) was compared to offset
(offset from the beginning of the OOB), and then, the
nand_change_read_column_op() sets the current position to the beginning
of the OOB instead of OOB+offset
The available length is really USER_DATA_LEN - 2 instead of just 2 (the
user data length minus the BBM length)
USER_DATA_LEN being 4, that doesn't change anything now, but if
USER_DATA_LEN changes, it will.
Saranya Gopal [Fri, 13 Mar 2026 10:03:37 +0000 (12:03 +0200)]
mfd: intel-lpss: Add Intel Nova Lake-H PCI IDs
Add Intel Nova Lake-H LPSS PCI IDs.
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com> Co-developed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260313100337.3471-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
Jianmin Lv [Fri, 20 Mar 2026 10:10:12 +0000 (18:10 +0800)]
MAINTAINERS: Update GPU driver maintainer information
I and Qianhai are GPU R&D engineers at Loongson, specializing
in kernel driver development. We understand that the current
Loongson GPU driver lacks dedicated maintenance resources
because of some reasons.
As Loongson GPU driver developers, we have both the capability
and the responsibility to continuously maintain the Loongson
GPU driver, ensuring minimal impact on its users. After internal
discussions, our team has decided to recommend me and Qianhai
to take over the maintenance responsibilities, and recommend
Huacai, Mingcong and Ruoyao to help to review.
And We'll continue to maintain it for current supported chips
and drive future updates according to chip support plan.
Deprecate simple-encoder and simple-display-pipe helpers in favor of
regular atomic helpers. Remove the related documentation. Add TODO
item for converting the remaining drivers.
These helpers have been deprecated for years and many drivers have
been updated to not use them. Still there are a few left and we
occasionally receive new drivers build upon them. Marking them as
deprecated will hopefully resolve these problems. The TODO items
should be easy enough for getting new voluteers started on DRM driver
development.
drm/st7735r: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct st7735r_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. St7735r requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/st7586: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct st7586_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. St7586 requires custom helpers for
various pipeline elements, and non-freeing cleanup of the pipeline.
v3:
- return early in st7586_plane_helper_atomic_update (David)
v2:
- fix connector initialization
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-12-tzimmermann@suse.de
drm/panel-mipi-dbi: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct panel_mipi_dbi_device and initialize them as
part of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Panel-mipi-dbi requires a custom helper
for CRTC enablement, and non-freeing cleanup of the pipeline.
v2:
- fix connector initialization
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-11-tzimmermann@suse.de
drm/mi0283qt: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct mi0283qt_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Mi0283qt requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9486: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9486_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9486 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9341: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9341_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9341 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/ili9225: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9225_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9225 requires custom helpers for
various pipeline elements, and non-freeing cleanup of the pipeline.
drm/ili9163: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct ili9163_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Ili9163 requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/hx8357d: Use regular atomic helpers; drop simple-display helpers
Replace simple-display helpers with regular atomic helpers. Store the
pipeline elements in struct hx8357d_device and initialize them as part
of probing the device. Use mipi-dbi's existing helpers and initializer
macros where possible.
Effectively open-codes the modesetting code in the initializer helpers
of mipi-dbi and simple-display. Hx8357d requires a custom helper for
CRTC enablement, and non-freeing cleanup of the pipeline.
drm/mipi-dbi: Provide callbacks for atomic interfaces
Refactor the existing simple-display callbacks such that they invoke
helpers compatible with regular atomic modesetting. Allows for adding
mipi-dbi drives that do not require simple-display helpers.
Provide initializer macro for elements of the regular modesetting
pipeline. These will be used by drivers to integrate mipi-dbi helpers.
Also provide initializer macros for the plane formats.
As the new helpers are DRM functions, add the drm_ prefix. Mipi-dbi
interfaces currently lack this.
v3:
- fix uninitialized variable (David)
- document public interfaces (David)
- mention format macros in commit message (David)
drm/mipi-dbi: Support custom pipelines with drm_mipi_dbi_dev_init()
Initialize the mipi-dbi device with drm_mipi_dbi_dev_init() without
creating a modesetting pipeline. Will allow for mipi-dbi drivers
without simple-display helpers.
As the new helper is a DRM function, add the drm_ prefix. Mipi-dbi
interfaces currently lack this.
Use drm_atomic_helper_commit_tail_rpm() as commit tail to update the
plane after enabling the CRTC. Then remove the plane-update code from
mipi_dbi_enable_flush() and inline the remaining backlight code where
necessary.
Mipi-dbi's current commit tail drm_atomic_helper_commit_tail() first
updates the plane and then enables the CRTC. But the CRTC enablement
includes power management that prevents the initial plane update from
working. Hence, each mipi-dbi driver includes a plane update in their
CRTC enablement; in the form of mipi_dbi_enable_flush() or custom code.
Using drm_atomic_helper_commit_tail_rpm() enables the CRTC before any
plane updates. Hence the additional plane update can be removed from
mipi_dbi_enable_flush() and a number of drivers.
This leaves backlight_enable() in the helper, which can now be inlined
into affected drivers. Drivers now enable the CRTC plus an optional
backlight and then automatically update the plane.
In the case of disabling the display, drm_atomic_helper_commit_tail_rpm()
only disables the CRTC without touching the plane at all. Mipi-dbi's
mipi_dbi_pipe_disable() already contains the necessary logic.
Removing the plane update from the CRTC enablement will also help with
converting mipi-dbi from simple-pipe helpers to regular atomic helpers.
Sanman Pradhan [Wed, 25 Mar 2026 05:13:06 +0000 (05:13 +0000)]
hwmon: (adm1177) fix sysfs ABI violation and current unit conversion
The adm1177 driver exposes the current alert threshold through
hwmon_curr_max_alarm. This violates the hwmon sysfs ABI, where
*_alarm attributes are read-only status flags and writable thresholds
must use currN_max.
The driver also stores the threshold internally in microamps, while
currN_max is defined in milliamps. Convert the threshold accordingly
on both the read and write paths.
Widen the cached threshold and related calculations to 64 bits so
that small shunt resistor values do not cause truncation or overflow.
Also use 64-bit arithmetic for the mA/uA conversions, clamp writes
to the range the hardware can represent, and propagate failures from
adm1177_write_alert_thr() instead of silently ignoring them.
Update the hwmon documentation to reflect the attribute rename and
the correct units returned by the driver.
Fixes: 09b08ac9e8d5 ("hwmon: (adm1177) Add ADM1177 Hot Swap Controller and Digital Power Monitor driver") Signed-off-by: Sanman Pradhan <psanman@juniper.net> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20260325051246.28262-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Henry Tseng [Tue, 24 Mar 2026 09:09:48 +0000 (17:09 +0800)]
cpufreq: acpi-cpufreq: use DMI max speed when CPPC is unavailable
On AMD Ryzen Embedded V1780B (Family 17h, Zen 1), the BIOS does not
provide ACPI _CPC objects and the CPU does not support MSR-based CPPC
(X86_FEATURE_CPPC). The _PSS table only lists nominal P-states
(P0 = 3350 MHz), so when get_max_boost_ratio() fails at
cppc_get_perf_caps(), cpuinfo_max_freq reports only the base frequency
instead of the rated boost frequency (3600 MHz).
dmesg:
ACPI CPPC: No CPC descriptor for CPU:0
acpi_cpufreq: CPU0: Unable to get performance capabilities (-19)
cppc-cpufreq already has a DMI fallback (cppc_get_dmi_max_khz()) that
reads the processor max speed from SMBIOS Type 4. Export it and reuse
it in acpi-cpufreq as a last-resort source for the boost frequency.
A sanity check ensures the DMI value is above the _PSS P0 frequency
and within 2x of it; values outside that range are ignored and the
existing arch_set_max_freq_ratio() path is taken instead. The 2x
upper bound is based on a survey of the AMD Ryzen Embedded V1000
series, where the highest boost-to-base ratio is 1.8x (V1404I:
2.0 GHz base / 3.6 GHz boost).
The DMI lookup and sanity check are wrapped in a helper,
acpi_cpufreq_resolve_max_freq(), which falls through to
arch_set_max_freq_ratio() if the DMI value is absent or
out of range.
Tested on AMD Ryzen Embedded V1780B with v7.0-rc4:
acpi_pptt_cache_v1_full was initially added as a stop gap until the
equivalent structure imported from ACPICA, acpi_pptt_v1 in actbl2.h,
contained all the fields of the Cache Type Structure.
Since commit 091c4af3562d ("ACPICA: ACPI 6.4: PPTT: include all
fields in subtable type1"), acpi_pptt_v1 contains all these fields
making acpi_pptt_cache_v1_full redundant.
Remove acpi_pptt_cache_v1_full.
No functional change intended.
Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
[ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260324113300.1002569-1-ben.horgan@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Every doit handler followed the same pattern: stack-allocate an
adm_ctx, call drbd_adm_prepare() at the top, call drbd_adm_finish()
at the bottom. This duplicated boilerplate across 25 handlers and
made error paths inconsistent, since some handlers could miss sending
the reply skb on early-exit paths.
The generic netlink framework already provides pre_doit/post_doit
hooks for exactly this purpose. An old comment even noted "this
would be a good candidate for a pre_doit hook".
Use them:
- pre_doit heap-allocates adm_ctx, looks up per-command flags from a
new drbd_genl_cmd_flags[] table, runs drbd_adm_prepare(), and
stores the context in info->user_ptr[0].
- post_doit sends the reply, drops kref references for
device/connection/resource, and frees the adm_ctx.
- Handlers just receive adm_ctx from info->user_ptr[0], set
reply_dh->ret_code, and return. All teardown is in post_doit.
- drbd_adm_finish() is removed, superseded by post_doit.
Damon Ding [Mon, 10 Nov 2025 08:58:23 +0000 (16:58 +0800)]
drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages and pre-emphasises
Replace analogix_dp_get_adjust_request_voltage() and
analogix_dp_get_adjust_request_pre_emphasis() with existing DP helper
APIs with the same function.
Add a new options that causes zloop to truncate the zone files to the
write pointer value recorded at the last cache flush to simulate
unclean shutdowns.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://patch.msgid.link/20260323071156.2940772-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Split out two helpers functions to make the function more readable and
to avoid conditional locking.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://patch.msgid.link/20260323071156.2940772-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Svyatoslav Ryhel [Thu, 12 Mar 2026 08:52:56 +0000 (10:52 +0200)]
dt-bindings: mfd: max77620: Convert to DT schema
Convert max77620 Device Tree bindings from TXT to YAML format. This patch
does not change any functionality; the bindings remain the same. The
thermal bindings are incorporated into the binding. GPIO controller
function in MAX77620 has no dedicated node and is folded into the parent
node itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260312085258.11431-4-clamor95@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
mfd: ezx-pcap: Avoid rescheduling after destroying workqueue
Driver allocates workqueue and then registers additional interrupt
handler with devm interface. This means that device removal will not
use a reversed order, but first destroy workqueue and then, via devm
release handlers, free the interrupt.
The interrupt handler registered with devm does not directly
use/schedule work items on the workqueue and the remove() function
correctly removes other IRQs handlers, however the code mixing devm and
non-devm interfaces is difficult to analyze and read.
Make the code flow much more obvious by using devm interface for
allocating the workqueue, so it will be freed with the rest of devm
resources.
Change is not equivalent in the workqueue itself: use non-legacy API
which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is
used to update device registers, thus there is no point to run it for
memory reclaim.
Phil Elwell [Fri, 6 Mar 2026 23:41:22 +0000 (00:41 +0100)]
mfd: bcm2835-pm: Add BCM2712 PM device support
The BCM2712 SoC includes a power management block that serves as the
power domain for the V3D graphics block. Unlike other PM blocks in
the BCM2835 family, it does not feature an ASB register space.
Conditionally register the PM device depending on the SoC variant.
Signed-off-by: Phil Elwell <phil@raspberrypi.com> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/c0b5793868f138bf5c928a12b2763d3e183e2e59.1772839224.git.andrea.porta@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
Phil Elwell [Fri, 6 Mar 2026 23:41:21 +0000 (00:41 +0100)]
mfd: bcm2835-pm: Introduce SoC-specific type identifier
Power management blocks across the BCM2835 family share a common
base but require variant-specific handling. For instance, the
BCM2712 lacks ASB register space, yet it manages the power domain
for the V3D graphics block.
Add a hardware type identifier to the driver's private data. This
allows the driver to distinguish between SoC models and implement
custom quirks or features as needed.
Signed-off-by: Phil Elwell <phil@raspberrypi.com> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/c4bb218654e91f312a01b419d3d408e5131f7673.1772839224.git.andrea.porta@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
The ROHM BD79300 is almost identical to the BD72720. Main differences
are the initial values for some of the registers. Thus, it appears the BD79300 can be handled with same software as BD72720.
Adding the compatible for the BD79300 enables people to use the real IC
type in the device-tree instead of claiming it is BD72720. This does
also help differentiating the ICs if appears it is needed.
Add own compatible for the BD73900 and mark BD72720 as a fall-back.
Randy Dunlap [Mon, 9 Mar 2026 21:42:23 +0000 (14:42 -0700)]
mfd: si476x: Fix kernel-doc warnings
Add kernel-doc entries for missing fields or correct some typos
in names to eliminate kernel-doc warnings:
Warning: include/linux/mfd/si476x-core.h:156 struct member 'regmap' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'power_state'
not described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'supplies' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'is_alive' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'rds_fifo_depth'
not described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:170 function parameter 'core' not
described in 'si476x_core_lock'
Warning: include/linux/mfd/si476x-core.h:179 function parameter 'core' not
described in 'si476x_core_unlock'
Warning: include/linux/mfd/si476x-core.h:259 struct member 'firmware' not
described in 'si476x_func_info'
Warning: include/linux/mfd/si476x-core.h:335 struct member 'rds' not
described in 'si476x_rds_status_report'
I don't know what the 'ble' field is so I didn't add a kernel-doc comment
for it:
Warning: include/linux/mfd/si476x-core.h:335 struct member 'ble' not
described in 'si476x_rds_status_report'
Randy Dunlap [Mon, 9 Mar 2026 21:42:21 +0000 (14:42 -0700)]
mfd: kempld: Fix kernel-doc struct member names
Correct the struct member names to avoid kernel-doc warnings:
Warning: include/linux/mfd/kempld.h:114 struct member 'gpio_base' not
described in 'kempld_platform_data'
Warning: include/linux/mfd/kempld.h:114 struct member 'get_hardware_mutex'
not described in 'kempld_platform_data'
Warning: include/linux/mfd/kempld.h:114 struct member
'release_hardware_mutex' not described in 'kempld_platform_data'
Randy Dunlap [Mon, 9 Mar 2026 21:42:20 +0000 (14:42 -0700)]
mfd: congatec: Fix kernel-doc struct member names
Correct the struct member names to avoid kernel-doc warnings:
Warning: include/linux/mfd/cgbc.h:38 struct member 'version' not
described in 'cgbc_device_data'
Warning: ../include/linux/mfd/cgbc.h:38 struct member 'lock' not
described in 'cgbc_device_data'
Johan Hovold [Thu, 5 Mar 2026 10:40:51 +0000 (11:40 +0100)]
mfd: viperboard: Drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Subhash Rawat [Tue, 3 Mar 2026 18:32:36 +0000 (18:32 +0000)]
mfd: dln2: Switch to managed resources and fix bare unsigned types
Convert dln2_probe and dln2_setup_rx_urbs to use devm_kzalloc() and
devm_kmalloc() respectively. This simplifies resource management by
allowing the removal of manual kfree() calls in dln2_free() and
dln2_free_rx_urbs().
Additionally, update bare 'unsigned' types to 'unsigned int' to satisfy
checkpatch.pl warnings and comply with the Linux kernel coding style.
Hector Martin [Tue, 17 Feb 2026 10:47:26 +0000 (21:47 +1100)]
mfd: macsmc: Wire up Apple SMC power driver
Add the cell for the macsmc-power driver so it is probed by the
MFD core.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com> Link: https://patch.msgid.link/20260217-b4-macsmc-power-v7-2-4a4d63664362@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
The current configuration incorrectly uses the revision code as the CID.
Therefore, the driver cannot detect the same PMIC of different revisions.
(E1/E2 for MT6328, E1/E3 for MT6331/MT6332)
Based on these, the CID of MT6328, MT6331 and MT6332 should be corrected.
Additionally, the incorrect MT6331/MT6332 CID overlaps with the MT6320's
actual CID:
Add supply properties that match the P1 PMIC's actual hardware topology
where each buck converter has its own VIN pin and LDO groups share
common input pins. Supply names are defined according to the pinout
names in the P1 datasheet.
The existing "vin-supply" is dropped from the binding document as the
updated spacemit P1 driver no longer parses it. Only the per-rail names
("vin1-supply", "vin2-supply", ...) are supported.
mfd: lpc_ich: Expose the GPIO controller cell's software node
One of the users of this driver - meraki-mx100 - abuses the software
node API by setting up a dummy software node without any logical link to
this GPIO controller and uses the fact that the GPIO core matches the
controller's label against the swnode's name to make the lookup work.
We want to remove this behavior from GPIOLIB in favor of actual matching
of firmware nodes but that would break this user. To facilitate that:
create a software node for the GPIO controller cell and expose its
address in the provided MFD header.
mfd: atmel-hlcdc: Fetch LVDS PLL clock for LVDS display
The XLCDC IP supports parallel RGB, MIPI DSI and LVDS Display.
The LCD Generic clock (sys_clk) is used for Parallel RGB and MIPI
displays, while the LVDS PLL clock (lvds_pll_clk) is used for LVDS
displays.Since both the clocks cannot co-exist together in the DT
for a given display, this patch tries sys_clk first (RGB/MIPI),
fallback to lvds_pll_clk (LVDS).
Johan Hovold [Thu, 5 Mar 2026 13:03:58 +0000 (14:03 +0100)]
mfd: dln2: Drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Marek Vasut [Thu, 22 Jan 2026 11:13:21 +0000 (12:13 +0100)]
mfd: stpmic1: Attempt system shutdown twice in case PMIC is confused
Attempt to shut down again, in case the first attempt failed.
The STPMIC1 might get confused and the first regmap_update_bits()
returns with -ETIMEDOUT / -110 . If that or similar transient
failure occurs, try to shut down again. If the second attempt
fails, there is some bigger problem, report it to user.
Cc: stable@vger.kernel.org Fixes: 6e9df38f359a ("mfd: stpmic1: Add PMIC poweroff via sys-off handler") Signed-off-by: Marek Vasut <marex@nabladev.com> Link: https://patch.msgid.link/20260122111423.62591-1-marex@nabladev.com Signed-off-by: Lee Jones <lee@kernel.org>
Kexin Sun [Sat, 21 Mar 2026 10:57:59 +0000 (18:57 +0800)]
iommufd: update outdated comment for renamed iommufd_hw_pagetable_alloc()
The function iommufd_hw_pagetable_alloc() was renamed to
iommufd_hwpt_paging_alloc() by commit 89db31635c87
("iommufd: Derive iommufd_hwpt_paging from
iommufd_hw_pagetable"). Update the stale reference in
iommufd_device_auto_get_domain().
ASoC: dt-bindings: mediatek,mt2701-wm8960: Correctly use additionalProperties
The binding does not reference any other schema, thus should use
"additionalProperties: false" to disallow any undocumented properties.
Correct the code and place this after "required:" block to match
convention expressed in example-schema.yaml.
Thomas Weißschuh [Mon, 16 Mar 2026 16:51:58 +0000 (17:51 +0100)]
kbuild: uapi: move some compiler arguments out of the command definition
Simplify the definition of cmd_hdrtest by moving some of it to a new
variable. This will both enable the upcoming reuse of those flags
and also the extension of cmd_hdrtest.
Shuming Fan [Wed, 25 Mar 2026 09:20:17 +0000 (17:20 +0800)]
ASoC: SDCA: remove the max count of initialization table
The number of the initialization table may exceed 2048.
Therefore, this patch removes the limitation and allows the driver to
allocate memory dynamically based on the size of the initialization table.
drm/msm/dsi: Add support for RGB101010 pixel format
Add video and command mode destination format mappings for RGB101010,
and extend the VID_CFG0 DST_FORMAT bitfield to 3 bits to accommodate
the new format value.
Make sure this is guarded behind MSM_DSI_6G_VER >= V2.1.0 as anything
older does not support this.
Required for 10 bit panels such as the BOE BF068MWM-TD0 found on the
Nothing Phone (3a).
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713721/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-5-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0
The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039
("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was
always correct just the name was wrong.
Rename and reorder to maintain version sorting.
Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Which seems to hint that the vma we are re-inserting for the ops unwind
is either invalid or overlapping with something already inserted in the
vm. It shouldn't be invalid since this is a re-insertion, so must have
worked before. Leaving the likely culprit as something already placed
where we want to insert the vma.
Following from that, for the case where we do something like a rebind in
the middle of a vma, and one or both mapped ends are already compatible,
we skip doing the rebind of those vma and set next/prev to NULL. As well
as then adjust the original unmap va range, to avoid unmapping the ends.
However, if we trigger the unwind path, we end up with three va, with
the two ends never being removed and the original va range in the middle
still being the shrunken size.
If this occurs, one failure mode is when another unwind op needs to
interact with that range, which can happen with a vector of binds. For
example, if we need to re-insert something in place of the original va.
In this case the va is still the shrunken version, so when removing it
and then doing a re-insert it can overlap with the ends, which were
never removed, triggering a warning like above, plus leaving the vm in a
bad state.
With that, we need two things here:
1) Stop nuking the prev/next tracking for the skip cases. Instead
relying on checking for skip prev/next, where needed. That way on the
unwind path, we now correctly remove both ends.
2) Undo the unmap va shrinkage, on the unwind path. With the two ends
now removed the unmap va should expand back to the original size again,
before re-insertion.
v2:
- Update the explanation in the commit message, based on an actual IGT of
triggering this issue, rather than conjecture.
- Also undo the unmap shrinkage, for the skip case. With the two ends
now removed, the original unmap va range should expand back to the
original range.
v3:
- Track the old start/range separately. vma_size/start() uses the va
info directly.
Add MIPI_DSI_FMT_RGB101010 for 30 bit (10,10,10 RGB) pixel format,
corresponding to the packed 30 bit pixel stream defined in MIPI DSI
v1.3 Section 8.8.17.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713714/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-1-ff6afc904115@pm.me
[Acked by Maxime to be merged through msm-next on IRC on dri-devel]
[DB: moved RGB101010 to the end of enum mipi_dsi_pixel_format] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Damon Ding [Tue, 11 Nov 2025 02:21:03 +0000 (10:21 +0800)]
drm/bridge: analogix_dp: Reuse &link_train.training_lane[] to set DPCD DP_TRAINING_LANEx_SET
In analogix_dp_link_start(), &link_train.training_lane[] is used to
set phy PE/VS configurations, and buf[] is initialized with the same
values to set DPCD DP_TRAINING_LANEx_SET.
It makes sense to reuse &link_train.training_lane[] to set DPCD
DP_TRAINING_LANEx_SET, which can remove the redundant assignments
and make codes more concise.
Which seems to hint that the vma we are re-inserting for the ops unwind
is either invalid or overlapping with something already inserted in the
vm. It shouldn't be invalid since this is a re-insertion, so must have
worked before. Leaving the likely culprit as something already placed
where we want to insert the vma.
Following from that, for the case where we do something like a rebind in
the middle of a vma, and one or both mapped ends are already compatible,
we skip doing the rebind of those vma and set next/prev to NULL. As well
as then adjust the original unmap va range, to avoid unmapping the ends.
However, if we trigger the unwind path, we end up with three va, with
the two ends never being removed and the original va range in the middle
still being the shrunken size.
If this occurs, one failure mode is when another unwind op needs to
interact with that range, which can happen with a vector of binds. For
example, if we need to re-insert something in place of the original va.
In this case the va is still the shrunken version, so when removing it
and then doing a re-insert it can overlap with the ends, which were
never removed, triggering a warning like above, plus leaving the vm in a
bad state.
With that, we need two things here:
1) Stop nuking the prev/next tracking for the skip cases. Instead
relying on checking for skip prev/next, where needed. That way on the
unwind path, we now correctly remove both ends.
2) Undo the unmap va shrinkage, on the unwind path. With the two ends
now removed the unmap va should expand back to the original size again,
before re-insertion.
v2:
- Update the explanation in the commit message, based on an actual IGT of
triggering this issue, rather than conjecture.
- Also undo the unmap shrinkage, for the skip case. With the two ends
now removed, the original unmap va range should expand back to the
original range.
v3:
- Track the old start/range separately. vma_size/start() uses the va
info directly.
Antonio Hickey [Thu, 19 Mar 2026 09:35:28 +0000 (10:35 +0100)]
rust: pin-init: replace `addr_of_mut!` with `&raw mut`
`feature(raw_ref_op)` became stable in Rust 1.82.0 which is the current
MSRV of pin-init with no default features. Earlier Rust versions will
now need to enable `raw_ref_op` to continue to work with pin-init.
This reduces visual complexity and improves consistency with existing
reference syntax.
projects / thirdparty / linux.git / log
