aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04irqchip/apple-aic: Only access system registers on SoCs which provide themKonrad Dybcio1-13/+13
Starting from the A11 (T8015) SoC, Apple introuced system registers for fast IPI and UNCORE PMC control. These sysregs do not exist on earlier A7-A10 SoCs and trying to access them results in an instant crash. Restrict sysreg access within the AIC driver to configurations where use_fast_ipi is true to allow AIC to function properly on A7-A10 SoCs. Co-developed-by: Nick Chan <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Nick Chan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Sven Peter <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-09-04irqchip/apple-aic: Add a new "Global fast IPIs only" feature levelNick Chan1-4/+25
Starting with the A11 (T8015) SoC, Apple began using arm64 sysregs for fast IPIs. However, on A11, there is no such things as "Local" fast IPIs, as the SYS_IMP_APL_IPI_RR_LOCAL_EL1 register does not seem to exist. Add a new feature level, used by the compatible "apple,t8015-aic", controlled by a static branch key named use_local_fast_ipi. When use_fast_ipi is true and use_local_fast_ipi is false, fast IPIs are used but all IPIs goes through the register SYS_IMP_APL_IPI_RR_GLOBAL_EL1, as "global" IPIs. Signed-off-by: Nick Chan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Sven Peter <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-09-04irqchip/apple-aic: Skip unnecessary enabling of use_fast_ipiNick Chan1-3/+1
use_fast_ipi is true by default and there is no need to "enable" it. Signed-off-by: Nick Chan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Sven Peter <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-09-04platform/x86: thinkpad_acpi: Fix uninitialized symbol 's' warningMatthias Fetzer1-1/+1
When the TPACPI_FAN_WR_ACPI_FANW branch is taken s stays uninitialized and would be later used in a debug print. Since the registers are always set to the same two static values inside the branch s is initialized to 0. Fixes: 57d0557dfa49 ("platform/x86: thinkpad_acpi: Add Thinkpad Edge E531 fan support") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Signed-off-by: Matthias Fetzer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86: x86-android-tablets: Fix spelling in the commentsAndy Shevchenko8-52/+52
Fix spelling across comments (besides obvious grammar issues): - spell words in full, e.g., 'img' --> 'image' - refer to 'gpio-keys' consistently - refer to acpi_power_off() clearly as to function - make sure that the first line is only for the affected model(s) - miscellaneous improvements Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86: ideapad-laptop: Make the scope_guard() clear of its scopeAndy Shevchenko1-21/+27
First of all, it's a bit counterintuitive to have something like int err; ... scoped_guard(...) err = foo(...); if (err) return err; Second, with a particular kernel configuration and compiler version in one of such cases the objtool is not happy: ideapad-laptop.o: warning: objtool: .text.fan_mode_show: unexpected end of section I'm not an expert on all this, but the theory is that compiler and linker in this case can't understand that 'result' variable will be always initialized as long as no error has been returned. Assigning 'result' to a dummy value helps with this. Note, that fixing the scoped_guard() scope (as per above) does not make issue gone. That said, assign dummy value and make the scope_guard() clear of its scope. For the sake of consistency do it in the entire file. Fixes: 7cc06e729460 ("platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86/intel-uncore-freq: Add efficiency latency control to sysfs ↵Tero Kristo2-6/+49
interface Add the TPMI efficiency latency control fields to the sysfs interface. The sysfs files are mapped to the TPMI uncore driver via the registered uncore_read and uncore_write driver callbacks. These fields are not populated on older non TPMI hardware. Signed-off-by: Tero Kristo <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86/intel-uncore-freq: Add support for efficiency latency controlTero Kristo2-2/+160
Add efficiency latency control support to the TPMI uncore driver. This defines two new threshold values for controlling uncore frequency, low threshold and high threshold. When CPU utilization is below low threshold, the user configurable floor latency control frequency can be used by the system. When CPU utilization is above high threshold, the uncore frequency is increased in 100MHz steps until power limit is reached. Signed-off-by: Tero Kristo <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86: lenovo-ymc: Ignore the 0x0 stateGergo Koteles1-0/+2
While booting, Lenovo 14ARB7 reports 'lenovo-ymc: Unknown key 0 pressed' warning. This is caused by lenovo_ymc_probe() calling lenovo_ymc_notify() at probe time to get the initial tablet-mode-switch state and the key-code lenovo_ymc_notify() reads from the firmware is not initialized at probe time yet on the Lenovo 14ARB7. The hardware/firmware does an ACPI notify on the WMI device itself when it initializes the tablet-mode-switch state later on. Add 0x0 YMC state to the sparse keymap to silence the warning. Signed-off-by: Gergo Koteles <[email protected]> Link: https://lore.kernel.org/r/08ab73bb74c4ad448409f2ce707b1148874a05ce.1724340562.git.soyer@irl.hu [[email protected]: Reword commit message] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-05extcon: lc824206xa: Fix build error of POWER_SUPPLY_PROP_USB_TYPEStephen Rothwell1-10/+5
commit 364ea7ccaef9("power: supply: Change usb_types from an array into a bitmask") changes usb_types from an array into a bitmask. Fix the build error of usb_types variables. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-09-04drm/xe/display: Avoid encoder_suspend at runtime suspendRodrigo Vivi1-3/+3
Fix circular locking dependency on runtime suspend. <4> [74.952215] ====================================================== <4> [74.952217] WARNING: possible circular locking dependency detected <4> [74.952219] 6.10.0-rc7-xe #1 Not tainted <4> [74.952221] ------------------------------------------------------ <4> [74.952223] kworker/7:1/82 is trying to acquire lock: <4> [74.952226] ffff888120548488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_modeset_lock_all+0x40/0x1e0 [drm] <4> [74.952260] but task is already holding lock: <4> [74.952262] ffffffffa0ae59c0 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}, at: xe_pm_runtime_suspend+0x2f/0x340 [xe] <4> [74.952322] which lock already depends on the new lock. The commit 'b1d90a86 ("drm/xe: Use the encoder suspend helper also used by the i915 driver")' didn't do anything wrong. It actually fixed a critical bug, because the encoder_suspend was never getting actually called because it was returning if (has_display(xe)) instead of if (!has_display(xe)). However, this ended up introducing the encoder suspend calls in the runtime routines as well, causing the circular locking dependency. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2304 Fixes: b1d90a862c89 ("drm/xe: Use the encoder suspend helper also used by the i915 driver") Cc: Imre Deak <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> (cherry picked from commit 8da19441d0a02b53e362df81843bb20db3a8006a) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-09-04drm/xe: Suspend/resume user access only during system s/rImre Deak1-4/+6
Enable/Disable user access only during system suspend/resume. This should not happen during runtime s/r v2: rebased Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Vinod Govindapillai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a64e7e5b05e014dad9ae5858c9644d61400ec6ef) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-09-04drm/xe/display: Match i915 driver suspend/resume sequences betterMaarten Lankhorst1-5/+14
Suspend fbdev sooner, and disable user access before suspending to prevent some races. I've noticed this when comparing xe suspend to i915's. Matches the following commits from i915: 24b412b1bfeb ("drm/i915: Disable intel HPD poll after DRM poll init/enable") 1ef28d86bea9 ("drm/i915: Suspend the framebuffer console earlier during system suspend") bd738d859e71 ("drm/i915: Prevent modesets during driver init/shutdown") Thanks to Imre for pointing me to those commits. Driver shutdown is currently missing, but I have some idea how to implement it next. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maarten Lankhorst,,, <[email protected]> (cherry picked from commit 492be2a070f023c66aaef6ebd664567fda28c2a6) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-09-05PM / devfreq: imx-bus: Use of_property_present()Rob Herring (Arm)1-1/+1
Use of_property_present() to test for property presence rather than of_get_property(). This is part of a larger effort to remove callers of of_get_property() and similar functions. of_get_property() leaks the DT property data pointer which is a problem for dynamically allocated nodes which may be freed. Link: https://lore.kernel.org/lkml/[email protected]/ Acked-by: Peng Fan <[email protected]> Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-09-04drm/xe: Add missing runtime reference to wedged upon gt_resetRodrigo Vivi1-2/+3
Fixes this missed case: xe 0000:00:02.0: [drm] Missing outer runtime PM protection WARNING: CPU: 99 PID: 1455 at drivers/gpu/drm/xe/xe_pm.c:564 xe_pm_runtime_get_noresume+0x48/0x60 [xe] Call Trace: <TASK> ? show_regs+0x67/0x70 ? __warn+0x94/0x1b0 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] ? report_bug+0x1b7/0x1d0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? xe_pm_runtime_get_noresume+0x48/0x60 [xe] xe_device_declare_wedged+0x91/0x280 [xe] gt_reset_worker+0xa2/0x250 [xe] v2: Also move get and get the right Fixes tag (Himal, Brost) Fixes: fb74b205cdd2 ("drm/xe: Introduce a simple wedged state") Cc: Himal Prasad Ghimiray <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> (cherry picked from commit bc947d9a8c3ebd207e52c0e35cfc88f3e1abe54f) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-09-04extcon: axp288: Switch to new Intel CPU model definesTony Luck1-1/+1
New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-09-05Merge tag 'ib-psy-usb-types-signed' of ↵Chanwoo Choi23-251/+125
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply into extcon-next Immutable branch for usb_types change for v6.12 Changing usb_types type from array to bitmap in the power_supply_desc struct requires updating power-supply drivers living in different subsystem, so it is handled via an immutable branch.
2024-09-05extcon: Add LC824206XA microUSB switch driverHans de Goede3-0/+512
Add a new driver for the ON Semiconductor LC824206XA microUSB switch and accessory detector chip. ON Semiconductor has an "Advance Information" datasheet available (ENA2222-D.PDF), but no full datasheet. So there is no documentation available for the registers. This driver is based on the register info from the extcon-fsa9285.c driver, from the Lollipop Android sources for the Lenovo Yoga Tablet 2 (Pro) 830 / 1050 / 1380 models. Note despite the name this is actually a driver for the LC824206XA not the FSA9285. This has only been tested on a Lenovo Yoga Tablet 2 Pro 1380 and using the driver on other setups may require additional work. So far this driver is only used on x86/ACPI (non devicetree) devs. Therefor there is no devicetree bindings documentation for this driver's "onnn,enable-miclr-for-dcp" property since this is not used in actual devicetree files and the dt bindings maintainers have requested properties with no actual dt users to _not_ be added to the dt bindings. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-09-04iommu/tegra241-cmdqv: Fix ioremap() error handling in probe()Dan Carpenter1-3/+3
The ioremap() function doesn't return error pointers, it returns NULL on error so update the error handling. Also just return directly instead of calling iounmap() on the NULL pointer. Calling iounmap(NULL) doesn't cause a problem on ARM but on other architectures it can trigger a warning so it'a bad habbit. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-09-05PM / devfreq: exynos: Use Use devm_clk_get_enabled() helpersAnand Moon1-17/+5
The devm_clk_get_enabled() helpers: - call devm_clk_get() - call clk_prepare_enable() and register what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the calls to clk_disable_unprepare(). While at it, use dev_err_probe consistently, and use its return value to return the error code. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Anand Moon <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-09-05PM/devfreq: governor: add missing MODULE_DESCRIPTION() macrosJeff Johnson4-0/+4
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_simpleondemand.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_performance.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_powersave.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_userspace.o Add all missing invocations of the MODULE_DESCRIPTION() macro. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-09-04cpufreq: ti-cpufreq: Use socinfo to get revision in AM62 familyDhruva Gole1-0/+19
In the AM62x, AM62Ax, and AM62Px devices, we already have the revision info within the k3-socinfo driver. Hence, re-use this information from there instead of re using the offset for 2 drivers trying to get the same information ie. revision. Signed-off-by: Dhruva Gole <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: Fix the cacography in powernv-cpufreq.cLiu Jing1-1/+1
The word 'swtich' is wrong, so fix it. Signed-off-by: Liu Jing <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriatelyNishanth Menon1-2/+8
Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx") introduced special handling for OMAP3 class devices where syscon node may not be present. However, this also creates a bug where the syscon node is present, however the offset used to read is beyond the syscon defined range. Fix this by providing a quirk option that is populated when such special handling is required. This allows proper failure for all other platforms when the syscon node and efuse offsets are mismatched. Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx") Signed-off-by: Nishanth Menon <[email protected]> Tested-by: Dhruva Gole <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()Huacai Chen1-1/+1
Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq] Reported-by: Xi Ruoyao <[email protected]> Tested-by: Binbin Zhou <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: amd-pstate: add check for cpufreq_cpu_get's return valueAnastasia Belova1-2/+12
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Anastasia Belova <[email protected]> Reviewed-by: Perry Yuan <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: Add SM7325 to cpufreq-dt-platdev blocklistDanila Tikhonov1-0/+1
The Qualcomm SM7325 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Danila Tikhonov <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: Fix warning on unused of_device_id tables for !CONFIG_OFRob Herring (Arm)4-4/+4
!CONFIG_OF builds cause warnings on unused of_device_id tables. This is due to of_match_node() being a macro rather than static inline function. Add a __maybe_unused annotation to the of_device_id tables. Fixes: c7582ec85342 ("cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm drivers") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()Dhananjay Ugwekar1-1/+4
Fix the reference counting of cpufreq_policy object in amd_pstate_update() function by adding the missing cpufreq_cpu_put(). Fixes: e8f555daacd3 ("cpufreq/amd-pstate: fix setting policy current frequency value") Signed-off-by: Dhananjay Ugwekar <[email protected]> Reviewed-by: Perry Yuan <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: Drop CONFIG_ARM and CONFIG_ARM64 dependency on Arm driversRob Herring (Arm)1-2/+0
The CONFIG_ARM and CONFIG_ARM64 dependency is redundant as all the drivers have necessary sub-arch dependency and don't depend on the architecture support. Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04cpufreq: Enable COMPILE_TEST on Arm driversRob Herring (Arm)1-20/+30
COMPILE_TEST is useful for build testing without requiring a specific architecture's compiler. Enable it for most of the Arm CPUFreq drivers. As Kconfig.arm is only included on ARM and ARM64, COMPILE_TEST is only enabled for those architectures until that is dropped. Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04opp: ti: Drop unnecessary of_match_ptr()Rob Herring (Arm)1-1/+1
of_match_ptr() is not necessary as the driver is always enabled for DT. Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-09-04perf/arm-cmn: Support CMN S3Robin Murphy1-43/+76
CMN S3 is the latest and greatest evolution for 2024, although most of the new features don't impact the PMU, so from our point of view it ends up looking a lot like CMN-700 r3 still. We have some new device types to ignore, a mildly irritating rearrangement of the register layouts, and a scary new configuration option that makes it potentially unsafe to even walk the full discovery tree, let alone attempt to use the PMU. Acked-by: Mark Rutland <[email protected]> Reviewed-by: Ilkka Koskinen <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/2ec9eec5b6bf215a9886f3b69e3b00e4cd85095c.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Refactor DTC PMU register accessRobin Murphy1-28/+36
Annoyingly, we're soon going to have to cope with PMU registers moving about. This will mostly be straightforward, except for the hard-coding of CMN_PMU_OFFSET for the DTC PMU registers. As a first step, refactor those accessors to allow for encapsulating a variable offset without making a big mess all over. As a bonus, we can repack the arm_cmn_dtc structure to accommodate the new pointer without growing any larger, since irq_friend only encodes a range of +/-3. Acked-by: Mark Rutland <[email protected]> Reviewed-by: Ilkka Koskinen <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/fc677576fae7b5b55780e5b245a4ef6ea1b30daf.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Make cycle counts less surprisingRobin Murphy1-5/+11
By default, CMN has automatic clock-gating with the implication that a DTC's cycle counter may not increment while the DTC is sufficiently idle. Given that we may have up to 4 DTCs to choose from when scheduling a cycles event, this may potentially lead to surprising results if trying to measure metrics based on activity in a different DTC domain from where cycles end up being counted. Furthermore, since the details of internal clock gating are not documented, we can't even reason about what "active" cycles for a DTC actually mean relative to the activity of other nodes within the same nominal DTC domain. Make the reasonable assumption that if the user wants to count cycles, they almost certainly want to count all of the cycles, and disable clock gating while a DTC's cycle counter is in use. Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/c47cfdc09e907b1d7753d142a7e659982cceb246.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Improve build-time assertionRobin Murphy1-1/+1
These days we can use static_assert() in the logical place rather than jamming a BUILD_BUG_ON() into the nearest function scope. Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/224ee8286f299100f1c768edb254edc898539f50.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Ensure dtm_idx is big enoughRobin Murphy1-1/+4
While CMN_MAX_DIMENSION was bumped to 12 for CMN-650, that only supports up to a 10x10 mesh, so bumping dtm_idx to 256 bits at the time worked out OK in practice. However CMN-700 did finally support up to 144 XPs, and thus needs a worst-case 288 bits of dtm_idx for an aggregated XP event on a maxed-out config. Oops. Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support") Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/e771b358526a0d7fc06efee2c3a2fdc0c9f51d44.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Fix CCLA register offsetRobin Murphy1-3/+7
Apparently pmu_event_sel is offset by 8 for all CCLA nodes, not just the CCLA_RNI combination type. Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support") Acked-by: Mark Rutland <[email protected]> Reviewed-by: Ilkka Koskinen <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/6e7bb06fef6046f83e7647aad0e5be544139763f.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04perf/arm-cmn: Refactor node ID handling. Again.Robin Murphy1-54/+40
The scope of the "extra device ports" configuration is not made clear by the CMN documentation - so far we've assumed it applies globally, based on the sole example which suggests as much. However it transpires that this is incorrect, and the format does in fact vary based on each individual XP's port configuration. As a consequence, we're currenly liable to decode the port/device indices from a node ID incorrectly, thus program the wrong event source in the DTM leading to bogus event counts, and also show device topology on the wrong ports in debugfs. To put this right, rework node IDs yet again to carry around the additional data necessary to decode them properly per-XP. At this point the notion of fully decomposing an ID becomes more impractical than it's worth, so unabstracting the XY mesh coordinates (where 2/3 users were just debug anyway) ends up leaving things a bit simpler overall. Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Acked-by: Mark Rutland <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/5195f990152fc37adba5fbf5929a6b11063d9f09.1725296395.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2024-09-04PCI: j721e: Add suspend and resume supportThéo Lebrun1-6/+92
Add suspend and resume support. Only the Root Complex mode is supported. During the suspend stage PERST# is asserted, then deasserted during the resume stage. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Théo Lebrun <[email protected]> Signed-off-by: Thomas Richard <[email protected]> [kwilczynski: commit log, update references to the PCI SIG specification] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Siddharth Vadapalli <[email protected]>
2024-09-04PCI: j721e: Use T_PERST_CLK_US macroThomas Richard1-1/+1
Use the T_PERST_CLK_US macro, and the fsleep() function instead of usleep_range(). Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Thomas Richard <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-09-04PCI: Add T_PERST_CLK_US macroThomas Richard1-1/+16
The "Power Sequencing and Reset Signal Timings" table of the PCI Express Card Electromechanical Specification, Revision 5.1, Section 2.9.2, indicates PERST# should be deasserted after minimum of 100us once REFCLK is stable (symbol T_PERST-CLK). Add a macro so that PCIe controller drivers can use it. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Thomas Richard <[email protected]> [kwilczynski: commit log, update sleep interval macros code comments] Signed-off-by: Krzysztof Wilczyński <[email protected]>
2024-09-04ARM: 9417/1: dma-mapping: Pass device to arm_iommu_create_mapping()Jason Gunthorpe4-6/+4
All users of ARM IOMMU mappings create them for a particular device, so change the interface to accept the device rather than forcing a vague indirection through a bus type. This prepares for making a similar change to iommu_domain_alloc() itself. Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04ARM: 9416/1: amba: make amba_bustype constantKunwu Chan1-1/+1
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the amba_bustype variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <[email protected]> Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04PCI: brcmstb: Don't conflate the reset rescal with PHY ctrlJim Quinlan1-3/+14
Add a "has_phy" field indicating that the internal PHY has SW control that requires configuration. Some previous chips only required the firing of the "rescal" reset controller. This change requires us to give the 7216 SoC its own cfg_data structure. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04PCI: brcmstb: Remove two unused constants from driverJim Quinlan1-5/+0
Remove two constants in the driver which are no longer used: RGR1_SW_INIT_1_INIT_MASK and RGR1_SW_INIT_1_INIT_SHIFT. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
2024-09-04PCI: brcmstb: PCI: brcmstb: Make HARD_DEBUG, INTR2_CPU_BASE offsets SoC-specificJim Quinlan1-15/+24
Do preparatory work for the 7712 SoC, which is introduced in a future commit. Our HW design has changed two register offsets for the 7712, where previously it was a common value for all Broadcom SoCs with PCIe cores. Specifically, the two offsets are to the registers HARD_DEBUG and INTR2_CPU_BASE. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Tested-by: Florian Fainelli <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04PCI: brcmstb: Use swinit reset if availableJim Quinlan1-0/+24
The 7712 SoC adds a software init reset device for the PCIe HW. If found in the DT node, use it. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-09-04PCI: brcmstb: Use bridge reset if availableJim Quinlan1-1/+17
The 7712 SoC has a bridge reset which can be described in the device tree. Use it if present. Otherwise, continue to use the legacy method to reset the bridge. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log, refactored function brcm_pcie_bridge_sw_init_set_generic()] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanimir Varbanov <[email protected]>
2024-09-04tty: sysfs: Add nbcon support for 'active'John Ogness1-1/+1
Allow the 'active' attribute to list nbcon consoles. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.