linux-dev/arch/arm/mach-mmp, branch master

ARM: mmp: Make some symbols static

2022-10-10T08:40:10Z

These symbols pxa168_usb_phy_resources, pxa168_u2o_resources, pxa168_u2oehci_resources and pxa168_u2ootg_resources are not used outside of arch/arm/mach-mmp/devices.c, so mark them static. Fixes the following sparse warning: arch/arm/mach-mmp/devices.c:241:17: warning: symbol 'pxa168_usb_phy_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:262:17: warning: symbol 'pxa168_u2o_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:297:17: warning: symbol 'pxa168_u2oehci_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:324:17: warning: symbol 'pxa168_u2ootg_resources' was not declared. Should it be static? Reported-by: kernel test robot Signed-off-by: Chen Lifu Signed-off-by: Arnd Bergmann

Merge tag 'arm-boardfiles-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2022-08-02T15:35:17Z

Pull ARM boardfile deprecation from Arnd Bergmann: "Over the past ten years, new machine support was based on device tree, and an initial set of about 400 boards using ATAGS with boardfile for booting were grandfathered in, with about half of them either removed or converted to DT over time. Based on the recent mailing list discussion I started, I have now turned the findings into a set of patches that marks most board files as 'depends on UNUSED_BOARD_FILES', leaving only 38 of the 196 boards. For the boards that are marked as unused, there are two final chances for potential users: The removal is scheduled to take place after the longterm stable kernel at the end of 2022, so users can stay on that version for another few years, and if anyone still has one of these machines and is planning to keep updating kernels beyond that version, they can speak up now to have their boards taken off the list again. Waiting for the LTS release also makes sure that there will be at least one longterm kernel that contains the recent multiplatform conversion along while still supporting all legacy boards. The short summary of the current status is: - The s3c24xx, cns3xxx, iop32x and mv78xx0 platforms have no known users and will be removed entirely. - The mmp and davinci platforms have DT support for the important machines and will become DT-only after this. - s3c64xx, dove, orion5x, and pxa keep some board files to allow those to be migrated over to DT more easily, but most board files are getting removed now. DT support on these platforms is partially working but requires changes to additional drivers for the other boards. - omap1, ep93xx, sa1100, footbridge and rpc have no DT support at the moment but have some boards with known users. Removing the board files that nobody uses should make it easier to try a DT conversion if anyone cares. There is no explicit timeline what happens with the boards that remain after this removal, but I expect to revisit this in the future, and with most boards gone, there will be a good time to do a treewide review of platform drivers that never gained DT support and have no remaining in-tree board files" Link: https://lore.kernel.org/linux-arm-kernel/CAK8P3a0Z9vGEQbVRBo84bSyPFM-LF+hs5w8ZA51g2Z+NsdtDQA@mail.gmail.com/ * tag 'arm-boardfiles-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: cns3xxx: add CONFIG_UNUSED_BOARD_FILES dependency ARM: iop32x: mark as unused ARM: s3c: mark most board files as unused ARM: omap1: add Kconfig dependencies for unused boards ARM: sa1100: mark most boards as unused ARM: footbridge: mark cats board for removal ARM: mmp: mark all board files for removal ARM: ep93xx: mark most board files as unused ARM: davinci: mark all ATAGS board files as unused ARM: orion: add ATAGS dependencies ARM: pxa: add Kconfig dependencies for ATAGS based boards ARM: add CONFIG_UNUSED_BOARD_FILES ARM: add ATAGS dependencies to non-DT platforms

irqchip/mmp: Declare init functions in common header file

2022-07-25T08:42:24Z

The functions icu_init_irq and mmp2_init_icu are exported from this code, so declare them in the header file to avoid the following sparse warnings: drivers/irqchip/irq-mmp.c:248:13: warning: symbol 'icu_init_irq' was not declared. Should it be static? drivers/irqchip/irq-mmp.c:271:13: warning: symbol 'mmp2_init_icu' was not declared. Should it be static? Signed-off-by: Ben Dooks [maz: fixup commit message] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220724222152.551850-1-ben-linux@fluff.org

ARM: mmp: mark all board files for removal

2022-07-22T11:11:21Z

The mmp platform supports both ATAGS based board files and DT booting, but it appears that nobody has been interested in board files for a long time. Mark all of them for removal in early 2023 with a dependency on CONFIG_UNUSED_BOARD_FILES, leaving only the DT support for the future, unless someone pops up who uses them. Cc: Lubomir Rintel Cc: Haojian Zhuang Signed-off-by: Arnd Bergmann

Merge tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2022-06-02T22:23:54Z

Pull more ARM multiplatform updates from Arnd Bergmann: "The second part of the multiplatform changes now converts the Intel/Marvell PXA platform along with the rest. The patches went through several rebases before the merge window as bugs were found, so they remained separate. This has to touch a lot of drivers, in particular the touchscreen, pcmcia, sound and clk bits, to detach the driver files from the platform and board specific header files" * tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (48 commits) ARM: pxa/mmp: remove traces of plat-pxa ARM: pxa: convert to multiplatform ARM: pxa/sa1100: move I/O space to PCI_IOBASE ARM: pxa: remove support for MTD_XIP ARM: pxa: move mach/*.h to mach-pxa/ ARM: PXA: fix multi-cpu build of xsc3 ARM: pxa: move plat-pxa to drivers/soc/ ARM: mmp: rename pxa_register_device ARM: mmp: remove tavorevb board support ARM: pxa: remove unused mach/bitfield.h ARM: pxa: move clk register definitions to driver ARM: pxa: move smemc register access from clk to platform cpufreq: pxa3: move clk register access to clk driver ARM: pxa: remove get_clk_frequency_khz() ARM: pxa: pcmcia: move smemc configuration back to arch ASoC: pxa: i2s: use normal MMIO accessors ASoC: pxa: ac97: use normal MMIO accessors ASoC: pxa: use pdev resource for FIFO regs Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops Input: wm97xx - switch to using threaded IRQ ...

ARM: pxa/mmp: remove traces of plat-pxa

2022-05-31T14:07:52Z

The missing include directory caused a W=1 warning that can be trivially fixed. I also noticed references in the marvell.rst documentation that can be removed at the same time. Reported-by: kernel test robot Signed-off-by: Arnd Bergmann

ARM: pxa: move plat-pxa to drivers/soc/

2022-05-07T20:56:16Z

There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both of them should ideally not be needed at all, as there are proper subsystems to replace them. OTOH, they are self-contained and can simply be normal SoC drivers, so move them over there to eliminate one more of the plat-* directories. Acked-by: Robert Jarzmik (mach-pxa) Acked-by: Lubomir Rintel (mach-mmp) Signed-off-by: Arnd Bergmann

ARM: mmp: rename pxa_register_device

2022-05-07T20:56:16Z

In a multiplatform kernel that includes both pxa and mmp, we get a link failure from the clash of two pxa_register_device functions. Rename the one in mach-mmp to mmp_register_device, along with with the rename of pxa_device_desc. Acked-by: Lubomir Rintel Signed-off-by: Arnd Bergmann

ARM: mmp: remove tavorevb board support

2022-05-07T20:56:16Z

There are two tavorevb boards in the kernel, one using a PXA930 chip in mach-pxa, and one using the later PXA910 chip in mach-mmp. They use the same board number, which is generally a bad idea, and in a multiplatform kernel, we can end up with funny link errors like this one resulting from two boards gettting controlled by the same Kconfig symbol: arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init': tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1' tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio' tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq' tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init' The mach-pxa TavorEVB seems much more complete than the mach-mmp one that supports only uart, gpio and ethernet. Further, I could find no information about the board on the internet aside from references to the Linux kernel, so I assume this was never available outside of Marvell and can be removed entirely. There is a third board named TavorEVB in the Kconfig description, but this refers to the "TTC_DKB" machine. The two are clearly related, so I change the Kconfig description to just list both names. Cc: Lubomir Rintel Reviewed-by: Lubomir Rintel Signed-off-by: Arnd Bergmann

ARM: rework endianess selection

2022-04-08T15:20:54Z

Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago. The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them. This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx. As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment. For the ARMv6/v7 platforms, there are two ways this could be handled a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point. b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work. Out of these, I picked b) because it seemed slighly more logical to me. Signed-off-by: Arnd Bergmann