Since the USB core code handles the generic USB PHYs automatically, the
optional PHY handling code has been removed from the 'ehci-orion' driver
entirely by commit e04585184d ("usb: ehci-orion: avoid double PHY
initialization"). However, the devm_phy_optional_get() call has been kept
so the driver still gets the PHY even though it is not used for anything
in the driver.
Drop the remaining code, and also remove the 'phy' member of the
'orion_ehci_hcd' structure to simplify the code.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260221-ehci-orion-drop-phy-handling-v2-1-5e26aa73790b@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The musb IP on mpfs and pic64gx has a reset pin, but until now this has
been undocumented because platform firmware takes the block out of reset
on first-party boards (or those using modified versions of the vendor
firmware), but not all boards may take this approach. Permit providing a
reset in devicetree for Linux, or other devicetree-consuming software,
to use.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260303-backspace-unhearing-c6cc8cbddbba@spud
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As the PHY subsystem already synchronizes concurrent accesses to a PHY
instance with a core-internal mutex remove the driver specific mutex
synchronization.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Link: https://patch.msgid.link/20260127-diogo-tegra_phy-v2-2-787b9eed3ed5@tecnico.ulisboa.pt
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reference usb-xhci.yaml in host mode in order to support on-board USB
hubs.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260226153859.665901-2-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cezary Rojewski <cezary.rojewski@intel.com> says:
ASoC: Intel: catpt: Overhaul volume and mute control operations
Short summary first, longer description later:
- fix the return code for kctl->put() - currently the driver returns
'0' even if changes were done
- lower power consumption for kctl operations by waking the DSP only
when some streaming is done. No streaming? Cache the values and
inform the AudioDSP firmware later.
- drop the existing code duplication between individual and master
volume controls
The very first patch addresses synchronization problem that exists when
an individual control and its paired stream are manipulated by a user
simultaneously. As the refactor integrates the fix in its new code,
most of it gets shuffled but in case of a "refactor problem" I've
decided to have it separated and leading the series. This way the
problem is fixed even if refactor, for whatever reason, would be
reverted.
--
More of in-depth explanation for the refactor, taken from commit 2:
The catpt-driver's volume and mute control operations always return '0'
regardless if a change occurred or not. To conform to ALSA's interface,
value '1' shall be returned when a change occurred.
The second major point is power consumption. Existing control
operations always wake the DSP even if no streams are running. In such
case waking the DSP just for the sake of updating the volume (or mute)
settings on the firmware side is a waste of power. The provided
implementation caches the values and updates the settings only when
streams are being opened for streaming or are already running.
As changing existing code is non-trivial, provide new operations
instead. The put() operation, which interests us the most, takes the
following shape:
// two values provided to put():
// @pin_id - which stream given control relates to
// @value_to_apply - the value from user
if (control->existing_val == value_to_apply)
return 0;
runtime_stream = get_running_stream(pin_id);
if (runtime_stream != NULL) {
ret = send_ipc();
if (ret)
return ret;
}
control->existing_val = value_to_apply;
return 1;
Adheres to ALSA's expectation and avoids sending IPCs if there is no
change to be made.
Switch to the new implementation and remove all unused code. The change
effectively causes the control put() operations to return '1' if a
change occurred, '0' if no change was made or error otherwise.
The second effect of the update is reducing the power consumption. With
the new control-operations in place, the controls no longer wake the DSP
just for the sake of updating volume (or mute) settings on the firmware
side. The values are cached and actual update occurs only when streams
are being opened for streaming or are already running.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With the new control-operations in place, the controls no longer wake
the DSP just for the sake of updating volume (or mute) settings on the
firmware side. The values are cached and actual update occurs only when
streams are being opened for streaming or are already running. In those
cases the DSP must already be woken up and we avoid unnecessary power
consumption.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Existing catpt_dai_apply_usettings() applies all the individual control
settings but why-what is covered behind if-statements. Refactor the
operation into:
catpt_apply_controls()
|__ catpt_apply_volume()
|__ catpt_apply_mute()
to make it easy to understand why and what is going on. The update also
enlists snd_ctl_find_id_mixer() for the query purpose, removing code
duplication.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The catpt-driver's volume and mute control operations always return '0'
regardless if a change occurred or not. To conform to ALSA's interface,
value '1' shall be returned when a change occurred.
The second major point is power consumption. Existing control operations
always wake the DSP even if no streams are running. In such case waking
the DSP just for the sake of updating the volume (or mute) settings on
the firmware side is a waste of power. The provided implementation
caches the values and updates the settings only when streams are being
opened for streaming or are already running.
As changing existing code is non-trivial, provide new operations
instead. The put() operation, which interests us the most, takes the
following shape:
// two values provided to put():
// pin_id - which stream given control relates to
// value_to_apply - the value from user
if (control->existing_val == value_to_apply)
return 0;
runtime_stream = get_running_stream(pin_id);
if (runtime_stream != NULL) {
ret = send_ipc();
if (ret)
return ret;
}
control->existing_val = value_to_apply;
return 1;
Adheres to ALSA's expectation and avoids sending IPCs if there is no
change to be made.
Two helpers which are part of the patch, catpt_stream_hw_id() and
catpt_stream_volume_regs(), help differentiate between individual
streams and the general MIXER stream. Translates to one pair of
get()/put() instead of two pairs as done currently.
PIN_ID_INVALID is returned if given stream is not currently running -
the constant is part of the firmware's API but remained unused by the
driver.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Streams may have individual controls assigned to them e.g.: volume
control in case of offload streams.
If such a stream is running and simultaneously its controls are being
manipulated, both processes are touching the exact same descriptors -
access to these must be synchronized. Replace spinlock with mutex as
IPCs are non-atomic operations and add proper locking for all
->stream_list users.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The acp3x_5682_init() function did not check the return value of
clk_get(), which could lead to dereferencing error pointers in
rt5682_clk_enable().
Fix this by:
1. Changing clk_get() to the device-managed devm_clk_get().
2. Adding proper IS_ERR() checks for both clock acquisitions.
Fixes: 6b8e4e7db3 ("ASoC: amd: Add machine driver for Raven based platform")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20260310024246.2153827-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
initialized, and dmc is thus NULL.
That would be the case when the call path is
intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
intel_power_domains_init_hw() is called *before* intel_dmc_init().
However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
conditionally, depending on the current and target DC states. At probe,
the target is disabled, but if DC6 is enabled, the function is called,
and an oops follows. Apparently it's quite unlikely that DC6 is enabled
at probe, as we haven't seen this failure mode before.
It is also strange to have DC6 enabled at boot, since that would require
the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and
the driver stopping / reprogramming the firmware is a poorly specified
sequence and as such unlikely an intentional BIOS behaviour. It's more
likely that BIOS is leaving an unintentionally enabled DC6 HW state
behind (without actually loading the required DMC firmware for this).
The tracking of the DC6 allowed counter only works if starting /
stopping the counter depends on the _SW_ DC6 state vs. the current _HW_
DC6 state (since stopping the counter requires the DC5 counter captured
when the counter was started). Thus, using the HW DC6 state is incorrect
and it also leads to the above oops. Fix both issues by using the SW DC6
state for the tracking.
This is v2 of the fix originally sent by Jani, updated based on the
first Link: discussion below.
Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com
Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com
Fixes: 88c1f9a4d3 ("drm/i915/dmc: Create debugfs entry for dc6 counter")
Cc: Mohammed Thasleem <mohammed.thasleem@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Tao Liu <ltao@redhat.com>
Cc: <stable@vger.kernel.org> # v6.16+
Tested-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com
It is possible that devices tristate buffers may set the buffer to
the high-Z state in addition to setting pull-up or pull-down on a pin.
Remove this particular restriction to prevent warning on zynqmp systems
where this configuration seems to be valid.
Reported-by: Rob Herring (Arm) <robh@kernel.org>
Fixes: a901e8705f ("dt-bindings: pinctrl: pincfg-node: add restrictions on conflicting properties")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Recognize new SMCA bank types and include their short names for sysfs
and long names for decoding.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260307163316.345923-4-yazen.ghannam@amd.com
Recent documentation updated the "CS" bank type name from "Coherent
Slave" to "Coherent Station".
Apply this change in the kernel also.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260307163316.345923-3-yazen.ghannam@amd.com
Originally, the SMCA bank type enums were ordered based on processor
documentation. However, the ordering became inconsistent after new bank
types were added over time.
Sort the bank type enums alphanumerically in most places. Sort the
"enum to HWID/McaType" mapping by HWID/McaType. Drop redundant code
comments.
No functional changes.
[ bp: Sort them alphanumerically. ]
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260307163316.345923-2-yazen.ghannam@amd.com
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled(). Moreover, it is no longer necessary to
unprepare and disable the clocks explicitly.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/e53aefc63e28caf32bcd553f3d0a8f2a5a25cd8d.1773193726.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace direct import_attach test with drm_gem_is_imported()
in ivpu_bo_bind().
Replace kzalloc(sizeof(*bo), GFP_KERNEL) with kzalloc_obj()
in ivpu_gem_create_object().
Remove unnecessary cast to bool in ivpu_dbg_bo().
No functional changes.
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260310120736.3341679-1-karol.wachowski@linux.intel.com
xfs_bmap_update_diff_items() sorts bmap intents by inode number using
a subtraction of two xfs_ino_t (uint64_t) values, with the result
truncated to int. This is incorrect when two inode numbers differ by
more than INT_MAX (2^31 - 1), which is entirely possible on large XFS
filesystems.
Fix this by replacing the subtraction with cmp_int().
Cc: <stable@vger.kernel.org> # v4.9
Fixes: 9f3afb57d5 ("xfs: implement deferred bmbt map/unmap operations")
Signed-off-by: Long Li <leo.lilong@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Panther Lake supports the following requestable C-states: C1, C1E, C6S,
C10.
The parameters of these C-states should be consistent across all
systems based on Panther Lake, so add a custom C-states table for it
that will override C-state parameters supplied by platform firmware
that may vary from one platform to another and may not represent the
most optimum choice.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
[ rjw: Changelog expansion ]
Link: https://patch.msgid.link/20260309083818.79588-1-dedekind1@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Support for Dual SPI and Quad SPI was added to the Linux driver in
commit 0605d9fb41 ("spi: sun6i: add quirk for dual and quad SPI modes
support") and commit 25453d797d ("spi: sun6i: add dual and quad SPI
modes support for R329/D1/R528/T113s").
However the binding was never updated to allow these modes. Allow them
by adding 2 and 4 to the allowed bus widths for the newer variants.
While at it, also add 0 to the allowed bus widths. This signals that
RX or TX is not available, i.e. the MISO or MOSI pin is disconnected.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260302153559.3199783-2-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 8505bfb4e4 ("ACPI: CPPC: Move reference performance
to capabilities") introduced a logical error when retrieving
the reference performance.
On platforms lacking the reference performance register, the fallback
logic leaves the local 'ref' variable uninitialized (0). This causes
the subsequent sanity check to incorrectly return -EFAULT, breaking
amd_pstate initialization.
Fix this by assigning 'ref = nom' in the fallback path.
Fixes: 8505bfb4e4 ("ACPI: CPPC: Move reference performance to capabilities")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/all/20260310003026.GA2639793@ax162/
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260311071334.1494960-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The pointer returned from acpi_os_map_generic_address() is
tagged with __iomem, so make the rv it is returned to also
of void __iomem * type.
Fixes the following sparse warning:
drivers/acpi/osl.c:1686:20: warning: incorrect type in assignment (different address spaces)
drivers/acpi/osl.c:1686:20: expected void *rv
drivers/acpi/osl.c:1686:20: got void [noderef] __iomem *
Fixes: 6915564dc5 ("ACPI: OSL: Change the type of acpi_os_map_generic_address() return value")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[ rjw: Subject tweak, added Fixes tag ]
Link: https://patch.msgid.link/20260311105835.463030-1-ben.dooks@codethink.co.uk
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Chasing vfork()'ed tasks on a CID ownership mode switch requires a full
task list walk, which is obviously expensive on large systems.
Avoid that by keeping a list of tasks using a mm MMCID entity in mm::mm_cid
and walk this list instead. This removes the proven to be flaky counting
logic and avoids a full task list walk in the case of vfork()'ed tasks.
Fixes: fbd0e71dc3 ("sched/mmcid: Provide CID ownership mode fixup functions")
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260310202526.183824481@kernel.org
This is a leftover from the early versions of this function where it could
be invoked without mm::mm_cid::lock held.
Remove it and add lockdep asserts instead.
Fixes: 653fda7ae7 ("sched/mmcid: Switch over to the new mechanism")
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260310202526.116363613@kernel.org
Matthieu and Jiri reported stalls where a task endlessly loops in
mm_get_cid() when scheduling in.
It turned out that the logic which handles vfork()'ed tasks is broken. It
is invoked when the number of tasks associated to a process is smaller than
the number of MMCID users. It then walks the task list to find the
vfork()'ed task, but accounts all the already processed tasks as well.
If that double processing brings the number of to be handled tasks to 0,
the walk stops and the vfork()'ed task's CID is not fixed up. As a
consequence a subsequent schedule in fails to acquire a (transitional) CID
and the machine stalls.
Cure this by removing the accounting condition and make the fixup always
walk the full task list if it could not find the exact number of users in
the process' thread list.
Fixes: fbd0e71dc3 ("sched/mmcid: Provide CID ownership mode fixup functions")
Closes: https://lore.kernel.org/b24ffcb3-09d5-4e48-9070-0b69bc654281@kernel.org
Reported-by: Matthieu Baerts <matttbe@kernel.org>
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260310202526.048657665@kernel.org
A newly forked task is accounted as MMCID user before the task is visible
in the process' thread list and the global task list. This creates the
following problem:
CPU1 CPU2
fork()
sched_mm_cid_fork(tnew1)
tnew1->mm.mm_cid_users++;
tnew1->mm_cid.cid = getcid()
-> preemption
fork()
sched_mm_cid_fork(tnew2)
tnew2->mm.mm_cid_users++;
// Reaches the per CPU threshold
mm_cid_fixup_tasks_to_cpus()
for_each_other(current, p)
....
As tnew1 is not visible yet, this fails to fix up the already allocated CID
of tnew1. As a consequence a subsequent schedule in might fail to acquire a
(transitional) CID and the machine stalls.
Move the invocation of sched_mm_cid_fork() after the new task becomes
visible in the thread and the task list to prevent this.
This also makes it symmetrical vs. exit() where the task is removed as CID
user before the task is removed from the thread and task lists.
Fixes: fbd0e71dc3 ("sched/mmcid: Provide CID ownership mode fixup functions")
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260310202525.969061974@kernel.org
- Add a dedicated thread for each svc client to fix a timeout issue when the svc
driver is handling multiple clients.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEoHhMeiyk5VmwVMwNGZQEC4GjKPQFAmmwSAEACgkQGZQEC4Gj
KPT46A/+OTfiKnqA/yLr2phsyWfvZUIU99gcki+8dBRiMidKWyFQvBhGNZTg9SpS
onQN2rYXmnLFER54wP4xjPZyUbojlz46GUa6jI0i32o7HKVuuJ042jIPEnvdJxGL
3rSvox/lRXbO/Dey3n525tmn4Dx1Zc1hFXon40G+9LMdH/LpM8HIXFPDIG5pvsp6
+Ks0ZccS3Jr6WjIrYy8wBP2pWarKVkp5o/HKh5AkyS2EQ592+bpCsrCqmFrOgXWi
8Ev9zHOkEH13B8nqQ9kzncYr1an5+pWbXNQDTyBct3vN6RL+MRajp/MdLtBEdkDd
ADtJUlC/hB2ZrLsPfGoDoH3US5cgFtQ79hNOr8uCmdsuVIpzTl1UW/ZPkLvN2OLp
BFTzP8onKh6VDFHNO/bOWJPC/e3J6xEGjl/ANGw+wiG/8ZkMEJ+b+Rn9aqvifiuS
8IVqJKQhosd0wbyLN3z++lHNgOSxcbzhVhl5wVnF36ouPRgzC5XxeKHL+22YUDWE
YyTxiNFZoXbIcK9r8zNmciIpBwHGZyYHcXNgSs9+ldx4zyrPfiub386MFmxUmr5w
qwW/g9igxZMLAgR8Wdh5SlQG8AdIVWZ/ICSDnNjXBwC/3wubQWqVdbNRh4l0yzfK
Rl2pwFB3+NbJ9OXFwiUKLi7UHqEJPEPRC2BWK+hsfKbsWdMgV5k=
=nIUm
-----END PGP SIGNATURE-----
Merge tag 'stratix10_svc_fix_for_v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into char-misc-linus
Dinh writes:
firmware: stratix10-svc: add multiple svc clients support
- Add a dedicated thread for each svc client to fix a timeout issue when the svc
driver is handling multiple clients.
* tag 'stratix10_svc_fix_for_v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
firmware: stratix10-svc: Add Multi SVC clients support
Samsung's S2MU005 PMIC, which contains battery charger functionality
also includes a battery fuel gauge device, which is separate from the
PMIC itself, and typically connected to an I2C bus. Add a generic driver
to support said device.
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Co-developed-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://patch.msgid.link/20260304-s2mu005-fuelgauge-v3-2-e4dc4e47cde8@disroot.org
[Moved mutex init before power-supply registration]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Samsung S2MU005 is a PMIC device which has LED controllers, an MUIC and
a battery charger. The battery charger is paired with an independent
device connected via I2C which can be used to access various metrics of
the battery. Document the device as a schema.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://patch.msgid.link/20260304-s2mu005-fuelgauge-v3-1-e4dc4e47cde8@disroot.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The trace_clock_jiffies() function that handles the "uptime" clock for
tracing calls jiffies_64_to_clock_t(). This causes the function tracer to
constantly recurse when the tracing clock is set to "uptime". Mark it
notrace to prevent unnecessary recursion when using the "uptime" clock.
Fixes: 58d4e21e50 ("tracing: Fix wraparound problems in "uptime" trace clock")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260306212403.72270bb2@robin
Move the get/put/ref/flush_for_display calls to the display parent
interface.
For i915, move the hooks next to the other i915 core frontbuffer code in
i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for
the same.
Note: The intel_frontbuffer_flush() calls from
i915_gem_object_frontbuffer.c will partially route back to i915 core via
the parent interface. This is less than stellar.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed
through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might
as well call the functions directly, instead of going through display
code. This would only get worse with get/put being moved to the parent
interface.
To make this easier, convert overlay code from struct intel_frontbuffer
to struct i915_frontbuffer, and add a
i915_gem_object_frontbuffer_track() wrapper for clarity.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to
i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer
functions are there already, and the relevant declarations are in
i915_gem_object_frontbuffer.h too.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/d779ef44b4b43feda9df63f1225a947a9cd23ba8.1772475391.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
To: Linus Walleij <linusw@kernel.org>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Currently there are three different open-coded variants of a time
namespace aware variant of vdso_read_begin(). They make the code hard to
read and introduce an inconsistency, as only the first copy uses
unlikely().
Split the code into a shared helper function.
Move that next to the definition of the regular vdso_read_begin(), so
that any future changes can be kept in sync easily.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260227-vdso-cleanups-v1-2-c848b4bc4850@linutronix.de
This patch fixes an out-of-bounds access in ceph_handle_auth_reply()
that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In
ceph_handle_auth_reply(), the value of the payload_len field of such a
message is stored in a variable of type int. A value greater than
INT_MAX leads to an integer overflow and is interpreted as a negative
value. This leads to decrementing the pointer address by this value and
subsequently accessing it because ceph_decode_need() only checks that
the memory access does not exceed the end address of the allocation.
This patch fixes the issue by changing the data type of payload_len to
u32. Additionally, the data type of result_msg_len is changed to u32,
as it is also a variable holding a non-negative length.
Also, an additional layer of sanity checks is introduced, ensuring that
directly after reading it from the message, payload_len and
result_msg_len are not greater than the overall segment length.
BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]
Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262
CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: ceph-msgr ceph_con_workfn [libceph]
Call Trace:
<TASK>
dump_stack_lvl+0x76/0xa0
print_report+0xd1/0x620
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? kasan_complete_mode_report_info+0x72/0x210
kasan_report+0xe7/0x130
? ceph_handle_auth_reply+0x642/0x7a0 [libceph]
? ceph_handle_auth_reply+0x642/0x7a0 [libceph]
__asan_report_load_n_noabort+0xf/0x20
ceph_handle_auth_reply+0x642/0x7a0 [libceph]
mon_dispatch+0x973/0x23d0 [libceph]
? apparmor_socket_recvmsg+0x6b/0xa0
? __pfx_mon_dispatch+0x10/0x10 [libceph]
? __kasan_check_write+0x14/0x30i
? mutex_unlock+0x7f/0xd0
? __pfx_mutex_unlock+0x10/0x10
? __pfx_do_recvmsg+0x10/0x10 [libceph]
ceph_con_process_message+0x1f1/0x650 [libceph]
process_message+0x1e/0x450 [libceph]
ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]
? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph]
? save_fpregs_to_fpstate+0xb0/0x230
? raw_spin_rq_unlock+0x17/0xa0
? finish_task_switch.isra.0+0x13b/0x760
? __switch_to+0x385/0xda0
? __kasan_check_write+0x14/0x30
? mutex_lock+0x8d/0xe0
? __pfx_mutex_lock+0x10/0x10
ceph_con_workfn+0x248/0x10c0 [libceph]
process_one_work+0x629/0xf80
? __kasan_check_write+0x14/0x30
worker_thread+0x87f/0x1570
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? __pfx_try_to_wake_up+0x10/0x10
? kasan_print_address_stack_frame+0x1f7/0x280
? __pfx_worker_thread+0x10/0x10
kthread+0x396/0x830
? __pfx__raw_spin_lock_irq+0x10/0x10
? __pfx_kthread+0x10/0x10
? __kasan_check_write+0x14/0x30
? recalc_sigpending+0x180/0x210
? __pfx_kthread+0x10/0x10
ret_from_fork+0x3f7/0x610
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x385/0xda0
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
[ idryomov: replace if statements with ceph_decode_need() for
payload_len and result_msg_len ]
Cc: stable@vger.kernel.org
Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This patch fixes unnecessary implicit conversions that change signedness
of blob_len and num_mon in ceph_monmap_decode().
Currently blob_len and num_mon are (signed) int variables. They are used
to hold values that are always non-negative and get assigned in
ceph_decode_32_safe(), which is meant to assign u32 values. Both
variables are subsequently used as unsigned values, and the value of
num_mon is further assigned to monmap->num_mon, which is of type u32.
Therefore, both variables should be of type u32. This is especially
relevant for num_mon. If the value read from the incoming message is
very large, it is interpreted as a negative value, and the check for
num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to
allocate a very large chunk of memory for monmap, which will most likely
fail. In this case, an unnecessary attempt to allocate memory is
performed, and -ENOMEM is returned instead of -EINVAL.
Cc: stable@vger.kernel.org
Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
After sparc64, there are no remaining users of ARCH_CLOCKSOURCE_DATA
and it can just be removed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: John Stultz <jstultz@google.com>
Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-14-d8eb3b0e1410@linutronix.de
[Thomas: drop sparc64 bits from the patch]
To be y2038-safe, 32-bit userspace needs to explicitly call the 64-bit safe
time APIs.
Implement clock_gettime64() in the 32-bit vDSO.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: Andreas Larsson <andreas@gaisler.com>
Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-13-d8eb3b0e1410@linutronix.de
There are no handled symbols left.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: Andreas Larsson <andreas@gaisler.com>
Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-12-d8eb3b0e1410@linutronix.de
After the adoption of the generic vDSO library this symbol does not exist.
The alignment invariant is now guaranteed by the generic code.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: Andreas Larsson <andreas@gaisler.com>
Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-11-d8eb3b0e1410@linutronix.de
