aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-23usb: typec: ucsi: Remove useless error check from ucsi_read_error()Heikki Krogerus1-3/+0
If the GET_ERROR_STATUS command fails, ucsi_read_error() can not reach the condition where the CCI error bit is checked, because ucsi_run_command() has already checked that bit and returned an error. Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23usb: typec: ucsi: Call CANCEL from single locationHeikki Krogerus1-13/+4
The command cancellation can be done right after detecting that the PPM is busy. There is no need to do it separately in ucsi_read_error() and ucsi_send_command_common(). Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23usb: typec: ucsi: Common function for the GET_PD_MESSAGE commandHeikki Krogerus2-77/+27
So far that command was only used to read the response to the Discover Identity Request, but it is handled with two separate functions, which is not really necessary. Squashing the command execution into a single function. That function can now also be used to read other messages on top of the Request Identity response. Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23usb: typec: ucsi: Only assign the identity structure if the PPM supports itHeikki Krogerus1-2/+4
This will make sure that the identity sysfs attribute files are kept hidden if the UCSI interface doesn't support reading the USB Power Delivery messages. Signed-off-by: Heikki Krogerus <[email protected]> Reviewed-by: Abhishek Pandit-Subedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23usb: typec: ucsi: Don't truncate the readsHeikki Krogerus2-6/+4
That may silently corrupt the data. Instead, failing attempts to read more than the interface can handle. Signed-off-by: Heikki Krogerus <[email protected]> Reviewed-by: Abhishek Pandit-Subedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23usb: typec: ucsi: Remove unused fields from struct ucsi_connector_statusHeikki Krogerus1-25/+2
The new fields are valid only with the new UCSI versions. They are at offsets that go beyond the MAX_DATA_LENGTH (16 bytes) with the older UCSI versions. That has not caused any problems before because nothing uses those new fields yet. Because they are not used yet, dropping them for now. Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-08-23irqchip/gic-v3: Init SRE before poking sysregsMark Rutland1-7/+14
The GICv3 driver pokes GICv3 system registers in gic_prio_init() before gic_cpu_sys_reg_init() ensures that GICv3 system registers have been enabled by writing to ICC_SRE_EL1.SRE. On arm64 this is benign as has_useable_gicv3_cpuif() runs earlier during cpufeature detection, and this enables the GICv3 system registers. On 32-bit arm when booting on an FVP using the boot-wrapper, the accesses in gic_prio_init() end up being UNDEFINED and crashes the kernel during boot. This is a regression introduced by the addition of gic_prio_init(). Fix this by factoring out the SRE initialization into a new function and calling it early in the three paths where SRE may not have been initialized: (1) gic_init_bases(), before the primary CPU pokes GICv3 sysregs in gic_prio_init(). (2) gic_starting_cpu(), before secondary CPUs initialize GICv3 sysregs in gic_cpu_init(). (3) gic_cpu_pm_notifier(), before CPUs re-initialize GICv3 sysregs in gic_cpu_sys_reg_init(). Fixes: d447bf09a4013541 ("irqchip/gic-v3: Detect GICD_CTRL.DS and SCR_EL3.FIQ earlier") Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Cc: [email protected]
2024-08-23kselftest/arm64: signal: fix/refactor SVE vector length enumerationAndre Przywara10-181/+132
Currently a number of SVE/SME related tests have almost identical functions to enumerate all supported vector lengths. However over time the copy&pasted code has diverged, allowing some bugs to creep in: - fake_sigreturn_sme_change_vl reports a failure, not a SKIP if only one vector length is supported (but the SVE version is fine) - fake_sigreturn_sme_change_vl tries to set the SVE vector length, not the SME one (but the other SME tests are fine) - za_no_regs keeps iterating forever if only one vector length is supported (but za_regs is correct) Since those bugs seem to be mostly copy&paste ones, let's consolidate the enumeration loop into one shared function, and just call that from each test. That should fix the above bugs, and prevent similar issues from happening again. Fixes: 4963aeb35a9e ("kselftest/arm64: signal: Add SME signal handling tests") Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-08-23soc: rockchip: grf: Add rk3576 default GRF valuesDetlev Casanova1-1/+29
Set SW controlled i3c weak pull up and disable JTAG function on SDMMC IO. The i3c weak pull up is activated to let all gpio banks be controlled by the pinctrl driver. Disabling the JTAG function lets the SDMMC core use its full IO width. Signed-off-by: Detlev Casanova <[email protected]> Acked-by: Dragan Simic <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-23dt-bindings: soc: rockchip: Add rk3576 syscon compatiblesDetlev Casanova1-0/+16
Add all syscon compatibles for RK3576. Signed-off-by: Detlev Casanova <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-23spi: bcmbca-hsspi: Simpify resource lookupJinjie Ruan1-9/+2
Instead of calling platform_get_resource_byname() and devm_ioremap_resource(), simplify the code by simply calling devm_platform_ioremap_resource_byname(). Signed-off-by: Jinjie Ruan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23spi: atmel-quadspi: Simpify resource lookupJinjie Ruan1-4/+2
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by: Jinjie Ruan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23spi: wpcm-fiu: Use devm_platform_ioremap_resource_byname()Jinjie Ruan1-4/+2
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by: Jinjie Ruan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23regmap: Use locking during kunit testsMark Brown1-2/+0
There is no reason to bypass the locking when running the kunit tests, leave it enabled as standard. Signed-off-by: Mark Brown <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23regmap: Hold the regmap lock when allocating and freeing the cacheMark Brown2-0/+5
For the benefit of the maple tree's lockdep checking hold the lock while creating and exiting the cache. Signed-off-by: Mark Brown <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: SOF: amd: add support for acp7.0 based platformVijendar Mukunda7-14/+352
Add SOF support for ACP7.0 version based platform. Signed-off-by: Vijendar Mukunda <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: amd: Add acpi machine id for acp7.0 version based platformVijendar Mukunda2-0/+13
Add acpi machine id for ACP7.0 version based platform and configure driver data to enable SOF sound card support on newer boards. Signed-off-by: Vijendar Mukunda <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: dapm-graph: show path name for non-static routesLuca Ceresoli1-2/+8
Many routes are just static, not modifiable at runtime. Show the route name for all the other routes as an edge label in the generated graph. Signed-off-by: Luca Ceresoli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: dapm-graph: visualize component On/Off bias levelLuca Ceresoli1-3/+18
Read the bias_level debugfs files (ignored so far) and visualize the On/Off state of each component using different graphic attributes in the generated graph. Signed-off-by: Luca Ceresoli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: dapm-graph: remove the "ROOT" clusterLuca Ceresoli1-8/+13
Widgets not belonging to any component are currently represented inside a cluster labeled "ROOT". This is not a correct representation of the actual structure, as these widgets are not necessarily related to each other as the ones inside actual components are. Improve the graphical representation by not adding a cluster around these widgets. Now a dot cluster represents a card component faithfully. This will be particularly important with the upcoming improvements which will visualize the component bias_level. Signed-off-by: Luca Ceresoli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: Intel: soc-acpi-cht: Make Lenovo Yoga Tab 3 X90F DMI match less strictHans de Goede1-1/+0
There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it turns out that the 2G version has a DMI product name of "CHERRYVIEW D1 PLATFORM" where as the 4G version has "CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are unique enough that the product-name check is not necessary. Drop the product-name check so that the existing DMI match for the 4G RAM version also matches the 2G RAM version. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards harderHans de Goede9-9/+9
Since commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") dummy codecs declared like this: SND_SOC_DAILINK_DEF(dummy, DAILINK_COMP_ARRAY(COMP_DUMMY())); expand to: static struct snd_soc_dai_link_component dummy[] = { }; Which means that dummy is a zero sized array and thus dais[i].codecs should not be dereferenced *at all* since it points to the address of the next variable stored in the data section as the "dummy" variable has an address but no size, so even dereferencing dais[0] is already an out of bounds array reference. Which means that the if (dais[i].codecs->name) check added in commit 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") relies on that the part of the next variable which the name member maps to just happens to be NULL. Which apparently so far it usually is, except when it isn't and then it results in crashes like this one: [ 28.795659] BUG: unable to handle page fault for address: 0000000000030011 ... [ 28.795780] Call Trace: [ 28.795787] <TASK> ... [ 28.795862] ? strcmp+0x18/0x40 [ 28.795872] 0xffffffffc150c605 [ 28.795887] platform_probe+0x40/0xa0 ... [ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102] Really fix things this time around by checking dais.num_codecs != 0. Fixes: 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-23pmdomain: Merge branch fixes into nextUlf Hansson1-34/+22
Merge the pmdomain fixes for v6.11-rc[n] into the next branch, to allow them to get tested together with the new changes that are targeted for v6.12. Signed-off-by: Ulf Hansson <[email protected]>
2024-08-23OPP: Fix support for required OPPs for multiple PM domainsUlf Hansson1-34/+22
It has turned out that having _set_required_opps() to recursively call dev_pm_opp_set_opp() to set the required OPPs, doesn't really work as well as we expected. More precisely, at each recursive call to dev_pm_opp_set_opp() we are changing an OPP for a required_dev that belongs to a required-OPP table. The problem with this, is that we may have several devices sharing the same required-OPP table, which leads to an incorrect behaviour in regards to aggregating the per device votes. To fix the problem for a required-OPP table belonging to a PM domain, which is the only existing usecase for now, let's simply replace the call to dev_pm_opp_set_opp() in _set_required_opps() by a call to _set_opp_level(). Moving forward we may potentially need to add support for other types of required-OPP tables. In this case, the aggregation needs to be thought of. Fixes: e37440e7e2c2 ("OPP: Call dev_pm_opp_set_opp() for required OPPs") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Acked-by: Viresh Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-23soc: rockchip: grf: Set RK3128's vpu main clockAlex Bee1-0/+2
RK3128 has a setting in GRF which selects whether the vpu attached iommu uses the AXI clock of the decoder (vdpu) or the encoder (vepu). The default is vepu but some part of the vendor firmware sets it to vdpu. In order to be independent on whether any of those vendor firmware blobs is used to boot the SoC reset "vpu main clock" setting to it's default value. Signed-off-by: Alex Bee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-23soc: rockchip: io-domain: Add RK3308 IO voltage domainsDavid Wu1-0/+40
Add IO voltage domains support for the RK3308 SoC. Signed-off-by: David Wu <[email protected]> Signed-off-by: Jianqun Xu <[email protected]> Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-23dt-bindings: power: rockchip: Document RK3308 IO voltage domainsJonas Karlman1-0/+24
Document dt-bindings for RK3308 IO voltage domains. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-23Merge tag 'pwrseq-fixes-for-v6.11-rc5' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fix from Bartosz Golaszewski: - request the wlan-enable GPIO "as-is" to fix an issue with the wifi module being already powered up before linux boots * tag 'pwrseq-fixes-for-v6.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: request the WLAN enable GPIO as-is
2024-08-23Merge tag 'pmdomain-v6.11-rc2' of ↵Linus Torvalds2-7/+3
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: - imx: Remove duplicated clocks for scu power domain - imx: Wait for SSAR to complete power-on for i.MX93 power domain * tag 'pmdomain-v6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: imx: wait SSAR when i.MX93 power domain on pmdomain: imx: scu-pd: Remove duplicated clocks
2024-08-23net: drop special comment styleJohannes Berg3-39/+0
As we discussed in the room at netdevconf earlier this week, drop the requirement for special comment style for netdev. For checkpatch, the general check accepts both right now, so simply drop the special request there as well. Acked-by: Stephen Hemminger <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-23iommu/amd: Update PASID, GATS, GLX, SNPAVICSUP feature related macrosSuravee Suthikulpanit3-20/+9
Clean up and reorder them according to the bit index. There is no functional change. Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Suravee Suthikulpanit <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-23iommu: Handle iommu faults for a bad iopf setupPranjal Shrivastava3-41/+87
The iommu_report_device_fault function was updated to return void while assuming that drivers only need to call iommu_report_device_fault() for reporting an iopf. This implementation causes following problems: 1. The drivers rely on the core code to call it's page_reponse, however, when a fault is received and no fault capable domain is attached / iopf_param is NULL, the ops->page_response is NOT called causing the device to stall in case the fault type was PAGE_REQ. 2. The arm_smmu_v3 driver relies on the returned value to log errors returning void from iommu_report_device_fault causes these events to be missed while logging. Modify the iommu_report_device_fault function to return -EINVAL for cases where no fault capable domain is attached or iopf_param was NULL and calls back to the driver (ops->page_response) in case the fault type was IOMMU_FAULT_PAGE_REQ. The returned value can be used by the drivers to log the fault/event as needed. Reported-by: Kunkun Jiang <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 3dfa64aecbaf ("iommu: Make iommu_report_device_fault() return void") Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Pranjal Shrivastava <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-23drm/i915/display: convert params to struct intel_displayJani Nikula7-14/+16
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_display_params.[ch] and intel_display_debugfs_params.[ch] to struct intel_display. Some stragglers are left behind where needed. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3e5cc1744eaf4708b08303e3e7e194035d7941cc.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/sprite: convert to struct intel_displayJani Nikula1-97/+112
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_sprite.[ch] to struct intel_display. Some stragglers are left behind where needed. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/094db6a9f40404fcc14843d32b45465d31730d96.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/tv: convert to struct intel_displayJani Nikula3-103/+108
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_tv.[ch] to struct intel_display. Some stragglers are left behind where needed. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/04b1c8d095a52fb817876acdab4e9139d909f306.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/vrr: convert to struct intel_displayJani Nikula1-66/+61
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_vrr.[ch] to struct intel_display. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1d25a08c62a320133fbb0a89dac3dd1081139487.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/vblank: convert to struct intel_displayJani Nikula1-47/+50
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_vblank.[ch] to struct intel_display. Some stragglers are left behind where needed. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/40430651a45ddd9e350a1fd7938fe4054492f6ea.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/vblank: fix context imbalance warningsJani Nikula1-4/+10
When building for xe, we get the context imbalance warning as the actual locking/unlocking is not compiled: ../drivers/gpu/drm/i915/display/intel_vblank.c:306:13: warning: context imbalance in 'intel_vblank_section_enter' - wrong count at exit ../drivers/gpu/drm/i915/display/intel_vblank.c:314:13: warning: context imbalance in 'intel_vblank_section_exit' - wrong count at exit Fix by adding separata stubs for xe without __acquires/__releases annotation. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/111de5bee15f408de65b19ece4b68a7ac66b30cf.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23drm/i915/vblank: use drm_crtc_vblank_crtc() instead of open-codingJani Nikula1-2/+2
There's a helper for drm->vblank[drm_crtc_index(crtc)], use it. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/78198ade92da1d978f2032c50b3b50e3f8f01701.1724342644.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-23Merge tag 'kvmarm-fixes-6.11-2' of ↵Catalin Marinas20-41/+75
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into for-next/fixes KVM/arm64 fixes for 6.11, round #2 - Don't drop references on LPIs that weren't visited by the vgic-debug iterator - Cure lock ordering issue when unregistering vgic redistributors - Fix for misaligned stage-2 mappings when VMs are backed by hugetlb pages - Treat SGI registers as UNDEFINED if a VM hasn't been configured for GICv3 * tag 'kvmarm-fixes-6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 KVM: arm64: Ensure canonical IPA is hugepage-aligned when handling fault KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors KVM: arm64: vgic-debug: Don't put unmarked LPIs KVM: arm64: vgic: Hold config_lock while tearing down a CPU interface KVM: selftests: arm64: Correct feature test for S1PIE in get-reg-list KVM: arm64: Tidying up PAuth code in KVM KVM: arm64: vgic-debug: Exit the iterator properly w/o LPI KVM: arm64: Enforce dependency on an ARMv8.4-aware toolchain docs: KVM: Fix register ID of SPSR_FIQ KVM: arm64: vgic: fix unexpected unlock sparse warnings KVM: arm64: fix kdoc warnings in W=1 builds KVM: arm64: fix override-init warnings in W=1 builds KVM: arm64: free kvm->arch.nested_mmus with kvfree()
2024-08-23leds: gpio: Set num_leds after allocationKees Cook1-3/+6
With the new __counted_by annotation, the "num_leds" variable needs to valid for accesses to the "leds" array. This requirement is not met in gpio_leds_create(), since "num_leds" starts at "0", so "leds" index "0" will not be considered valid (num_leds would need to be "1" to access index "0"). Fix this by setting the allocation size after allocation, and then update the final count based on how many were actually added to the array. Fixes: 52cd75108a42 ("leds: gpio: Annotate struct gpio_leds_priv with __counted_by") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-08-23clk: samsung: add top clock support for ExynosAuto v920 SoCSunyeal Hong2-0/+1174
This adds support for CMU_TOP which generates clocks for all the function blocks such as CORE, HSI0/1/2, PERIC0/1 and so on. For CMU_TOP, PLL_SHARED0,1,2,3,4 and 5 will be the sources of this block and they will generate bus clocks. Signed-off-by: Sunyeal Hong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-23clk: samsung: clk-pll: Add support for pll_531xSunyeal Hong2-0/+45
pll531x PLL is used in Exynos Auto v920 SoC for shared pll. pll531x: Integer/fractional PLL with mid frequency FVCO (800 to 3120 MHz) PLL531x FOUT = (MDIV x FIN)/(PDIV x 2^SDIV) for integer PLL FOUT = (MDIV + F/2^32-F[31]) x FIN/(PDIV x 2^SDIV) for fractional PLL Signed-off-by: Sunyeal Hong <[email protected]> Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-23Merge branch 'for-v6.12/clk-dt-bindings' into next/clkKrzysztof Kozlowski2-0/+353
2024-08-23arm64: dts: exynosautov920: add initial CMU clock nodes in ExynosAuto v920Sunyeal Hong1-13/+27
Add cmu_top, cmu_peric0 clock nodes and switch USI clocks instead of dummy fixed-rate-clock. Signed-off-by: Sunyeal Hong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-23Merge branch 'for-v6.12/clk-dt-bindings' into next/dt64Krzysztof Kozlowski2-0/+353
2024-08-23dt-bindings: clock: add ExynosAuto v920 SoC CMU bindingsSunyeal Hong2-0/+353
Add dt-schema for ExynosAuto v920 SoC clock controller. Add device tree clock binding definitions for below CMU blocks. - CMU_TOP - CMU_PERIC0/1 - CMU_MISC - CMU_HSI0/1 Signed-off-by: Sunyeal Hong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-23Merge tag 'asoc-fix-v6.11-rc3' of ↵Takashi Iwai17-26/+88
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.11 A relatively large collection of fixes here, all driver specific and none of them particularly major, plus one MAINTAINERS update. There's been a bunch of work on module autoloading from several people.
2024-08-23xfrm: Correct spelling in xfrm.hSimon Horman1-2/+2
Correct spelling in xfrm.h. As reported by codespell. Signed-off-by: Simon Horman <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2024-08-23rust: list: add ListArcFieldAlice Ryhl2-0/+99
One way to explain what `ListArc` does is that it controls exclusive access to the prev/next pointer field in a refcounted object. The feature of having a special reference to a refcounted object with exclusive access to specific fields is useful for other things, so provide a general utility for that. This is used by Rust Binder to keep track of which processes have a reference to a given node. This involves an object for each process/node pair, that is referenced by both the process and the node. For some fields in this object, only the process's reference needs to access them (and it needs mutable access), so Binder uses a ListArc to give the process's reference exclusive access. Reviewed-by: Benno Lossin <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>