| Age | Commit message (Collapse) | Author |
|---|
|
Accesses to the PTP_RTC_NANOSEC register are done through a hardcoded
address which doesn't match with the KSZ8463's register layout.
Add a new entry for the PTP_RTC_NANOSEC register in the regs[] tables.
Use the regs[] table to retrieve the PTP_RTC_NANOSEC register address
when accessing it.
Remove the macro defining the address to prevent further use.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260105-ksz-rework-v1-4-a68df7f57375@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Accesses to the PTP_CLK_CTRL register are done through a hardcoded
address which doesn't match with the KSZ8463's register layout.
Add a new entry for the PTP_CLK_CTRL register in the regs[] tables.
Use the regs[] table to retrieve the PTP_CLK_CTRL register address
when accessing it.
Remove the macro defining the address to prevent further use.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260105-ksz-rework-v1-3-a68df7f57375@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The PTP irq_chip operations use an hardcoded IRQ offset in the bit
logic. This IRQ offset isn't the same on KSZ8463 than on others switches
so it can't use the irq_chip operations.
Convey the interrupt bit offset through a new attribute in struct ksz_irq
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260105-ksz-rework-v1-2-a68df7f57375@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The IRQ logic of the KSZ8463 differs from that of other KSZ switches.
It doesn't have a 'mask' register but an 'enable' one instead. The
common IRQ framework can still be used though as soon as we reverse
the logic (using '1' to enable interrupts instead of '0') for KSZ8463
cases.
Move the initialization of the kirq->masked outside of
ksz_irq_common_setup() to keep this function truly common when
IRQ support for the KSZ8463 is added.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260105-ksz-rework-v1-1-a68df7f57375@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The introduction of PREEMPT_LAZY was for multiple reasons:
- PREEMPT_RT suffered from over-scheduling, hurting performance compared to
!PREEMPT_RT.
- the introduction of (more) features that rely on preemption; like
folio_zero_user() which can do large memset() without preemption checks.
(Xen already had a horrible hack to deal with long running hypercalls)
- the endless and uncontrolled sprinkling of cond_resched() -- mostly cargo
cult or in response to poor to replicate workloads.
By moving to a model that is fundamentally preemptable these things become
managable and avoid needing to introduce more horrible hacks.
Since this is a requirement; limit PREEMPT_NONE to architectures that do not
support preemption at all. Further limit PREEMPT_VOLUNTARY to those
architectures that do not yet have PREEMPT_LAZY support (with the eventual goal
to make this the empty set and completely remove voluntary preemption and
cond_resched() -- notably VOLUNTARY is already limited to !ARCH_NO_PREEMPT.)
This leaves up-to-date architectures (arm64, loongarch, powerpc, riscv, s390,
x86) with only two preemption models: full and lazy.
While Lazy has been the recommended setting for a while, not all distributions
have managed to make the switch yet. Force things along. Keep the patch minimal
in case of hard to address regressions that might pop up.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Link: https://patch.msgid.link/20251219101502.GB1132199@noisy.programming.kicks-ass.net
|
|
This colocates some hot fields in "struct rq" to be on the same cache line
as others that are often accessed at the same time or in similar ways.
Using data from a Google-internal fleet-scale profiler, I found three
distinct groups of hot fields in struct rq:
- (1) The runqueue lock: __lock.
- (2) Those accessed from hot code in pick_next_task_fair():
nr_running, nr_numa_running, nr_preferred_running,
ttwu_pending, cpu_capacity, curr, idle.
- (3) Those accessed from some other hot codepaths, e.g.
update_curr(), update_rq_clock(), and scheduler_tick():
clock_task, clock_pelt, clock, lost_idle_time,
clock_update_flags, clock_pelt_idle, clock_idle.
The cycles spent on accessing these different groups of fields broke down
roughly as follows:
- 50% on group (1) (the runqueue lock, always read-write)
- 39% on group (2) (load:store ratio around 38:1)
- 8% on group (3) (load:store ratio around 5:1)
- 3% on all the other fields
Most of the fields in group (3) are already in a cache line grouping; this
patch just adds "clock" and "clock_update_flags" to that group. The fields
in group (2) are scattered across several cache lines; the main effect of
this patch is to group them together, on a single line at the beginning of
the structure. A few other less performance-critical fields (nr_switches,
numa_migrate_on, has_blocked_load, nohz_csd, last_blocked_load_update_tick)
were also reordered to reduce holes in the data structure.
Since the runqueue lock is acquired from so many different contexts, and is
basically always accessed using an atomic operation, putting it on either
of the cache lines for groups (2) or (3) would slow down accesses to those
fields dramatically, since those groups are read-mostly accesses.
To test this, I wrote a focused load test that would put load on the
pick_next_task_fair() path. A parent process would fork many child
processes, and each child would nanosleep() for 1 msec many times in a
loop. The load test was monitored with "perf", and I looked at the amount
of cycles that were spent with sched_balance_rq() on the stack. The test
was reliably spending ~5% of all of its cycles there. I ran it 100 times
on a pair of 2-socket Intel Haswell machines (72 vCPUs per machine) - one
running the tip of sched/core, the other running this change - using 360
child processes and 8192 1-msec sleeps per child. The mean cycle count
dropped from 5.14B to 4.91B, or a *4.6% decrease* in relevant scheduler
cycles.
Given that this change reduces cache misses in a very hot kernel codepath,
there's likely to be additional application performance improvement due to
reduced cache conflicts from kernel data structures.
On a Power11 system with 128-byte cache lines, my test showed a ~5%
decrease in relevant scheduler cycles, along with a slight increase in user
time - both positive indicators. This data comes from
https://lore.kernel.org/lkml/affdc6b1-9980-44d1-89db-d90730c1e384@linux.ibm.com/
This is the case even though the additional "____cacheline_aligned" that
puts the runqueue lock on the next cache line adds an additional 64 bytes
of padding on those machines. This patch does not change the size of
"struct rq" on machines with 64-byte cache lines.
I also ran "hackbench" to try to test this change, but it didn't show
conclusive results. Looking at a CPU cycle profile of the hackbench run,
it was spending 95% of its cycles inside __alloc_skb(), __kfree_skb(), or
kmem_cache_free() - almost all of which was spent updating memcg counters
or contending on the list_lock in kmem_cache_node. And it spent less than
0.5% of its cycles inside either schedule() or try_to_wake_up(). So it's
not surprising that it didn't show useful results here.
The "__no_randomize_layout" was added to reflect the fact that performance
of code that references this data structure is unusually sensitive to
placement of its members.
Signed-off-by: Blake Jones <blakejones@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Reviewed-by: Josh Don <joshdon@google.com>
Tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Link: https://patch.msgid.link/20251202023743.1524247-1-blakejones@google.com
|
|
In the group_has_spare case, the function creates a temporary cpumask
to just calculate weight of (p->cpus_ptr & sched_group_span(local)).
We've got a dedicated helper for it.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Reviewed-by: Fernand Sieber <sieberf@amazon.com>
Link: https://patch.msgid.link/20251207034247.402926-1-yury.norov@gmail.com
|
|
Use for_each_cpu_and() and drop some housekeeping code.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Reviewed-by: Phil Auld <pauld@redhat.com>
Link: https://patch.msgid.link/20251207033037.399608-1-yury.norov@gmail.com
|
|
cpumask_empty() call is O(N) and useless because the previous
cpumask_and() returns false for empty 'cpus'. Drop it.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://patch.msgid.link/20251207040543.407695-1-yury.norov@gmail.com
|
|
When the EFI stub itself loads the initrd and puts it in memory (rather
than simply passing on a struct boot_params or device tree that already
carries initrd information), it exposes this information to the core
kernel via a INITRD configuration table.
Given that config tables are preserved across kexec, this means that
subsequent kexec boots will observe the same information, even though it
most likely has become stale by that point. On x86, this information is
usually superseded by the initrd info passed via bootparams, in which
case this stale information is simply ignored. However, when performing
a kexec boot without passing an initrd, the loader falls back to this
stale information and explodes.
So wipe the base and size from the INITRD config table as soon as it has
been consumed. This fixes the issue for kexec on all EFI architectures.
Reported-by: James Le Cuirot <chewi@gentoo.org>
Tested-by: James Le Cuirot <chewi@gentoo.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Link: https://lore.kernel.org/all/20251126173209.374755-2-chewi@gentoo.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
In order to correctly handle the interaction between the reset-gpio
devices and shared GPIOs managed by GPIOLIB, we need to be able to
identify the former. Add the "compatible" property to allow us to use
the device_is_compatible() helper.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Enable the PCIe controller and USB3 XHCI host on the OpenWrt One
board. The USB controller is configured for USB 2.0 only mode, as the
shared USB3/PCIe PHY is dedicated to PCIe functionality on this board.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Add device tree nodes for PCIe controller and USB3 XHCI host
controller on MT7981B SoC. Both controllers share the USB3 PHY
which can be configured for either USB3 or PCIe operation.
The USB3 XHCI controller supports USB 2.0 and USB 3.0 SuperSpeed
operation. The PCIe controller is compatible with PCIe Gen2
specifications.
Also add the topmisc syscon node required for USB/PCIe PHY
multiplexing.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The endpoint IDs in the display graph are expected to match the
associated display path number, i.e. all endpoints connected to
mmsys_ep_main must have reg = <0> and all endpoints connected to
mmsys_ep_ext must have reg = <1>.
Add the missing ID to all endpoints in the display graph, based on
mt8365.dtsi as an existing example that does this correctly.
Fixes: e72d63fa0563 ("arm64: dts: mediatek: mt8183: Migrate to display controller OF graph")
Reported-by: Evans Jahja <evansjahja13@gmail.com>
Closes: https://lore.kernel.org/linux-mediatek/CAAq5pW9o3itC0G16LnJO7KMAQ_XoqXUpB=cuJ_7e3-H11zKd5Q@mail.gmail.com/
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
[Angelo: Fixed dtbs_check issues]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
I've acquired a Logitech MX Anywhere 3S mouse, which supports HID++ over
Bluetooth. Adding its PID 0xb037 to the allowlist enables the additional
features, such as high-resolution scrolling. Tested working across multiple
machines, with a mix of Intel and Mediatek Bluetooth chips.
[jkosina@suse.com: standardize shortlog]
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
On Asus ROG laptops, the Fn+F5 key (HID code 0xae) is used to cycle
through fan modes. This key press needs to be forwarded to the asus-wmi
driver to actually change the fan mode.
Add ASUS_FAN_CTRL_KEY_CODE define and implement the handler in
asus_raw_event() to send WMI events when this key is pressed.
When asus-wmi successfully handles the event, it is blocked from reaching
userspace. If asus-wmi is unavailable or fails, the event is passed to
userspace via evdev, allowing userspace implementations of fan control.
Tested on Asus ROG G14/G15 series laptops.
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Add infrastructure for the HID driver to communicate with the asus-wmi
driver for handling special keys that require WMI communication.
This includes:
- Define ASUS_WMI_METHODID_NOTIF method ID in asus-wmi.h
- Implement asus_wmi_send_event() function to send events to asus-wmi
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
On Asus ROG laptops, several HID vendor usage codes (0xea, 0xec, 0x02,
0x8a, 0x9e) are sent during normal operation without a clear purpose,
generating unwanted "Unmapped Asus vendor usagepage code" warnings in
dmesg.
Add definitions for these codes and filter them out in asus_raw_event()
to prevent kernel log spam.
Tested on Asus ROG series laptops.
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Use the existing HID_UP_ASUSVENDOR constant instead of the magic number
0xff310000 for better code clarity and maintainability.
Reviewed-by: Denis Benato <benato.denis96@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Ionut Nechita <ionut_n2001@yahoo.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
This driver provides backlight brightness control through the Linux
backlight subsystem. It communicates with the board controller to
adjust LCD backlight using PWM signals. Communication is done
through Congatec Board Controller core driver.
Tested-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Signed-off-by: Petri Karhula <petri.karhula@novatron.fi>
Link: https://patch.msgid.link/20251205-cgbc-backlight-v6-1-e4175b0bf406@novatron.fi
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The LP5860 is a LED matrix driver with 18 constant current sinks and 11
scan switches for 198 LED dots:
* Supply range from 2.7 V to 5.5 V
* 0.1mA - 50mA per current sink
* 1MHz I2C and 12MHz SPI control interface
* 8-bit analog dimming
* 8/16-bit PWM dimming
* individual ON and OFF control for each LED dot
* globat 3-bit Maximum Current setting for all LED dots
* individual LED dot open/short detection
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251201-v6-14-topic-ti-lp5860-v6-1-be9a21218157@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Starting from NPU6, the driver can pass boot parameters address through
the AON retention register and toggle between cold/warm boot types using
the boot_type parameter, while setting the cold boot entry point in both
cases.
Refactor the existing cold/warm boot handling to be consistent with the
new NPU6 boot flow requirements and still maintain compatibility with
older boot flows.
This will allow firmware to remove support for legacy warm boot starting
from NPU6.
Fixes: 550f4dd2cedd ("accel/ivpu: Add support for Nova Lake's NPU")
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Link: https://patch.msgid.link/20251230142116.540026-1-maciej.falkowski@linux.intel.com
|
|
Building with W=1 reports several kernel-doc warnings in
drivers/leds/leds-lm3692x.c:
Warning: leds-lm3692x.c:122 struct member 'boost_ctrl'
not described in 'lm3692x_led'
Warning: leds-lm3692x.c:122 struct member 'brightness_ctrl'
not described in 'lm3692x_led'
Warning: leds-lm3692x.c:122 struct member 'enabled'
not described in 'lm3692x_led'
These fields were added to struct lm3692x_led but the corresponding
kernel-doc comment was not updated. Convert the kernel-doc block to
use the "@member: description" style consistently and document the
boost_ctrl, brightness_ctrl and enabled fields.
This keeps the documentation in sync with the implementation and
silences the W=1 warnings.
Signed-off-by: Vivek BalachandharTN <vivek.balachandhar@gmail.com>
Link: https://patch.msgid.link/20251201042612.2099239-1-vivek.balachandhar@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix kernel-doc warnings on struct intel_lb_component_ops:
Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of
kernel-doc format: * push_payload - Sends a payload to the
authentication firmware
And a bunch more. There isn't really support for documenting function
pointer struct members in kernel-doc, but at least reference the member
properly.
Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver")
Cc: Alexander Usyskin <alexander.usyskin@intel.com>
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
airoha_ppe_deinit() runs airoha_npu_ppe_deinit() in atomic context.
airoha_npu_ppe_deinit routine allocates ppe_data buffer with GFP_KERNEL
flag. Rely on rcu_replace_pointer in airoha_ppe_deinit routine in order
to fix schedule while atomic issue in airoha_npu_ppe_deinit() since we
do not need atomic context there.
Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260105-airoha-fw-ethtool-v2-1-3b32b158cc31@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Ingo reported PREEMPT_RT=y builds fail building
lib/test_context-analysis.c.
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
|
|
The robot reported CONFIG_MODVERSION fails; which Nathan described as
so:
> Something about the context analysis makes genksyms fall over, running
> it manually on kernel/sched/core.i with '-w' to show warnings reveals
> many new "syntax error" instances. I don't see any warnings when using
> gendwarfksyms. Maybe it is context_lock_struct, as that is the first
> error I see in the list:
>
> include/linux/spinlock_types_raw.h:14: syntax error
Reported-by: kernel test robot <lkp@intel.com>
Debugged-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/oe-kbuild-all/202512222219.F6EkVNmQ-lkp@intel.com/
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/aV7fxXjaOBtHhI9X@elver.google.com
|
|
There are multiple design tradeoffs and considerations in how the
PCA953x driver detects the source(s) of an interrupt. This driver
supports PCAL variants with input latching, a feature that is
constrained by the fact that the interrupt status and input port
registers cannot be read atomically. These limits and the design
decisions deserve an in-depth explanation.
Update the documentation to clarify these hardware limits and describe
how the driver determines pending interrupts, and how it makes use of
the PCAL input latching.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20260107093125.4053468-1-ernestvanhoecke@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The at25,* properties have been deprecated since 2012. These platforms
weren't upstream until 2020 and 2023, so it should be safe to switch
over to the "new" properties and just drop the deprecated ones.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The code, as it is, plays fast and loose with bandwidth units. It also
doesn't specify its constraints in the actual maximum hardware value,
but as some roundabout thing that then ends up multiplied into the
actual hardware value constraint after some indirections. In part, this
is due to the use of individual members for storing each limit, instead
of making it possible to index them by type.
Rework all of this by adding const array members indexed by the
bandwidth type enum to the soc_data struct. This array expresses the
actual hardware value limitations, not a factor thereof.
Use the clamp function macro to clamp the values between the minimum and
maximum constraints after all the calculations, which also means the
code doesn't write nonsense to a hardware register when the math is
wrong, as it'll constrain after all the calculations.
Pass the type as the actual enum type as well, and not as an int. If
there's some type checking that can be extracted from the function
signature, then we may as well use it.
Don't needlessly explicitly cast return values to the return type
either; this is both unnecessary and makes it harder to spot type safety
issues.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The DVFSRC has a clock on all platforms.
Get and enable it in the probe function, so that Linux's common clock
framework knows we're a user of it.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Add support for the DVFSRC Version 4 by adding new functions for
vcore/dram levels (in v4, called gears instead), and for readout
of pre-programmed dvfsrc_opp entries, corresponding to each gear.
In the probe function, for v4, the curr_opps is initialized from
the get_hw_opps() function instead of platform data.
In order to make use of the new DVFSRCv4 code, also add support
for the MediaTek MT8196 SoC.
Co-developed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for adding support for DVFSRC Version 4, add a new
`has_emi_ddr` member to struct dvfsrc_soc_data: if true, write the
DRAM bandwidth both to the BW_AVG and to the newly defined EMI_BW
register, present only on DVFSRC v4.
Currently supported SoCs will not use this, as has_emi_ddr is left
out from their platform data, hence reading false.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for adding support for DVFSRC Version 4, add a new
callback for calculating the dram bandwidth, assign the current
calculation algo to all of the currently supported SoCs, and use
this in __dvfsrc_set_dram_bw_v1().
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for adding support for DVFSRC Version 4, add a new
mtk_dvfsrc_bw_type enumeration, and propagate it from specific bw
setting callbacks to __dvfsrc_set_dram_bw_v1(), which will use it
to choose calculation multipliers and dividers in v4 callbacks.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for adding support for DVFSRC Version 4, change the
error check for the MTK_SIP_DVFSRC_START command in the probe
function to error out only if BIT(0) is set: this is still valid
for the previous DVFSRC versions, as those always set this bit in
a fail reply anyway.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The DVFSRC hardware has a clock on all platforms.
Instead or proliferating the culture of omitting clock descriptions in
the clock controller drivers or marking them critical instead of
declaring these types of relationships, add this one to the binding.
Any device that wishes to use this binding should figure out their
incomplete or incorrect clock situation first before piling more
features on top.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Add an entry for the MT8371 SoC with commercial name Genio 520.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In svs_enable_debug_write(), the buf allocated by memdup_user_nul()
is leaked if kstrtoint() fails.
Fix this by using __free(kfree) to automatically free buf, eliminating
the need for explicit kfree() calls and preventing leaks.
Fixes: 13f1bbcfb582 ("soc: mediatek: SVS: add debug commands")
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
[Angelo: Added missing cleanup.h inclusion]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Move the "interrupt-parent = <&plic>" property from the soc node to the
top node, for consistency with
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/97d3d70e42832f4ffa3888bec792b692a7ab700f.1767719409.git.geert+renesas@glider.be
|
|
Add PCLKCAN ID for CANFD to both R9A09G077 and R9A09G087 SoCs.
This definition is required for describing CANFD device in DT.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224165049.3384870-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Private state is available in all places where cpg_rzt2h_mstp_read() is
called, remove the extra pointer math used to find it from clk_hw.
While at it, put these statements on a single line as they do not exceed
the 80 columns limit.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251127145654.3253992-2-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
"version" is an enum, thus cast of pointer on 64-bit compile test with
clang W=1 causes:
ahci_xgene.c:776:13: error: cast to smaller integer type 'enum xgene_ahci_version' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
"imxpriv->type" is an enum, thus cast of pointer on 64-bit compile test
with clang W=1 causes:
ahci_imx.c:872:18: error: cast to smaller integer type 'enum ahci_imx_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
Use scoped for-each loop when iterating over device nodes and switch to
iterating already over available nodes to make code a bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
The "select" schema is not necessary. It looks like it is there to prevent
matching on "generic-ahci" compatible, but that's not necessary because
this is the only place "generic-ahci" compatible is present.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
clear_page() translates into memset(*p, 0, PAGE_SIZE) on some
architectures, but on the major architectures it will call
an optimized assembly snippet so use this instead of open
coding a memset().
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20251130-dma-buf-heap-clear-page-v1-1-a8dcea2a88ee@linaro.org
|
|
Add nodes for usart, spi and i2c when missing to the
flexcom nodes.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20260102170135.70717-6-nicolas.ferre@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
|
When missing, add the atmel,fifo-size = <32> property for usart nodes in
flexcom.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20260102170135.70717-5-nicolas.ferre@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
|
Add the dma property and associated dma activation for usart6 as part of
flx6 node.
Is useful for usual default console on this product.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20260102170135.70717-4-nicolas.ferre@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
