Remove redundant NULL initialization for list iterator because
variables used as iterators in list_for_each_entry() do not require
initialization, as the macro assigns them before first use.
No functional change.
Signed-off-by: Shyam Sunder Reddy Padira <shyamsunderreddypadira@gmail.com>
Link: https://patch.msgid.link/20260505192320.107936-1-shyamsunderreddypadira@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The SB IOAPIC is on the device 0xb from Hygon family 18h model 4h.
Signed-off-by: Fu Hao <fuhao@open-hieco.net>
Tested-by: Tingyin Duan <tingyin.duan@gmail.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Under heavy concurrent attach/detach operations, scx_claim_exit() can
trigger a NULL pointer dereference. This can be reproduced running the
reload_loop kselftests inside a virtme-ng session:
$ vng -v -- ./tools/testing/selftests/sched_ext/runner -t reload_loop
...
BUG: kernel NULL pointer dereference, address: 0000000000000400
RIP: 0010:scx_claim_exit+0x3b/0x120
Call Trace:
<TASK>
bpf_scx_unreg+0x45/0xb0
bpf_struct_ops_map_link_dealloc+0x39/0x50
bpf_link_release+0x18/0x20
__fput+0x10b/0x2e0
__x64_sys_close+0x47/0xa0
The underlying race (diagnosed by Tejun Heo) is a stomp of @ops->priv,
not a missing NULL check:
T2 unreg(K) T1 reg(K)
----------- ---------
sch = ops->priv = sch_b800
scx_disable; flush_disable_work
[scx_root_disable: scx_root=NULL,
mutex_unlock, state=DISABLED]
mutex_lock; state ok
scx_alloc_and_add_sched:
ops->priv = sch_a800
scx_root = sch_a800; init=0
state=ENABLED; mutex_unlock
[flush returns]
RCU_INIT_POINTER(ops->priv, NULL) <-- clobbers sch_a800
kobject_put(sch_b800)
T1 acquires scx_enable_mutex inside scx_root_disable()'s mutex_unlock
window and starts a fresh attach on the same kdata, assigning sch_a800
to @ops->priv. T2 then continues out of scx_disable()/flush_disable_work
and clobbers @ops->priv to NULL, leaking sch_a800; the bpf_link is gone
but state stays SCX_ENABLED, so all future attaches fail with -EBUSY
permanently. The next bpf_scx_unreg() on that kdata then reads NULL
@ops->priv and dereferences it in scx_claim_exit().
Make @ops->priv the lifecycle binding: in scx_root_enable_workfn() and
scx_sub_enable_workfn(), after the existing state check and still under
scx_enable_mutex, refuse with -EBUSY if @ops->priv is non-NULL. This
rejects an attempt to reuse a kdata that is still bound to a previous
scheduler instance, closing the race without changing the unreg side.
Fixes: 105dcd005b ("sched_ext: Introduce scx_prog_sched()")
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Exclusion ranges in IVMD are treated as unity mappings with r&w
permissions since commit 0bbe4ced53 ("iommu/amd: Fix the
overwritten field in IVMD header"), using 1:1 mappings. And IOMMU
Exclusion Base & Range Limit Registers (0x0020/0x0028) are actually
no longer used.
As a result, several definitions and code paths became dead code:
- exclusion_start/exclusion_length in struct amd_iommu are never
assigned,
- iommu_set_exclusion_range() always returns 0 now.
- MMIO_EXCL_ENABLE_MASK & MMIO_EXCL_ALLOW_MASK are only used by
the removed iommu_set_exclusion_range().
- DEV_ENTRY_EX is no longer set in any DTE.
- IOMMU_UNITY_MAP_FLAG_EXCL_RANGE is no longer set, thus the
IOMMU_RESV_RESERVED branch in amd_iommu_get_resv_regions() is
no longer reachable.
Just remove all of the dead code. No functional change.
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Reviewed-by: Jacob Pan <jacob.pan@linux.microsoft.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The termios definitions are provided by the termios.h header file which
is included by tty.h so drop the redundant asm/termbits.h include
directive.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Add the missing atomic.h include to the two driver that use it but did
not include it directly.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
This driver no longer uses anything from atomic.h so drop the unused
include directive.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
These drivers (and usb-serial.c) no longer use anything from
moduleparam.h so drop the unnecessary include directives.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
These drivers (and usb-serial.c) no longer use anything from uaccess.h
directly so drop the unnecessary include directives.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Add the missing uaccess.h include, which is needed since TIOCSRS485
support was added, instead of relying on the header being included
indirectly.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
These drivers (and usb-serial.c) no longer use anything from tty_flip.h
directly so drop the unnecessary include directives.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
USB serial drivers do not use anything from tty_driver.h directly (only
core does) so drop the unnecessary include directives.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Update a stale comment about which of the legacy modes is visible to the
user, i.e. can be forced via amd_iommu_intr=legacy.
Fixes: b74aa02d7a ("iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Wei Wang <wei.w.wang@hotmail.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Bail early from enable_iommus_vapic() if IOMMUs are configured for either
of the legacy modes, as it's absurdly difficult to see that
iommu_ga_log_enable() is guaranteed to fail because iommu_init_ga_log()
skips allocating the ga_log.
Opportunistically have iommu_ga_log_enable() WARN if it's called without
IOMMUs being configured to support AVIC/vAPIC.
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Prefer to use === instead of --- for top level section heading
underlines to allow using the latter for sub-headings later.
While at it, fix the underline lenghts where needed.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/f49968792220ca3ff24efde813550850340d092e.1778235406.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Nowadays, the display support for drm/i915 and drm/xe is shared between
the drivers, even though the code is located under drm/i915/display.
The drm/i915 documentation has everything, including display topics, in
one huge page, while the drm/xe documentation is well-organized but
hardly mentions display. It's not great, to put it mildly.
Split out the Intel display documentation to a dedicated directory,
Documentation/gpu/intel-display. Also directly split the
functionality/feature documentation to dedicated pages to keep the main
index page high level and readable. We'll want to organize this further,
but just sort them alphabetically for starters.
Drop the boilerplate documentation sections that don't actually document
anything.
Cross-reference drm/i915, drm/xe, and intel-display.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/21bfa7777eb0926eadd309d4c6f5c9cf48405cf0.1778235406.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In preparation for adding support for 3, 5, 6 and 7 port devices, replace
the current one-bit-per-type encoding of the number of ports with a more
compact four bit encoding (2..16 ports or undefined).
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Now that all panel drivers use devm_drm_panel_alloc(),
there are no external callers of drm_panel_init().
Make it static to prevent new users from bypassing the
refcounted allocation path.
Remove stale references to drm_panel_init() in kdocs.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-10-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-9-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-8-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-7-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-6-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-5-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-4-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-3-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-2-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety. Also deduplicate the prepare_prev_first
assignment that was set both before and after drm_panel_init().
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-1-0bd4ac429971@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Fix the error path during DDI encoder/connector initialization by
calling the missing TC port cleanup function.
This fixes the leaked TC port state.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260507065940.2046690-1-imre.deak@intel.com
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmoA87keHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGsnAIAJENovWOPJnq6XOM
GcnwSFG+xsv5kfSXU9+ZgP2WnoHJGoWCon2T69+dyVrthmMxFcPub1UM+VI0M+LP
Eo894JhbAlpej4Z0f6I4L6eE9RMq2vc3UW3ga1WK6R9IYJ3WE1kEur64zJJoBvX1
SPj4oxpI/S02KxLT8F2Sq5PVS4lvaDwK/N2mTB5JNjZE24iUMYc/4nPFNFpVKhgb
qfpMOk4VGjfgRexVksskm8pVO6FAWXUMQTGUUYSpzv5f2avGAyP8o+m3dHIs366+
Y/xVLADTtW7z4pu3eTw5hZLhbTekElFfLTsSPqWwqCiu0zA5s3HjRHMo3xbhHkwT
0zXS2H0=
=j7EH
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rc3' into staging-next
We need the staging fixes in here to build off of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmoA87keHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGsnAIAJENovWOPJnq6XOM
GcnwSFG+xsv5kfSXU9+ZgP2WnoHJGoWCon2T69+dyVrthmMxFcPub1UM+VI0M+LP
Eo894JhbAlpej4Z0f6I4L6eE9RMq2vc3UW3ga1WK6R9IYJ3WE1kEur64zJJoBvX1
SPj4oxpI/S02KxLT8F2Sq5PVS4lvaDwK/N2mTB5JNjZE24iUMYc/4nPFNFpVKhgb
qfpMOk4VGjfgRexVksskm8pVO6FAWXUMQTGUUYSpzv5f2avGAyP8o+m3dHIs366+
Y/xVLADTtW7z4pu3eTw5hZLhbTekElFfLTsSPqWwqCiu0zA5s3HjRHMo3xbhHkwT
0zXS2H0=
=j7EH
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rc3' into usb-next
We need the USB fixes in here as well to test and work off of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reboot hangs on T113s boards because no restart handler is
available.
Enable the SoC watchdog whose driver registers a restart handler.
Tested on LCPI-PC-T113/F113.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
Link: https://patch.msgid.link/20260506-t113-mangopi-reboot-hang-v3-1-fa15a360a520@mmpsystems.pl
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Describe high speed timer block on Allwinner H616.
Tested on Orange Pi Zero 3:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260506-h616-t113s-hstimer-v4-4-591d425863d6@mmpsystems.pl
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Describe high speed timer block on Allwinner D1S-T113.
Tested on LCPI-PC-T113/F113:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260506-h616-t113s-hstimer-v4-3-591d425863d6@mmpsystems.pl
[wens@kernel.org: change subject prefix from "arm" to "riscv"]
[wens@kernel.org: fix interrupt representation]
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
At the moment, in intel_dp_compute_config(), intel_panel_fixed_mode() is
called to check if the panel has any fixed mode or not. If it is an eDP
and has the fixed mode, then intel_panel_compute_config() is called.
However, the intel_panel_compute_config already checks if the panel
supports a fixed mode and returns early if it doesn't. This makes the
earlier check in the caller redundant.
Remove this extra check for intel_panel_fixed_mode().
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-6-ankit.k.nautiyal@intel.com
Currently, in intel_sdvo_compute_config(), intel_panel_fixed_mode() is
called to get the fixed mode. However, since the call is made after
intel_panel_compute_config, that copies the selected fixed mode to the
adjusted mode, we can directly use the crtc_state->hw.adjusted_mode.
So remove the extra call to intel_panel_fixed_mode() and use adjusted
mode instead.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-5-ankit.k.nautiyal@intel.com
The function intel_dvo_compute_config() calls intel_panel_fixed_mode() only
to check if there is a valid fixed_mode and based on that it then calls
intel_panel_compute_config().
However, since the intel_panel_compute_config() already checks for
fixed_mode and we can drop the call to intel_panel_fixed_mode().
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-4-ankit.k.nautiyal@intel.com
Currently, most callers of intel_panel_mode_valid() also call
intel_panel_fixed_mode(). This is done either to check for the presence of
a fixed mode for the connector or to get the clock of the fixed mode, which
is then compared against the max dotclock for the pipe.
Since intel_panel_mode_valid() already calls intel_panel_fixed_mode()
internally, we can avoid yet another call to intel_panel_fixed_mode() from
the caller.
Remove the redundant call to intel_panel_fixed_mode() in mode_valid paths.
To get the clock for the fixed mode, extend the helper
intel_panel_mode_valid() to accept 'target_clock' as an out param.
The 'target_clock' can then be used by the callers to check against the
max dotclock.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-3-ankit.k.nautiyal@intel.com
For LVDS SDVO, mode validation checks the requested mode against the
pipe max dotclock, but does not validate the selected fixed mode clock.
After intel_panel_mode_valid(), get the fixed mode and validate its
clock against the max dotclock.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-2-ankit.k.nautiyal@intel.com
intel_hdcp_required_content_stream() walks every connector on the
digital port to populate hdcp_port_data->streams[]. The only filter is
connector_status_disconnected, which reflects physical presence on the
MST topology, not whether the connector currently drives a stream.
On a multi-sink MST setup where only a subset of sinks are modeset,
the loop can pick a sibling MST connector that is connected but has
no active CRTC / VC payload. intel_conn_to_vcpi() then logs "MST
Payload not present" and returns 0, and the bogus StreamID=0 is
written to the repeater in RepeaterAuth_Stream_Manage (DPCD 0x693F0).
Authentication completes, but the repeater shortly raises
LINK_INTEGRITY_FAILURE (RxStatus 0x69493 bit4) because the StreamID
does not match any stream on its input. The HDCP check work then
tears the link down, the Content Protection property drops back to
DESIRED, and userspace observes a spurious HDCP enable failure.
Filter the connector iteration to only those with a CRTC assigned in
the new atomic state, so intel_conn_to_vcpi() is called for the
connector actually being enabled and reads its real VCPI from the MST
topology state.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260505094022.4064256-1-suraj.kandpal@intel.com
Add PSCI-based CPU idle state definitions for the Sky1 SoC,
enabling core and cluster level power management through
ARM PSCI firmware.
Three idle states are defined:
- CPU_SLEEP_0: Core idle state for A520 cores
(psci-suspend-param 0x0010000), entry-latency 34us,
exit-latency 100us
- CPU_SLEEP_1: Core idle state for A720 cores
(psci-suspend-param 0x10000), entry-latency 31us,
exit-latency 79us
- CLUSTER_SLEEP_0: Cluster idle state shared by all cores
(psci-suspend-param 0x1010000), entry-latency 41us,
exit-latency 104us
A520 cores (cpu0-3) reference CPU_SLEEP_0 and CLUSTER_SLEEP_0,
while A720 cores (cpu4-11) reference CPU_SLEEP_1 and
CLUSTER_SLEEP_0.
Signed-off-by: Devin Li <Devin.Li@cixtech.com>
Link: https://lore.kernel.org/r/20260507065956.3900087-1-Devin.Li@cixtech.com
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
Add SCMI Protocol 13 (Performance) node under ap_to_pm_scmi with
domains.
Define SKY1_PERF_* macros in sky1-power.h for all performance domain
IDs (CPU L/B0/B1/M0/M1, GPU, DSU, NPU, VPU, CI700, NI700), and
wire each CPU node to its corresponding performance domain using
power-domains and power-domain-names properties.
Signed-off-by: Devin Li <Devin.Li@cixtech.com>
Link: https://lore.kernel.org/r/20260506025254.3602623-1-Devin.Li@cixtech.com
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
The ifdeffery is unnecessary, as the compiler can already optimize away
all of the mfd-specific code based on the IS_ENABLED() in
keyboard_led_is_mfd_device().
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260404-cros_kbd_led-cleanup-v1-3-0dc1100d54e3@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Make the code simpler to read by passing the 'struct keyboard_led' as
a parameter to the 'init' callbacks instead of relying on the platform
device driver data.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260404-cros_kbd_led-cleanup-v1-2-0dc1100d54e3@weissschuh.net
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
A race condition exists between the probe of cros-ec-sysfs and
cros-ec-sensorhub.
The `kb_wake_angle` attribute should only be visible if the sensor hub
detects two or more accelerometers. If cros_ec_sysfs_probe() runs
before cros_ec_sensorhub_register() completes sensor enumeration, the
sysfs attributes are created while `has_kb_wake_angle` is still false,
hiding `kb_wake_angle` incorrectly.
Store the created attribute group pointer in `ec_dev->group`. When
the sensor hub completes sensor enumeration, it checks for this group
and calls sysfs_update_group() to notify the sysfs core to re-evaluate
attribute visibility. This ensures the `kb_wake_angle` attribute
visibility is correctly updated regardless of the driver probe order.
Co-developed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Link: https://lore.kernel.org/r/20260407102615.1605317-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Building the dequeue selftest with newer compilers (e.g., gcc 16)
triggers the following error:
dequeue.c:28:22: error: variable 'sum' set but not used
The 'volatile' qualifier prevents the writes from being optimized away,
but does not silence the unused variable 'sum' is indeed only written
and never read.
Consume 'sum' via an empty asm() with a register input constraint. This
forces the compiler to keep the accumulated value (preserving the CPU
stress loop) and avoiding the build error.
Fixes: 658ad2259b ("selftests/sched_ext: Add test to validate ops.dequeue() semantics")
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
cg_read_strcmp() allocated a buffer sized to strlen(expected) + 1,
then passed it to read_text() which calls read(fd, buf, size-1).
When comparing against an empty string (""), strlen("") = 0 gives a
1-byte buffer, and read() is asked to read 0 bytes. The file content
is never actually read, so strcmp("", buf) always returns 0 regardless
of the real content. This caused cg_test_proc_killed() to always
report the cgroup as empty immediately, making OOM tests pass without
verifying that processes were killed.
Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
