IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
An $ARCH or a platform should select PM. Single device drivers
should only depend on PM, not select it.
Having SUN20I_PPU depend on PM removes a kconfig warning:
WARNING: unmet direct dependencies detected for PM
Depends on [n]: !MMU [=y]
Selected by [y]:
- SUN20I_PPU [=y] && (ARCH_SUNXI || COMPILE_TEST [=y])
Fixes: 0ad2185dcb5e ("soc: sunxi: select CONFIG_PM")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Samuel Holland <samuel@sholland.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-sunxi@lists.linux.dev
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Selecting CONFIG_PM_GENERIC_DOMAINS without CONFIG_PM leads to a
build failure:
WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS
Depends on [n]: PM [=n]
Selected by [y]:
- SUN20I_PPU [=y] && (ARCH_SUNXI [=n] || COMPILE_TEST [=y])
drivers/base/power/domain_governor.c: In function 'default_suspend_ok':
drivers/base/power/domain_governor.c:85:24: error: 'struct dev_pm_info' has no member named 'ignore_children'
85 | if (!dev->power.ignore_children)
| ^
drivers/base/power/domain.c: In function 'genpd_queue_power_off_work':
drivers/base/power/domain.c:657:20: error: 'pm_wq' undeclared (first use in this function)
657 | queue_work(pm_wq, &genpd->power_off_work);
| ^~~~~
Unfortunately platforms are inconsistent between using 'select PM'
and 'depends on PM' here. CONFIG_PM is a user-visible symbol, so
in principle we should be using 'depends on', but on the other hand
using 'select' here is more common among drivers/soc. Go with the
majority for now, as this has a smaller risk of introducing circular
dependencies. We may need to clean this up for consistency later.
Fixes: 0e30ca5ab0a8 ("soc: sunxi: Add Allwinner D1 PPU driver")
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The PPU contains a series of identical MMIO register ranges, one for
each power domain. Each range contains control/status bits for a clock
gate, reset line, output gates, and a power switch. (The clock and reset
are separate from, and in addition to, the bits in the CCU.) It also
contains a hardware power sequence engine to control the other bits.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20230126063419.15971-3-samuel@sholland.org
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
This driver exists as a workaround for old devicetrees which are missing
interconnects properties, so it is only useful for those specific
platforms, which all happen to be ARM or ARM64.
This solves the issue that the driver fails to build on RISC-V, where
PHYS_OFFSET is not defined.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20220702032520.22129-1-samuel@sholland.org
So far most of the drivers with the MBUS quirks had to duplicate the
code to deal with DT compatibility and enforcing the DMA offsets.
Let's move for a more maintainable solution by putting everything in a
notifier that would take care of setting up the DMA offsets for all the
MBUS devices.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but
not REGMAP_MMIO, so the kernel fails to link with an undefined reference
to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in
drivers/base/regmap/Kconfig.
This creates the following dependency loop:
drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
drivers/base/regmap/Kconfig:7: symbol REGMAP default is visible depending on REGMAP_MMIO
drivers/base/regmap/Kconfig:39: symbol REGMAP_MMIO is selected by SUNXI_SRAM
drivers/soc/sunxi/Kconfig:4: symbol SUNXI_SRAM is selected by USB_MUSB_SUNXI
drivers/usb/musb/Kconfig:63: symbol USB_MUSB_SUNXI depends on GENERIC_PHY
drivers/phy/Kconfig:7: symbol GENERIC_PHY is selected by PHY_BCM_NS_USB3
drivers/phy/broadcom/Kconfig:29: symbol PHY_BCM_NS_USB3 depends on MDIO_BUS
drivers/net/phy/Kconfig:12: symbol MDIO_BUS default is visible depending on PHYLIB
drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected by ARC_EMAC
drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
To fix the circular dependency, make USB_MUSB_SUNXI select GENERIC_PHY
instead of depending on it. This matches the use of GENERIC_PHY by all
but two other drivers.
Cc: <stable@vger.kernel.org> # 4.19
Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.
That mapping is controlled by an SRAM controller, and that mapping might
not be set by the bootloader, for example if the device wasn't used at all,
or if we're using solutions like the U-Boot's Falcon Boot.
We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory
rate change, if that ever happens.
These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.
This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some
drivers in the kernel.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
