- 23 Jun, 2023 1 commit
-
-
Nathan Chancellor authored
Clang warns: drivers/clk/ralink/clk-mtmips.c:309:9: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] 309 | return ret; | ^~~ drivers/clk/ralink/clk-mtmips.c:285:9: note: initialize the variable 'ret' to silence this warning 285 | int ret, i; | ^ | = 0 drivers/clk/ralink/clk-mtmips.c:359:9: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] 359 | return ret; | ^~~ drivers/clk/ralink/clk-mtmips.c:335:9: note: initialize the variable 'ret' to silence this warning 335 | int ret, i; | ^ | = 0 2 errors generated. Set ret to the return value of clk_hw_register_fixed_rate() using the PTR_ERR() macro, which ensures ret is not used uninitialized, clearing up the warning. Fixes: 6f3b1558 ("clk: ralink: add clock and reset driver for MTMIPS SoCs") Closes: https://github.com/ClangBuiltLinux/linux/issues/1879Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Acked-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- 21 Jun, 2023 12 commits
-
-
Shiji Yang authored
The ralink_of_remap() function is repeated several times on SoC specific source files. They have the same structure, but just differ in compatible strings. In order to make commonly use of these codes, this patch introduces a newly designed mtmips_of_remap_node() function to match and remap all supported system controller and memory controller nodes. Build and run tested on MT7620 and MT7628. Signed-off-by:
Shiji Yang <yangshiji66@outlook.com> Reviewed-by:
-
Shiji Yang authored
Usually, We only need to print the error log when there is a PCIe card but initialization fails. Whether the driver finds the PCIe card or not is the expected behavior. So it's better to log these information with dev_info(). Tested on MT7628AN router Motorola MWR03. Signed-off-by:
-
Shiji Yang authored
These codes are used to read NFTS_TIMEOUT_DELAY register value and write it into kernel log after writing the register. they are only used for debugging during driver development, so there is no need to keep them now. Tested on MT7628AN router Motorola MWR03. Signed-off-by:
-
Sergio Paracuellos authored
Adding myself as maintainer for Mediatek MTMIPS clock driver. Signed-off-by:
-
Sergio Paracuellos authored
At very early stage on boot, there is a need to set 'mips_hpt_frequency'. This timer frequency is a half of the CPU frequency. To get clocks properly set we need to call to 'of_clk_init()' and properly get cpu clock frequency afterwards. Depending on the SoC, CPU clock index and compatible differs, so use them to get the proper clock frm the clock provider. Hence, adapt code to be aligned with new clock driver. Signed-off-by:
-
Sergio Paracuellos authored
A proper clock driver for ralink SoCs has been added. This driver is also a reset provider for the SoC. Hence there is no need to have reset related code in 'arch/mips/ralink' folder anymore. The only code that remains is the one related with mips_reboot_setup where a PCI reset is performed. We maintain this because I cannot test old ralink board with PCI to be sure all works if we remove also this code. Signed-off-by:
-
Sergio Paracuellos authored
A proper clock driver for ralink SoCs has been added. Hence there is no need to have clock related code in 'arch/mips/ralink' folder anymore. Since this is the last clock related code removal, remove also remaining prototypes in 'common.h' header file. Signed-off-by:
-
Sergio Paracuellos authored
A properly clock driver for ralink SoCs has been added. Hence there is no need to have clock related code in 'arch/mips/ralink' folder anymore. Signed-off-by:
-
Sergio Paracuellos authored
A properly clock driver for ralink SoCs has been added. Hence there is no need to have clock related code in 'arch/mips/ralink' folder anymore. Signed-off-by:
-
Sergio Paracuellos authored
A properly clock driver for ralink SoCs has been added. Hence there is no need to have clock related code in 'arch/mips/ralink' folder anymore. Signed-off-by:
-
Sergio Paracuellos authored
Until now, clock related code for old ralink SoCs was based in fixed clocks using 'clk_register_fixed_rate' and 'clkdev_create' directly doing in code and not using device tree at all for their definition. Including this driver is an effort to be able to define proper clocks using device tree and also cleaning all the clock and reset related code from 'arch/mips/ralink' dir. This clock and reset driver covers all the ralink SoCs but MT7621 which is the newest and provides gating and some differences that make it different from its predecesors. It has its own driver since some time ago. The ralink SoCs we are taking about are RT2880, RT3050, RT3052, RT3350, RT3352, RT3883, RT5350, MT7620, MT7628 and MT7688. Mostly the code in this new driver has been extracted from 'arch/mips/ralink' and cleanly put using kernel clock driver APIs. The clock plans for this SoCs only talks about relation between CPU frequency and BUS frequency. This relation is different depending on the particular SoC. CPU clock is derived from XTAL frequencies. Depending on the SoC we have the following frequencies: * RT2880 SoC: - XTAL: 40 MHz. - CPU: 250, 266, 280 or 300 MHz. - BUS: CPU / 2 MHz. * RT3050, RT3052, RT3350: - XTAL: 40 MHz. - CPU: 320 or 384 MHz. - BUS: CPU / 3 MHz. * RT3352: - XTAL: 40 MHz. - CPU: 384 or 400 MHz. - BUS: CPU / 3 MHz. - PERIPH: 40 MHz. * RT3383: - XTAL: 40 MHz. - CPU: 250, 384, 480 or 500 MHz. - BUS: Depends on RAM Type and CPU: + RAM DDR2: 125. ELSE 83 MHz. + RAM DDR2: 128. ELSE 96 MHz. + RAM DDR2: 160. ELSE 120 MHz. + RAM DDR2: 166. ELSE 125 MHz. * RT5350: - XTAL: 40 MHz. - CPU: 300, 320 or 360 MHz. - BUS: CPU / 3, CPU / 4, CPU / 3 MHz. - PERIPH: 40 MHz. * MT7628 and MT7688: - XTAL: 20 MHz or 40 MHz. - CPU: 575 or 580 MHz. - BUS: CPU / 3. - PCMI2S: 480 MHz. - PERIPH: 40 MHz. * MT7620: - XTAL: 20 MHz or 40 MHz. - PLL: XTAL, 480, 600 MHz. - CPU: depends on PLL and some mult and dividers. - BUS: depends on PLL and some mult and dividers. - PERIPH: 40 or XTAL MHz. MT7620 is a bit more complex deriving CPU clock from a PLL and an bunch of register reads and predividers. To derive CPU and BUS frequencies in the MT7620 SoC 'mt7620_calc_rate()' helper is used. In the case XTAL can have different frequencies and we need a different clock frequency for peripherals 'periph' clock in introduced. The rest of the peripherals present in the SoC just follow their parent frequencies. With this information the clk driver will provide all the clock and reset functionality from a set of hardcoded clocks allowing to define a nice device tree without fixed clocks. Acked-by:Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Sergio Paracuellos authored
Adds device tree binding documentation for system controller node present in Mediatek MIPS and Ralink SOCs. This node is a clock and reset provider for the rest of the world. This covers RT2880, RT3050, RT3052, RT3350, RT3883, RT5350, MT7620, MT7628 and MT7688 SoCs. Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
-
- 20 Jun, 2023 5 commits
-
-
Yu Zhao authored
Aleksandar Markovic was last seen in Oct 2020 [1] and cannot be reached for multiple days because of "Recipient inbox full". [1] https://lore.kernel.org/all/1602103041-32017-4-git-send-email-aleksandar.qemu.devel@gmail.com/Signed-off-by:
Yu Zhao <yuzhao@google.com> Acked-by:
Huacai Chen <chenhuacai@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. While destroying alignment of the assignments in bridge_driver, do it consistently and use a single space before =. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Sui Jingfeng authored
As it's usuable on LS3A4000 platform. Tested with RX550, glmark2 got about 4235 score. Signed-off-by:
Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by:
-
Nathan Chancellor authored
After commit 96cb8ae2 ("MIPS: Rework smt cmdline parameters"), modpost complains when building with clang: WARNING: modpost: vmlinux.o: section mismatch in reference: core_vpe_count (section: .text) -> smp_max_threads (section: .init.data) This warning occurs when core_vpe_count() is not inlined, as it appears that a non-init function is referring to an init symbol. However, this is not a problem in practice because core_vpe_count() is only called from __init functions, cps_smp_setup() and cps_prepare_cpus(). Resolve the warning by marking core_vpe_count() as __init, as it is only called in an init context so it can refer to init functions and symbols and have its memory freed on boot. Fixes: 96cb8ae2 ("MIPS: Rework smt cmdline parameters") Signed-off-by:
-
Thomas Bogendoerfer authored
Macro cpu_has_mips_r2_exec_hazard correctly handles OCTEON CPUs, so we don't need the extra switch cases for them. Signed-off-by:
-
- 09 Jun, 2023 22 commits
-
-
Tony Lindgren authored
We want to unify the pinctrl-single pin group nodes to use naming "pins". Otherwise non-standad pin group names will add make dtbs checks errors when the pinctrl-single yaml binding gets merged. Cc: Conor Dooley <conor+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Jiaxun Yang authored
hlt,nohlt paramaters are useful when debugging cpuidle related issues. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
-
Jiaxun Yang authored
Provide a generic smt parameters interface aligned with s390 to allow users to limit smt usage and threads per core. It replaced previous undocumented "nothreads" parameter for smp-cps which is ambiguous and does not cover smp-mt. Signed-off-by:
-
Arnd Bergmann authored
Building with -Werror and W=1 fails entirely because of warnings in asm-offsets.c: arch/mips/kernel/asm-offsets.c:26:6: error: no previous prototype for 'output_ptreg_defines' [-Werror=missing-prototypes] arch/mips/kernel/asm-offsets.c:78:6: error: no previous prototype for 'output_task_defines' [-Werror=missing-prototypes] arch/mips/kernel/asm-offsets.c:92:6: error: no previous prototype for 'output_thread_info_defines' [-Werror=missing-prototypes] arch/mips/kernel/asm-offsets.c:108:6: error: no previous prototype for 'output_thread_defines' [-Werror=missing-prototypes] arch/mips/kernel/asm-offsets.c:136:6: error: no previous prototype for 'output_thread_fpu_defines' [-Werror=missing-prototypes] Nothing actually calls these functions, so just add prototypes to shut up the warnings. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jiaxun Yang authored
Some CPU feature macros were using current_cpu_type to mark feature availability. However current_cpu_type will use smp_processor_id, which is prohibited under preemptable context. Since those features are all uniform on all CPUs in a SMP system, use boot_cpu_type instead of current_cpu_type to fix preemptable kernel. Cc: stable@vger.kernel.org Signed-off-by:
-
Liviu Dudau authored
This WiFi AP is based on a MT7621 SoC with 128MiB RAM, 128MiB NAND, a MT7603 2.4GHz WiFi and a MT7613 5GHz WiFi chips integrated on the board, connected to the main SoC over PCIe. The device uses NMBM over NAND, which is not currently supported in the mainline, so NAND node is skipped in this revision. Signed-off-by:
Liviu Dudau <liviu@dudau.co.uk> Reviewed-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by:
-
Liviu Dudau authored
Add bindings for the compatible string used for the TP-Link's HC220 G5 V1 board, a wireless AP based on MT7621. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Acked-by:
-
Paul Cercueil authored
Enable the required drivers for the WiFi / Bluetooth functionality. I enabled WEXT compatibility as well since the CI20 is typically used with a very old userspace. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Paul Cercueil authored
Just a "make ci20_defconfig menuconfig savedefconfig" Without changing anything in the menuconfig. No functional change. Signed-off-by:
-
Paul Cercueil authored
Wire the WiFi/Bluetooth chip properly in the Device Tree. - Provide it with the correct regulators and clocks; - Change the MMC I/O bus to 1.8V which seems to be enough; - Change the MMC I/O bus frequency to 25 MHz as 50 MHz causes errors; - Fix the Bluetooth powerdown GPIO being inverted and add reset GPIO; - Convert host-wakeup-gpios to IRQ. With these changes, the WiFi works properly with the latest firmware provided by linux-firmware. The Bluetooth does not work very well here, as I cannot get my wireless keyboard to pair; but it does detect it, and it does see the key presses when I type the pairing code. Signed-off-by:
-
Paul Cercueil authored
This makes it possible to clock the SD cards much higher, as the MPLL is running at 1.2 GHz by default. The previous parent was the EXT clock, which caused the SD cards to be clocked at 24 MHz maximum. Signed-off-by:
-
Paul Cercueil authored
- Use the standard "ecc-engine" property instead of the custom "ingenic,bch-controller" to get a handle to the BCH controller. - Respect cell sizes in the Ethernet controller node. - Use proper macro for interrupt type instead of hardcoding magic values. Signed-off-by:
-
Paul Cercueil authored
These regulators should be enabled by their respective drivers. Signed-off-by:
-
Paul Cercueil authored
Provide parent regulators to the ACT8600 regulators that need one. Signed-off-by:
-
Paul Cercueil authored
The Device Tree was using invalid node names for the ACT8600 regulators. To be fair, it is not the original committer's fault, as the documentation did gives invalid names as well. In theory, the fix should have been to modify the driver to accept the alternative names. However, even though the act8865 driver spits warnings, the kernel seemed to work fine with what is currently supported upstream. For that reason, I think it is okay to just update the DTS. I removed the "regulator-name" too, since they really didn't bring any information. The node names are enough. Fixes: 73f2b940 ("MIPS: CI20: DTS: Add I2C nodes") Signed-off-by:
-
Paul Cercueil authored
The regulators don't have any "reg" property, and therefore shouldn't use an unit address in their node names. They also don't need to specify the GPIO_ACTIVE_LOW flag, which will be ignored anyway, as they are active-high. Signed-off-by:
-
Paul Cercueil authored
The regulators don't have any "reg" property, and therefore shouldn't use an unit address in their node names. Signed-off-by:
-
Paul Cercueil authored
The JZ4750, JZ4755 and JZ4760 (non-B version) support using a 24 MHz external crystal oscillator instead of the typical 12 MHz one. However, most of the SoC's IP blocks only work with a 12 MHz clock. Thanksfully, there is a /2 divider we can enable when a 24 MHz external crystal is present. Force-enable this /2 divider when the oscillator is 24 MHz, so that the SoC always uses a 12 MHz clock internally. It is done here, and not in the clocks driver, because we need the EXT clock to be 12 MHz for the early console to work, and the clocks driver probes way too late. Signed-off-by:
-
Paul Cercueil authored
These flags are useless in this case as the code referencing these data structures is always seen by the compiler (and not behind #ifdef guards). Signed-off-by:
-
Siarhei Volkau authored
The LXW, LXH, LXHU opcodes are part of the MXU ASE found in Ingenic XBurst based SoCs. While technically part of the MXU ASE, they do not touch any of the SIMD registers, and can be used even when the MXU ASE is disabled. This patch makes it possible to emulate unaligned access for those instructions. Signed-off-by:
Siarhei Volkau <lis8215@gmail.com> Signed-off-by:
-
Maciej W. Rozycki authored
Revert commit 75b18aac ("MIPS: unhide PATA_PLATFORM") now that HAVE_PATA_PLATFORM is set selectively for all the relevant platforms. Verified with `db1xxx_defconfig' and `sb1250_swarm_defconfig' by making sure PATA_PLATFORM is still there in `.config' with this change applied, and with `malta_defconfig' by making sure it's now gone. Signed-off-by:
Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by:
-
Maciej W. Rozycki authored
We have limited demand for platform PATA support across MIPS platforms: $ find arch/mips -type f | sort | xargs grep -l pata_platform_info arch/mips/alchemy/devboards/db1200.c arch/mips/alchemy/devboards/db1300.c arch/mips/sibyte/swarm/platform.c $ certainly not high enough to justify enabling support for PATA_PLATFORM port-wide. SiByte platforms are handled selectively already, so just make a similar arrangement for Alchemy DB1XXX platforms. Signed-off-by:
-
