- 17 Nov, 2020 9 commits
-
-
Álvaro Fernández Rojas authored
BCM6328 SoCs have a reset controller for certain components. Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
Álvaro Fernández Rojas authored
Add support for resetting blocks through the Linux reset controller subsystem for BCM63xx SoCs. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Álvaro Fernández Rojas authored
Add device tree binding documentation for BCM6345 reset controller. Signed-off-by:
-
Álvaro Fernández Rojas authored
This allows to add reset controllers support. Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
1.Refresh defconfig of CI20 to support OTG and RNG. 2.Refresh defconfig of CU1000-Neo to support OTG/RNG/OST/SC16IS752. 3.Refresh defconfig of CU1830-Neo to support OTG/DTRNG/OST/SC16IS752. Tested-by:
周正 (Zhou Zheng) <sernia.zhou@foxmail.com> Tested by: H. Nikolaus Schaller <hns@goldelico.com> # CI20/jz4780 Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20. 2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1000-Neo. 3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1830-Neo. Tested-by:
-
Thomas Bogendoerfer authored
Pull in mips-fixes to get memblock fix. - fix bug preventing booting on several platforms - fix for build error, when modules need has_transparent_hugepage - fix for memleak in alchemy clk setup Signed-off-by: -
Zhang Qilong authored
If the clk_register fails, we should free h before function returns to prevent memleak. Fixes: 47440229 ("MIPS: Alchemy: clock framework integration of onchip clocks") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
-
Thomas Bogendoerfer authored
The loop over all memblocks works with PFNs and not physical addresses, so we need for_each_mem_pfn_range(). Fixes: b10d6bca ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Reviewed-by:
Serge Semin <fancer.lancer@gmail.com>
-
- 12 Nov, 2020 16 commits
-
-
Alexander Lobakin authored
Commit c3e2ee65 ("MIPS: generic: Add support for zboot") added support for self-extracting images to Generic MIPS. However, the intended way to boot Generic MIPS kernels is using FIT Images and UHI boot protocol, but currently there's no way to make self-extracting FIT Image (only legacy uzImages). Add a target for this named "vmlinuz.itb", which will consist of vmlinuz.bin and selected DT blobs. It will allow to have the advantages of both UHI and self-extracting images. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Acked-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Alexander Lobakin authored
1. All final targets like vmlinuz.{bin,ecoff,srec} etc. should reside in $(objtree)/arch/mips/boot, not in the root $(objtree) directory. The only file that should be left there is vmlinuz, similar to other architectures. 2. Add all the targets to $(targets) variable, so they'll be properly accounted by Kbuild. This also allows to remove redundant $(clean-files) (which were missing uzImage BTW). 3. Prefix all targets with $(obj)/$(objtree), depending on their locations. Misc: fix the identation of the 'STRIP' quiet message. Signed-off-by: -
Gregory CLEMENT authored
Add a device trees and FIT image support for the Microsemi Serval SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Gregory CLEMENT authored
Add a device trees and FIT image support for the Microsemi Jaguar2 SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Luton now has already an u-boot port so let's build FIT images. Signed-off-by:
-
Gregory CLEMENT authored
Add a device tree for the Microsemi Luton PCB091 evaluation board. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Add a device tree include file for the Microsemi Luton SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Ocelots is supported by the generic MIPS build so make it clears that LEGACY_BOARD_OCELOT is only needed for legacy boards which didn't have bootloader supporting device tree. Signed-off-by:
-
Gregory CLEMENT authored
Ocelot belongs to a family of SoC named the VCore III. In order to add these new Soc, use the new symbol SOC_VCOREIII instead of a one dedicated to Ocelot. In order to avoid regression on driver building, the MSCC_OCELOT configuration symbol is kept until the driver will be converted. Signed-off-by:
-
Gregory CLEMENT authored
Serval and Jaguar2 SoCs belong to the same family as Ocelot and Luton. Acked-by:
-
Gregory CLEMENT authored
Luton SoC belongs to the same family as Ocelot. Acked-by:
-
Necip Fazil Yildiran authored
When BCM47XX_BCMA is enabled and BCMA_DRIVER_PCI is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for BCMA_DRIVER_PCI_HOSTMODE Depends on [n]: MIPS [=y] && BCMA_DRIVER_PCI [=n] && PCI_DRIVERS_LEGACY [=y] && BCMA [=y]=y Selected by [y]: - BCM47XX_BCMA [=y] && BCM47XX [=y] && PCI [=y] The reason is that BCM47XX_BCMA selects BCMA_DRIVER_PCI_HOSTMODE without depending on or selecting BCMA_DRIVER_PCI while BCMA_DRIVER_PCI_HOSTMODE depends on BCMA_DRIVER_PCI. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: c1d1c5d4 ("bcm47xx: add support for bcma bus") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209879Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Signed-off-by:
-
Necip Fazil Yildiran authored
When BCM47XX_SSB is enabled and SSB_PCIHOST is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SSB_B43_PCI_BRIDGE Depends on [n]: SSB [=y] && SSB_PCIHOST [=n] Selected by [y]: - BCM47XX_SSB [=y] && BCM47XX [=y] && PCI [=y] The reason is that BCM47XX_SSB selects SSB_B43_PCI_BRIDGE without depending on or selecting SSB_PCIHOST while SSB_B43_PCI_BRIDGE depends on SSB_PCIHOST. This can also fail building the kernel as demonstrated in a bug report. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210051Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
-
- 11 Nov, 2020 7 commits
-
-
Tiezhu Yang authored
In play_dead function, the whole 64-bit PC mailbox was used as a indicator to determine if the master core had written boot jump information. However, after we introduced CSR mailsend, the hardware will not guarante an atomic write for the 64-bit PC mailbox. Thus we have to use the lower 32-bit which is written at the last as the jump indicator instead. Signed-off-by:
Lu Zeng <zenglu@loongson.cn> Signed-off-by:
Jun Yi <yijun@loongson.cn> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
Loongson 3A4000+ CPU has per-core Mail_Send register to send mail, there is no need to maintain register address of each core and node, just simply specify cpu number. Signed-off-by:
Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
In the current code, for example, core 1 sets Core[0, 1, 2, 3]_IPI_Enalbe register and core 2, 3 do the same thing on the 1-way Loongson64 platform, this is not necessary. Set IPI_Enable register per core by itself to avoid duplicate operations and make the logic more clear. Signed-off-by:
-
Tiezhu Yang authored
The field ELPA of CP0_PAGEGRAIN register is set at the beginning of the kernel entry point in kernel-entry-init.h, no need to set it again in numa.c, we can remove enable_lpa() and only print the related information. Signed-off-by:
-
Tiezhu Yang authored
The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the write operations are meaningless, remove them. Signed-off-by:
-
Nick Desaulniers authored
Remove a tautology; since commit 0bddd227 ("Documentation: update for gcc 4.9 requirement") which raised the minimally supported version of GCC to 4.9, this case is always true. Link: https://github.com/ClangBuiltLinux/linux/issues/427Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Geert Uytterhoeven authored
Everything in arch/mips/include/uapi/asm/types.h is protected by "#ifndef __KERNEL__", so it's unused for kernelspace. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 06 Nov, 2020 5 commits
-
-
Qinglang Miao authored
add missing iounmap() of pciu_base on error when failed to init io_map_base. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Qinglang Miao authored
Add the missing iounmap() of iounmap(mips_gcr_base) before return from mips_cm_probe() in the error handling case. Signed-off-by:
-
Qinglang Miao authored
Add the missing iounmap() of gpch->regs before return from ar7_gpio_init() in the error handling case. Signed-off-by:
-
Colin Ian King authored
There are a few spelling mistakes in the Kconfig, fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
-
Chuanhong Guo authored
This will make a separated section for dtb appear in ELF, and we can then use objcopy to patch a dtb into vmlinuz when RAW_APPENDED_DTB is set in kernel config. command to patch a dtb: objcopy --set-section-flags=.appended_dtb=alloc,contents \ --update-section=.appended_dtb=<target>.dtb vmlinuz Signed-off-by:Chuanhong Guo <gch981213@gmail.com> Signed-off-by:
-
- 27 Oct, 2020 3 commits
-
-
Sam Ravnborg authored
There are no users of this headers file in the kernel. All users are likely migrated to device tree which is a good thing. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Harvey Hunt <harveyhuntnexus@gmail.com> Cc: linux-mips@vger.kernel.org Reviewed-by:
-
Tiezhu Yang authored
Add a description for /sys/firmware/lefi/boardinfo on the Loongson platform. Signed-off-by:
-
Tiezhu Yang authored
Add /sys/firmware/lefi/boardinfo to get mainboard and BIOS info easily on the Loongson platform, this is useful to point out the current used mainboard type and BIOS version when there exists problems related with hardware or firmware. The related structures are already defined in the interface specification about firmware and kernel which are common requirement and specific for Loongson64, so only add a new boardinfo.c file in arch/mips/loongson64. E.g. with this patch: [loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo Board Info Manufacturer : LEMOTE Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc Family : LOONGSON3 BIOS Info Vendor : Kunlun Version : Kunlun-A1901-V4.1.3-20200414093938 ROM Size : 4 KB Release Date : 2020-04-14 By the way, using dmidecode command can get the similar info if there exists SMBIOS in firmware, but the fact is that there is no SMBIOS on some machines, we can see nothing when execute dmidecode, like this: [root@linux loongson]# dmidecode # dmidecode 2.12 # No SMBIOS nor DMI entry point found, sorry. Signed-off-by:
-
