Rockchip RK3576 EVB1 has an onboard PCIe slot (PCIe 2.1, x4 mechanically,
x1 electrically), but it shares pins and PHY with the only USB3 Type-A
port.
There is a physical switch next to the slot to transfer respective pins
connection from the USB3 port to the PCIe slot, but apart from flipping
the switch one must also disable the USB3 host controller to prevent it
from claiming the PHY before the PCIe slot can become usable.
Add an overlay to disable the USB3 host port and instead enable the
PCIe slot, along with its pin configs. The physical switch must still be
flipped to the "ON - PCIe1" position for this to work.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20251202-evb1-pcie1-v2-1-810693b1b72f@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
RK3288 contains a Rockchip VDEC block that only support HEVC
decoding. Add a vdec node for this.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patch.msgid.link/20250905161942.3759717-8-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Till now, the runtime PM workqueue has been flagged as freezable, so it
does not process work items during system-wide PM transitions like
system suspend and resume. The original reason to do that was to
reduce the likelihood of runtime PM getting in the way of system-wide
PM processing, but now it is mostly an optimization because (1) runtime
suspend of devices is prevented by bumping up their runtime PM usage
counters in device_prepare() and (2) device drivers are expected to
disable runtime PM for the devices handled by them before they embark
on system-wide PM activities that may change the state of the hardware
or otherwise interfere with runtime PM. However, it prevents
asynchronous runtime resume of devices from working during system-wide
PM transitions, which is confusing because synchronous runtime resume
is not prevented at the same time, and it also sometimes turns out to
be problematic.
For example, it has been reported that blk_queue_enter() may deadlock
during a system suspend transition because of the pm_request_resume()
usage in it [1]. It may also deadlock during a system resume transition
in a similar way. That happens because the asynchronous runtime resume
of the given device is not processed due to the freezing of the runtime
PM workqueue. While it may be better to address this particular issue
in the block layer, the very presence of it means that similar problems
may be expected to occur elsewhere.
For this reason, remove the WQ_FREEZABLE flag from the runtime PM
workqueue and make device_suspend_late() use the generic variant of
pm_runtime_disable() that will carry out runtime PM of the device
synchronously if there is pending resume work for it.
Also update the comment before the pm_runtime_disable() call in
device_suspend_late(), to document the fact that the runtime PM
should not be expected to work for the device until the end of
device_resume_early(), and update the related documentation.
This change may, even though it is not expected to, uncover some
latent issues related to queuing up asynchronous runtime resume
work items during system suspend or hibernation. However, they
should be limited to the interference between runtime resume and
system-wide PM callbacks in the cases when device drivers start
to handle system-wide PM before disabling runtime PM as described
above.
Link: https://lore.kernel.org/linux-pm/20251126101636.205505-2-yang.yang@vivo.com/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/12794222.O9o76ZdvQC@rafael.j.wysocki
Enable use of common SDHCI-related properties such as sdhci-caps-mask as
found in the AST2600 EVB DTS.
Cc: stable@vger.kernel.org # v6.2+
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enable CLK_SET_RATE_PARENT for mux clocks so that rate changes can properly
propagate to their parent clocks. Several clocks in the R9A09G077 CPG tree
depend on upstream PLL or divider outputs being recalculated when a child
requests a new frequency. Without this flag, rate adjustments stop at the
mux layer, leaving parent rates unchanged and preventing the clock tree
from converging on the intended values.
Set the flag in DEF_MUX to ensure that parent clocks participate in rate
negotiation, which is required for correct operation of the display and
peripheral related clocks being added for RZ/T2H support.
Fixes: 065fe720ee ("clk: renesas: Add support for R9A09G077 SoC")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251121090853.5220-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add core clocks and module clock definitions required by the xSPI
(Expanded SPI) IP on the R9A09G077 SoC.
Define the new SCKCR fields FSELXSPI0/FSELXSPI1 and DIVSEL_XSPI0/1 and
add two new core clocks XSPI_CLK0 and XSPI_CLK1. The xSPI block uses
PCLKH as its bus clock (use as module clock parent) while the operation
clock (XSPI_CLKn) is derived from PLL4. To support this arrangement
provide mux/div selectors and divider tables for the supported
XSPI operating rates.
Add CLK_TYPE_RZT2H_FSELXSPI to implement a custom divider/mux clock
where the determine_rate() callback enforces the hardware constraint:
when the parent output is 600MHz only dividers 8 and 16 are valid,
whereas for 800MHz operation the full divider set (6,8,16,32,64) may
be used. The custom determine_rate() picks the best parent/divider pair
to match the requested rate and programs the appropriate SCKCR fields.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251117205627.39376-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Although CMN-Skeena is mildly modified for the Morello hardware
architecture, it still identifies itself as CMN-600 r3p1. Since
there are also no documented changes to its PMU functionality,
we can make the PMU accessible via the standard CMN-600 binding.
In general, PMU registers are non-functional on CMN Fast Models,
so this is only meaningful for the real SDP hardware.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Message-Id: <cbeb3832ded539c8c4616d49d3133078a34f88ad.1748350539.git.robin.murphy@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Uninitialized pointers with `__free` attribute can cause undefined
behaviour as the memory assigned(randomly) to the pointer is freed
automatically when the pointer goes out of scope
arm doesn't have any bugs related to this as of now, but
it is better to initialize and assign pointers with `__free` attr
in one statement to ensure proper scope-based cleanup
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/all/aPiG_F5EBQUjZqsl@stanley.mountain/
Signed-off-by: Ally Heev <allyheev@gmail.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Message-Id: <20251105-aheev-uninitialized-free-attr-arm-v1-1-f7b6cb5d3361@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The FF-A driver currently performs loose comparisons when checking the
supported FF-A feature, which can inadvertently treat future or
intermediate revisions as compatible.
Replace generic `version {>,<} FFA_VERSION_1_*` pattern checks with
feature-specific macros that clearly express which functionality
depends on FF-A versioning.
This improves readability and future maintainability by tying each
feature (e.g. GET_COUNT_ONLY, size/UUID/exec state in responses) to
explicit version requirements instead of relying on generic version
comparisons. This improves robustness and clarity as the FF-A
specification evolves.
No functional change, only improves code readability.
Message-Id: <20251016094111.946236-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the
partition setup failure path it never unmaps them.
Add the missing ffa_rxtx_unmap() call in the error path so that
the Rx/Tx buffers are properly released before freeing the backing
pages.
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Commit 9ac09bb9fe ("mm: consistently use current->mm in
mm_get_unmapped_area()") upstream dropped a parameter from
mm_get_unmapped_area() while commit 99bda20d6d ("drm/gem: Introduce
drm_gem_get_unmapped_area() fop") in drm-misc-next added a new user.
Drop the extra parameter from the call.
Fixes: 7f790dd21a ("Merge drm/drm-next into drm-misc-next")
Cc: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patch.msgid.link/20251215092706.3218018-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The XFRM_STATE_NOPMTUDISC flag is only meaningful for output SAs, but
it was being applied regardless of the SA direction when the sysctl
ip_no_pmtu_disc is enabled. This can unintentionally affect input SAs.
Limit setting XFRM_STATE_NOPMTUDISC to output SAs when the SA direction
is configured.
Closes: https://github.com/strongswan/strongswan/issues/2946
Fixes: a4a87fa4e9 ("xfrm: Add Direction to the SA in or out")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
The video clocks enci, encp, vdac and hdmitx share the same clock
source. Adding CLK_SET_RATE_PARENT to the mux may unintentionally change
the shared parent clock, which could affect other video clocks.
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20250919-add_video_clk-v6-3-fe223161fb3f@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add indices for video encoder, demodulator and CVBS clocks.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20250919-add_video_clk-v6-1-fe223161fb3f@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add DT bindings for the peripheral clock controller of the Amlogic T7
SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251212022619.3072132-4-jian.hu@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251212022619.3072132-3-jian.hu@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Currently it seems impossible to observe these changes to the file's
attributes. It's useful to be able to do this to see when the file
becomes immutable, for example, so emit IN_ATTRIB via fsnotify_xattr(),
like when changing other inode attributes.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Link: https://patch.msgid.link/iyvn6qjotpu6cei5jdtsoibfcp6l6rgvn47cwgaucgtucpfy2s@tarta.nabijaczleweli.xyz
Signed-off-by: Jan Kara <jack@suse.cz>
inotify/fanotify do not allow users with no read access to a file to
subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the
same user to subscribe for watching events on children when the user
has access to the parent directory (e.g. /dev).
Users with no read access to a file but with read access to its parent
directory can still stat the file and see if it was accessed/modified
via atime/mtime change.
The same is not true for special files (e.g. /dev/null). Users will not
generally observe atime/mtime changes when other users read/write to
special files, only when someone sets atime/mtime via utimensat().
Align fsnotify events with this stat behavior and do not generate
ACCESS/MODIFY events to parent watchers on read/write of special files.
The events are still generated to parent watchers on utimensat(). This
closes some side-channels that could be possibly used for information
exfiltration [1].
[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Reported-by: Sudheendra Raghav Neela <sneela@tugraz.at>
CC: stable@vger.kernel.org
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
When pdacf_config() fails, snd_pdacf_probe() returns the error code
directly without freeing the sound card resources allocated by
snd_card_new(), which leads to a memory leak.
Add proper error handling to free the sound card and clear the card
list entry when pdacf_config() fails.
Fixes: 15b99ac172 ("[PATCH] pcmcia: add return value to _config() functions")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251215090433.211-1-vulab@iscas.ac.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
TID getting from ieee80211_get_tid() might be out of range of array size
of sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise,
UBSAN warn:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30
index 10 is out of range for type 'rtl_tid_data [9]'
Fixes: 8ca4cdef93 ("wifi: rtlwifi: rtl8192cu: Fix TX aggregation")
Signed-off-by: Morning Star <alexbestoso@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1764232628-13625-1-git-send-email-pkshih@realtek.com
The indirect IO is necessary for RTL8822CS, but not necessary for other
chips. Otherwiese, it throws errors and becomes unusable.
rtw88_8723cs mmc1:0001:1: WOW Firmware version 11.0.0, H2C version 0
rtw88_8723cs mmc1:0001:1: Firmware version 11.0.0, H2C version 0
rtw88_8723cs mmc1:0001:1: sdio read32 failed (0xf0): -110
rtw88_8723cs mmc1:0001:1: sdio write8 failed (0x1c): -110
rtw88_8723cs mmc1:0001:1: sdio read32 failed (0xf0): -110
By vendor driver, only RTL8822CS and RTL8822ES need indirect IO, but
RTL8822ES isn't supported yet. Therefore, limit it to RTL8822CS only.
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/07a32e2d6c764eb1bd9415b5a921a652@realtek.com/T/#m997b4522f7209ba629561c776bfd1d13ab24c1d4
Fixes: 58de1f91e0 ("wifi: rtw88: sdio: use indirect IO for device registers before power-on")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Link: https://patch.msgid.link/1764034729-1251-1-git-send-email-pkshih@realtek.com
When vxpocket_config() fails, vxpocket_probe() returns the error code
directly without freeing the sound card resources allocated by
snd_card_new(), which leads to a memory leak.
Add proper error handling to free the sound card and clear the
allocation bit when vxpocket_config() fails.
Fixes: 15b99ac172 ("[PATCH] pcmcia: add return value to _config() functions")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251215042652.695-1-vulab@iscas.ac.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CONFIG_OMAP_USB2 is already enabled as a module in the default defconfig
since commit 8a703a728a ("arm64: defconfig: Enable USB2 PHY Driver").
Remove the duplicate entry to fix the following warning:
arch/arm64/configs/defconfig:1705:warning: override: reassigning to symbol OMAP_USB2
Fixes: 91fe3315cdf9f ("arm64: defconfig: Enable missing AMD/Xilinx drivers")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20251015150728.118296-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Over years number of upstream drivers have grown for AMD/Xilinx SOCs
(ZynqMP, Versal, Versal NET) but they are not enabled by default in
defconfig that's why enable all drivers for these SOCs including USB5744
on board USB hub available on Kria ZynqMP based SOMs and Carrier Cards.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/457c3a128e300241afd20da693d1d80a35d1ece6.1758099050.git.michal.simek@amd.com
Since the following commit, the zynqmp clk driver uses the common
divider_round_rate() when determining the appropriate clock divider for a
requested clock frequency:
1fe15be1fb
This means that all the calculations will be in kHz when determining the
appropriate clock divider for a given cpufreq request. The problem with this
is that the zynqmp.dtsi and zynqmp-clk-ccf.dtsi files have frequency
definitions in Hz, so when dividing requested values in kHz, errors can occur
with the rounding.
For example, the current pss_ref_clk frequency is 33333333 Hz which generates
a cpufreq parent clock frequency of 1199999988 Hz which is the same as the
highest opp-table-cpu frequency in the zynqmp.dtsi.
But if a user requests the value 1199999 kHz as recommended in the available
frequencies:
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
299999 399999 599999 1199999
root@zynqmp:/ # echo 1199999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
The calculation will be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
Also, if a user tries to work around this calculation by using any larger
values, it still will not fix the problem because the driver will use the
largest opp in kHz which leads to the same calculation error.
User requests 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
Driver converts any value greater than 1199999 to the largest opp which is
1199999 and then calculates the divider value with the same calculation.
The calculation will still be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
This means there is no way to configure the zynqmp for the fastest opp using
the current dtsi files.
To fix this issue, this patch updates the zynqmp opp-table-cpu and
pss_ref_clk, so the clock rates are calculated correctly.
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
300000 400000 600000 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
1200000
Signed-off-by: Neal Frager <neal.frager@amd.com>
Acked-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251111070555.1169130-1-neal.frager@amd.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
system_dfl_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251104103942.96647-1-marco.crivellari@suse.com
AMD/Xilinx Versal Window Watchdog Timer has its own power domain, so add
an optional property to describe it.
Signed-off-by: Harini T <harini.t@amd.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20250130120233.742879-1-harini.t@amd.com
Unlike zynq, which has a specific compatible for the Cadence spi
controller, zynqmp and versal-net do not have specific compatibles.
In order to "encourage" people to use soc-specific compatibles for new
devices using this IP, add specific compatibles for these devices, with
a fallback to the existing compatible for the r1p6 version of the IP so
that there will be no functional change.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251001-cheesy-shucking-c55431bbcae3@spud
Signed-off-by: Michal Simek <michal.simek@amd.com>
We have currently used up 30 out of the 32-bits in the struct ata_device
struct member quirks. Thus, it is only possible to add two more quirks.
Change the struct ata_device struct member quirks from an unsigned int to
an u64.
Doing this core level change now, will make it easier for us now, as we
will not need to also do core level changes once the final two bits are
used as well.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Add a new libata.force parameter called max_sec.
The parameter can take an arbitrary value using the format:
libata.force=max_sec=<number of 512B sectors>
e.g. libata.force=max_sec=8191
or
libata.force=max_sec=2048
This will allow the user to set an arbitrary maximum command size
(dev->max_sectors) using libata.force.
We cannot remove the existing libata.force parameters "max_sec_128" and
"max_sec_1024", as these are a part of the exising user facing API.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
