aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-04-25arm64: dts: freescale: ls1028a: Add standard PCI device compatible strings ↵Rob Herring (Arm)1-6/+6
to ENETC PCI devices should have a compatible string based on the vendor and device IDs. Add these to the Freescale ENETC devices. Putting the PCI compatible string first as vendor and device ID is more specific than a compatible without any device specific information. Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25arm64: dts: freescale: ls1028a: Fix embedded PCI interrupt mappingRob Herring (Arm)1-2/+6
PCI devices should use PCI interrupt binding for their interrupts assuming they function as standard PCI interrupts. The embedded PCI devices in the LS1028a are mapping the interrupts directly to the host interrupt controller. While that works here, it is unusual. Based on the reference manual, there is not any INTC or INTD to map, so only INTA and INTB are mapped. Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960 and sai[0,1,4,5]Frank Li1-0/+138
Add cm40_i2c, wm8960 and sai[0,1,4,5] for imx8qxp-mek (SCH-38813). Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25arm64: dts: imx8mp: Align both CSI2 pixel clockMarek Vasut1-2/+2
Configure both CSI2 clock-frequency and assigned-clock-rates the same way. There does not seem to be any reason for keeping the two CSI2 pixel clock set to different frequencies. This also reduces first CSI2 clock from overdrive mode frequency which is 500 MHz down below the regular mode frequency of 400 MHz. Reviewed-by: Alexander Stein <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Ahmad Fatoum <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25ARM: dts: imx6ull-tarragon: Reduce SPI clock for QCA7000Stefan Wahren3-4/+4
Our hardware department recently informed us that, according to the specification, the QCA7000 should be operated with a maximum SPI clock frequency of 12 MHz. Even if it appears to work at a higher frequency, we should not take any risks here. A short performance test showed no measurable loss of speed. Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25ARM: dts: imx6ull-tarragon: fix USB over-current polarityMichael Heimpold1-0/+1
Our Tarragon platform uses a active-low signal to inform the i.MX6ULL about the over-current detection. Fixes: 5e4f393ccbf0 ("ARM: dts: imx6ull: Add chargebyte Tarragon support") Signed-off-by: Michael Heimpold <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25ARM: dts: nxp: imx6qdl: fix esai clock warning when do dtb_checkFrank Li1-2/+1
Remove unused clock-names 'mem'. Driver (sound/soc/fsl/fsl_esai.c.) never use clock name 'mem'. arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: clocks: [[2, 208], [2, 209], [2, 118], [2, 208], [2, 156]] is too long from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: clock-names:1: 'extal' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: clock-names:2: 'fsys' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: clock-names:3: 'spba' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6q-sabreauto.dtb: esai@2024000: clock-names: ['core', 'mem', 'extal', 'fsys', 'spba'] is too long from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-25ARM: dts: nxp: imx6sx: fix esai related warning when do dtb_checkFrank Li1-3/+2
Remove undocumented compatible string 'fsl,imx6sx-esai', which never used in driver sound/soc/fsl/fsl_esai.c. Remove unused clock-names 'mem'. Driver never use clock name 'mem'. Fix below warning: arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: compatible:0: 'fsl,imx6sx-esai' is not one of ['fsl,imx35-esai', 'fsl,imx6ull-esai', 'fsl,imx8qm-esai', 'fsl,vf610-esai'] from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arm/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: compatible: ['fsl,imx6sx-esai', 'fsl,imx35-esai'] is too long from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arm/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: clocks: [[2, 239], [2, 240], [2, 152], [2, 239], [2, 196]] is too long from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: clock-names:1: 'extal' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: clock-names:2: 'fsys' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: clock-names:3: 'spba' was expected from schema $id: http://devicetree.org/schemas/sound/fsl,esai.yaml# arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtb: esai@2024000: clock-names: ['core', 'mem', 'extal', 'fsys', 'spba'] is too long Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-04-24riscv: cmpxchg: implement arch_cmpxchg64_{relaxed|acquire|release}Jisheng Zhang1-0/+18
After selecting ARCH_USE_CMPXCHG_LOCKREF, one straight futher optimization is implementing the arch_cmpxchg64_relaxed() because the lockref code does not need the cmpxchg to have barrier semantics. At the same time, implement arch_cmpxchg64_acquire and arch_cmpxchg64_release as well. However, on both TH1520 and JH7110 platforms, I didn't see obvious performance improvement with Linus' test case [1]. IMHO, this may be related with the fence and lr.d/sc.d hw implementations. In theory, lr/sc without fence could give performance improvement over lr/sc plus fence, so add the code here to leave performance improvement room on newer HW platforms. Link: http://marc.info/?l=linux-fsdevel&m=137782380714721&w=4 [1] Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Andrea Parri <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-04-24riscv: select ARCH_USE_CMPXCHG_LOCKREFJisheng Zhang1-0/+1
Select ARCH_USE_CMPXCHG_LOCKREF to enable the cmpxchg-based lockless lockref implementation for riscv. Using Linus' test case[1] on TH1520 platform, I see a 11.2% improvement. On JH7110 platform, I see 12.0% improvement. Link: http://marc.info/?l=linux-fsdevel&m=137782380714721&w=4 [1] Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Andrea Parri <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-04-24KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()Oliver Upton1-4/+4
vgic_v2_parse_attr() is responsible for finding the vCPU that matches the user-provided CPUID, which (of course) may not be valid. If the ID is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled gracefully. Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id() actually returns something and fail the ioctl if not. Cc: [email protected] Fixes: 7d450e282171 ("KVM: arm/arm64: vgic-new: Add userland access to VGIC dist registers") Reported-by: Alexander Potapenko <[email protected]> Tested-by: Alexander Potapenko <[email protected]> Reviewed-by: Alexander Potapenko <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-04-24ARM: dts: BCM5301X: Conform to DTS Coding Style on ASUS RT-AC3100 & AC88UArınç ÜNAL2-81/+80
Reorder the nodes and properties to conform to the Devicetree Sources (DTS) Coding Style. Signed-off-by: Arınç ÜNAL <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240423-for-soc-asus-rt-ac3200-ac5300-v3-5-23d33cfafe7a@arinc9.com Signed-off-by: Florian Fainelli <[email protected]>
2024-04-24ARM: dts: BCM5301X: Add DT for ASUS RT-AC5300Arınç ÜNAL2-0/+157
Add the device tree for ASUS RT-AC5300 which is an AC5300 router featuring 5 Ethernet ports over the integrated Broadcom switch. Hardware info: * Processor: Broadcom BCM4709C0 dual-core @ 1.4 GHz * Switch: BCM53012 in BCM4709C0 * DDR3 RAM: 512 MB * Flash: 128 MB * 2.4GHz: BCM4366 4x4 single chip 802.11b/g/n SoC * 5GHz: BCM4366 4x4 two chips 802.11a/n/ac SoC * Ports: 4 LAN Ports, 1 WAN Port Co-developed-by: Tom Brautaset <[email protected]> Signed-off-by: Tom Brautaset <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240423-for-soc-asus-rt-ac3200-ac5300-v3-4-23d33cfafe7a@arinc9.com Signed-off-by: Florian Fainelli <[email protected]>
2024-04-24ARM: dts: BCM5301X: Add DT for ASUS RT-AC3200Arınç ÜNAL2-0/+151
Add the device tree for ASUS RT-AC3200 which is an AC3200 router featuring 5 Ethernet ports over the integrated Broadcom switch. Hardware info: * Processor: Broadcom BCM4709A0 dual-core @ 1.0 GHz * Switch: BCM53012 in BCM4709A0 * DDR3 RAM: 256 MB * Flash: 128 MB * 2.4GHz: BCM43602 3x3 single chip 802.11b/g/n SoC * 5GHz: BCM43602 3x3 two chips 802.11a/n/ac SoC * Ports: 4 LAN Ports, 1 WAN Port Co-developed-by: Tom Brautaset <[email protected]> Signed-off-by: Tom Brautaset <[email protected]> Signed-off-by: Arınç ÜNAL <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240423-for-soc-asus-rt-ac3200-ac5300-v3-3-23d33cfafe7a@arinc9.com Signed-off-by: Florian Fainelli <[email protected]>
2024-04-24ARM: dts: bcm2835: Add Unicam CSI nodesJean-Michel Hautbois3-0/+46
Add both MIPI CSI-2 nodes in the bcm283x tree and take care of the Raspberry Pi / BCM2711 specific in the related files. Signed-off-by: Jean-Michel Hautbois <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]>
2024-04-24x86/tdx: Preserve shared bit on mprotect()Kirill A. Shutemov2-1/+3
The TDX guest platform takes one bit from the physical address to indicate if the page is shared (accessible by VMM). This bit is not part of the physical_mask and is not preserved during mprotect(). As a result, the 'shared' bit is lost during mprotect() on shared mappings. _COMMON_PAGE_CHG_MASK specifies which PTE bits need to be preserved during modification. AMD includes 'sme_me_mask' in the define to preserve the 'encrypt' bit. To cover both Intel and AMD cases, include 'cc_mask' in _COMMON_PAGE_CHG_MASK instead of 'sme_me_mask'. Reported-and-tested-by: Chris Oo <[email protected]> Fixes: 41394e33f3a0 ("x86/tdx: Extend the confidential computing API to support TDX guests") Signed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/20240424082035.4092071-1-kirill.shutemov%40linux.intel.com
2024-04-24x86/cpu: Fix check for RDPKRU in __show_regs()David Kaplan1-1/+1
cpu_feature_enabled(X86_FEATURE_OSPKE) does not necessarily reflect whether CR4.PKE is set on the CPU. In particular, they may differ on non-BSP CPUs before setup_pku() is executed. In this scenario, RDPKRU will #UD causing the system to hang. Fix by checking CR4 for PKE enablement which is always correct for the current CPU. The scenario happens by inserting a WARN* before setup_pku() in identiy_cpu() or some other diagnostic which would lead to calling __show_regs(). [ bp: Massage commit message. ] Signed-off-by: David Kaplan <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24x86/resctrl: Add tracepoint for llc_occupancy trackingHaifeng Xu2-0/+27
In our production environment, after removing monitor groups, those unused RMIDs get stuck in the limbo list forever because their llc_occupancy is always larger than the threshold. But the unused RMIDs can be successfully freed by turning up the threshold. In order to know how much the threshold should be, perf can be used to acquire the llc_occupancy of RMIDs in each rdt domain. Instead of using perf tool to track llc_occupancy and filter the log manually, it is more convenient for users to use tracepoint to do this work. So add a new tracepoint that shows the llc_occupancy of busy RMIDs when scanning the limbo list. Suggested-by: Reinette Chatre <[email protected]> Suggested-by: James Morse <[email protected]> Signed-off-by: Haifeng Xu <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: James Morse <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24x86/resctrl: Rename pseudo_lock_event.h to trace.hHaifeng Xu2-5/+5
Now only the pseudo-locking part uses tracepoints to do event tracking, but other parts of resctrl may need new tracepoints. It is unnecessary to create separate header files and define CREATE_TRACE_POINTS in different c files which fragments the resctrl tracing. Therefore, give the resctrl tracepoint header file a generic name to support its use for tracepoints that are not specific to pseudo-locking. No functional change. Suggested-by: Reinette Chatre <[email protected]> Signed-off-by: Haifeng Xu <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24x86/CPU/AMD: Add models 0x10-0x1f to the Zen5 rangeWenkuan Wang1-2/+1
Add some more Zen5 models. Fixes: 3e4147f33f8b ("x86/CPU/AMD: Add X86_FEATURE_ZEN5") Signed-off-by: Wenkuan Wang <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24x86/resctrl: Simplify call convention for MSR update functionsTony Luck3-27/+18
The per-resource MSR update functions cat_wrmsr(), mba_wrmsr_intel(), and mba_wrmsr_amd() all take three arguments: (struct rdt_domain *d, struct msr_param *m, struct rdt_resource *r) struct msr_param contains pointers to both struct rdt_resource and struct rdt_domain, thus only struct msr_param is necessary. Pass struct msr_param as a single parameter. Clean up formatting and fix some fir tree declaration ordering. No functional change. Suggested-by: Reinette Chatre <[email protected]> Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Maciej Wieczor-Retman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24x86/resctrl: Pass domain to target CPUTony Luck4-52/+17
reset_all_ctrls() and resctrl_arch_update_domains() use on_each_cpu_mask() to call rdt_ctrl_update() on potentially one CPU from each domain. But this means rdt_ctrl_update() needs to figure out which domain to apply changes to. Doing so requires a search of all domains in a resource, which can only be done safely if cpus_lock is held. Both callers do hold this lock, but there isn't a way for a function called on another CPU via IPI to verify this. Commit c0d848fcb09d ("x86/resctrl: Remove lockdep annotation that triggers false positive") removed the incorrect assertions. Add the target domain to the msr_param structure and call rdt_ctrl_update() for each domain separately using smp_call_function_single(). This means that rdt_ctrl_update() doesn't need to search for the domain and get_domain_from_cpu() can safely assert that the cpus_lock is held since the remaining callers do not use IPI. Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: James Morse <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Maciej Wieczor-Retman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24sched/cpufreq: Rename arch_update_thermal_pressure() => ↵Vincent Guittot2-6/+6
arch_update_hw_pressure() Now that cpufreq provides a pressure value to the scheduler, rename arch_update_thermal_pressure into HW pressure to reflect that it returns a pressure applied by HW (i.e. with a high frequency change) and not always related to thermal mitigation but also generated by max current limitation as an example. Such high frequency signal needs filtering to be smoothed and provide an value that reflects the average available capacity into the scheduler time scale. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Lukasz Luba <[email protected]> Reviewed-by: Qais Yousef <[email protected]> Reviewed-by: Lukasz Luba <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24locking/pvqspinlock/x86: Use _Q_LOCKED_VAL in PV_UNLOCK_ASM macroUros Bizjak1-1/+1
Use _Q_LOCKED_VAL instead of hardcoded $0x1 in PV_UNLOCK_ASM macro. No functional changes intended. Signed-off-by: Uros Bizjak <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Boqun Feng <[email protected]> Cc: Waiman Long <[email protected]> Cc: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24locking/qspinlock/x86: Micro-optimize virt_spin_lock()Uros Bizjak1-4/+9
Optimize virt_spin_lock() to use simpler and faster: atomic_try_cmpxchg(*ptr, &val, new) instead of: atomic_cmpxchg(*ptr, val, new) == val The x86 CMPXCHG instruction returns success in the ZF flag, so this change saves a compare after the CMPXCHG. Also optimize retry loop a bit. atomic_try_cmpxchg() fails iff &lock->val != 0, so there is no need to load and compare the lock value again - cpu_relax() can be unconditinally called in this case. This allows us to generate optimized: 1f: ba 01 00 00 00 mov $0x1,%edx 24: 8b 03 mov (%rbx),%eax 26: 85 c0 test %eax,%eax 28: 75 63 jne 8d <...> 2a: f0 0f b1 13 lock cmpxchg %edx,(%rbx) 2e: 75 5d jne 8d <...> ... 8d: f3 90 pause 8f: eb 93 jmp 24 <...> instead of: 1f: ba 01 00 00 00 mov $0x1,%edx 24: 8b 03 mov (%rbx),%eax 26: 85 c0 test %eax,%eax 28: 75 13 jne 3d <...> 2a: f0 0f b1 13 lock cmpxchg %edx,(%rbx) 2e: 85 c0 test %eax,%eax 30: 75 f2 jne 24 <...> ... 3d: f3 90 pause 3f: eb e3 jmp 24 <...> Signed-off-by: Uros Bizjak <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Waiman Long <[email protected]> Cc: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24locking/atomic/x86: Merge __arch{,_try}_cmpxchg64_emu_local() with ↵Uros Bizjak1-46/+10
__arch{,_try}_cmpxchg64_emu() Macros __arch{,_try}_cmpxchg64_emu() are almost identical to their local variants __arch{,_try}_cmpxchg64_emu_local(), differing only by lock prefixes. Merge these two macros by introducing additional macro parameters to pass lock location and lock prefix from their respective static inline functions. No functional change intended. Signed-off-by: Uros Bizjak <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24microblaze: Remove early printk call from cpuinfo-static.cMichal Simek1-1/+1
Early printk has been removed already that's why also remove calling it. Similar change has been done in cpuinfo-pvr-full.c by commit cfbd8d1979af ("microblaze: Remove early printk setup"). Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support") Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/2f10db506be8188fa07b6ec331caca01af1b10f8.1712824039.git.michal.simek@amd.com
2024-04-24microblaze: Remove gcc flag for non existing early_printk.c fileMichal Simek1-1/+0
early_printk support for removed long time ago but compilation flag for ftrace still points to already removed file that's why remove that line too. Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support") Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/5493467419cd2510a32854e2807bcd263de981a0.1712823702.git.michal.simek@amd.com
2024-04-24ARM: dts: aspeed: Add vendor prefixes to lm25066 compat stringsZev Weiss2-3/+3
Due to the way i2c driver matching works (falling back to the driver's id_table if of_match_table fails) this didn't actually cause any misbehavior, but let's add the vendor prefixes so things actually work the way they were intended to. Signed-off-by: Zev Weiss <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-04-24arm64: dts: cavium: thunder2-99xx: drop redundant reg-namesKrzysztof Kozlowski1-1/+0
There is no "reg-names" property in the PCI bindings and the value does not conform to Devicetree coding style (upper-case letters, space), so assume this was copied from downstream. This fixes dtbs_check warning: thunder2-99xx.dtb: pcie@30000000: Unevaluated properties are not allowed ('reg-names' was unexpected) Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-04-24arm64: dts: amazon: alpine-v3: correct gic unit addressesKrzysztof Kozlowski1-1/+1
Correct gic unit addresses to fix dtc W=1 warnings: alpine-v3.dtsi:321.38-331.5: Warning (simple_bus_reg): /soc/interrupt-controller@f0000000: simple-bus unit address format error, expected "f0800000" Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: amazon: alpine-v3: drop cache nodes unit addressesKrzysztof Kozlowski1-4/+4
Cache device nodes within cpus do not have "reg" property, so should not have unit address, as reported by dtc W=1 warnings: alpine-v3.dtsi:247.24-254.5: Warning (unit_address_vs_reg): /cpus/cache@0: node has a unit name, but no reg or ranges property alpine-v3.dtsi:256.26-263.5: Warning (unit_address_vs_reg): /cpus/cache@100: node has a unit name, but no reg or ranges property alpine-v3.dtsi:265.26-272.5: Warning (unit_address_vs_reg): /cpus/cache@200: node has a unit name, but no reg or ranges property alpine-v3.dtsi:274.26-281.5: Warning (unit_address_vs_reg): /cpus/cache@300: node has a unit name, but no reg or ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: amazon: alpine-v3: add missing io-fabric unit addressesKrzysztof Kozlowski1-1/+1
Add io-fabric unit address, because it has ranges property. This also fixes dtc W=1 warnings: alpine-v2.dtsi:153.13-229.5: Warning (simple_bus_reg): /soc/io-fabric: simple-bus unit address format error, expected "fc000000" Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: amazon: alpine-v2: move non-MMIO node out of socKrzysztof Kozlowski1-16/+17
Non-MMIO devices should not be within simple-bus, as reported by dtc W=1 warning: alpine-v2.dtsi:100.9-106.5: Warning (simple_bus_reg): /soc/timer: missing or empty reg/ranges property alpine-v2.dtsi:108.7-114.5: Warning (simple_bus_reg): /soc/pmu: missing or empty reg/ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: amazon: alpine-v2: add missing io-fabric unit addressesKrzysztof Kozlowski1-1/+1
Add io-fabric unit address, because it has ranges property. This also fixes dtc W=1 warnings: alpine-v2.dtsi:153.13-229.5: Warning (simple_bus_reg): /soc/io-fabric: simple-bus unit address format error, expected "fc000000" Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: apm: shadowcat: move non-MMIO node out of socKrzysztof Kozlowski1-7/+7
Non-MMIO devices, like fixed-clocks, should not be within simple-bus. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: apm: storm: move non-MMIO node out of socKrzysztof Kozlowski1-6/+7
Non-MMIO devices, like fixed-clocks, should not be within simple-bus. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: cavium: correct unit addressesKrzysztof Kozlowski1-3/+3
Correct several nodes' unit addresses to fix dtc W=1 warnings: thunder-88xx.dtsi:381.44-398.5: Warning (simple_bus_reg): /soc/interrupt-controller@8010,00000000: simple-bus unit address format error, expected "801000000000" thunder-88xx.dtsi:400.30-406.5: Warning (simple_bus_reg): /soc/serial@87e0,24000000: simple-bus unit address format error, expected "87e024000000" thunder-88xx.dtsi:408.30-414.5: Warning (simple_bus_reg): /soc/serial@87e0,25000000: simple-bus unit address format error, expected "87e025000000" Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: cavium: move non-MMIO node out of socKrzysztof Kozlowski1-7/+7
Non-MMIO devices, which are BTW not really part of the SoC, should not be within simple-bus, as reported by dtc W=1 warning: thunder-88xx.dtsi:374.28-379.5: Warning (simple_bus_reg): /soc/refclk50mhz: missing or empty reg/ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: realtek: rtc16xx: add missing unit address to soc nodeKrzysztof Kozlowski1-1/+1
"soc" node has "ranges" property thus add matching unit address to fix dtc W=1 warnings: rtd16xx.dtsi:130.6-198.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: realtek: rtd139x: add missing unit address to soc nodeKrzysztof Kozlowski1-1/+1
"soc" node has "ranges" property thus add matching unit address to fix dtc W=1 warnings: rtd139x.dtsi:50.6-120.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: realtek: rtd129x: add missing unit address to soc nodeKrzysztof Kozlowski1-1/+1
"soc" node has "ranges" property thus add matching unit address to fix dtc W=1 warnings: rtd129x.dtsi:51.6-122.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: uniphier: ld20-global: drop audio codec port unit addressKrzysztof Kozlowski1-1/+1
Audio codec port does not have "reg", thus it should not have unit address, as reported by dtc W=1 warning: uniphier-ld20-global.dts:127.10-132.5: Warning (unit_address_vs_reg): /soc@0/i2c@58780000/tas5707@1b/port@0: node has a unit name, but no reg or ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: uniphier: ld20-global: use generic node name for audio-codecKrzysztof Kozlowski1-1/+1
Devicetree specification expects node names to be generic, representing the class of devices. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: uniphier: ld11-global: drop audio codec port unit addressKrzysztof Kozlowski1-1/+1
Audio codec port does not have "reg", thus it should not have unit address, as reported by dtc W=1 warning: uniphier-ld11-global.dts:127.10-132.5: Warning (unit_address_vs_reg): /soc@0/i2c@58780000/tas5707a@1d/port@0: node has a unit name, but no reg or ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: uniphier: ld11-global: use generic node name for audio-codecKrzysztof Kozlowski1-1/+1
Devicetree specification expects node names to be generic, representing the class of devices. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: sharkl3: add missing unit addressesKrzysztof Kozlowski1-9/+9
Nodes with "reg" property are supposed to have unit address, as reported by dtc W=1 warning: sharkl3.dtsi:42.23-48.6: Warning (unit_address_vs_reg): /soc/syscon@402b0000/pmu-gate: node has a reg or ranges property, but no unit name sharkl3.dtsi:59.29-63.6: Warning (unit_address_vs_reg): /soc/syscon@402e0000/aonapb-gate: node has a reg or ranges property, but no unit name sharkl3.dtsi:74.13-80.6: Warning (unit_address_vs_reg): /soc/syscon@40353000/pll: node has a reg or ranges property, but no unit name sharkl3.dtsi:91.15-95.6: Warning (unit_address_vs_reg): /soc/syscon@40359000/mpll: node has a reg or ranges property, but no unit name sharkl3.dtsi:106.15-112.6: Warning (unit_address_vs_reg): /soc/syscon@4035c000/rpll: node has a reg or ranges property, but no unit name sharkl3.dtsi:123.15-127.6: Warning (unit_address_vs_reg): /soc/syscon@40363000/dpll: node has a reg or ranges property, but no unit name sharkl3.dtsi:138.21-142.6: Warning (unit_address_vs_reg): /soc/syscon@60800000/mm-gate: node has a reg or ranges property, but no unit name sharkl3.dtsi:153.27-159.6: Warning (unit_address_vs_reg): /soc/syscon@71300000/apapb-gate: node has a reg or ranges property, but no unit name Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: whale2: add missing ap-apb unit addressKrzysztof Kozlowski1-1/+1
Nodes with "reg" property are supposed to have unit address, as reported by dtc W=1 warning: whale2.dtsi:67.10-116.5: Warning (simple_bus_reg): /soc/ap-apb: simple-bus unit address format error, expected "70000000" Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: sc9860: move GIC to soc nodeKrzysztof Kozlowski1-12/+12
All devices on MMIO bus should be within the "soc" node. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-04-24arm64: dts: sc9860: move GPIO keys to boardKrzysztof Kozlowski2-28/+28
GPIO keys are properties of a board, not SoC, because SoC physically does not have any keys or buttons. This also fixes dtc W=1 build warning: sc9860.dtsi:688.13-714.5: Warning (simple_bus_reg): /soc/gpio-keys: missing or empty reg/ranges property Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.