* Re: [PATCH v3] PCI: aardvark: Fix PCI_EXP_RTCTL register configuration
From: Thomas Petazzoni @ 2019-09-25 12:08 UTC (permalink / raw)
To: Remi Pommarel
Cc: Ellie Reeves, Lorenzo Pieralisi, linux-pci, linux-kernel,
Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20190614101059.1664-1-repk@triplefau.lt>
On Fri, 14 Jun 2019 12:10:59 +0200
Remi Pommarel <repk@triplefau.lt> wrote:
> PCI_EXP_RTCTL is used to activate PME interrupt only, so writing into it
> should not modify other interrupts' mask. The ISR mask polarity was also
> inverted, when PCI_EXP_RTCTL_PMEIE is set PCIE_MSG_PM_PME_MASK mask bit
> should actually be cleared.
>
> Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space")
> Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Sorry for the long delay, but:
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
I did verify that indeed the polarity of the PME interrupt bit is
different between the standard PCI_EXP_RTCTL register and the
Aardvark-specific ISR0 mask register. And obviously, we shouldn't
clobber other bits of the ISR0 mask register when changing the PME
interrupt enable/disable state.
I did a quick test with a E1000E NIC and it worked fine.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] PCI: aardvark: Use LTSSM state to build link training flag
From: Thomas Petazzoni @ 2019-09-25 12:32 UTC (permalink / raw)
To: Remi Pommarel
Cc: Ellie Reeves, Lorenzo Pieralisi, linux-pci, linux-kernel,
Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20190522213351.21366-3-repk@triplefau.lt>
Hello Remi,
On Wed, 22 May 2019 23:33:51 +0200
Remi Pommarel <repk@triplefau.lt> wrote:
> Aardvark's PCI_EXP_LNKSTA_LT flag in its link status register is not
> implemented and does not reflect the actual link training state (the
> flag is always set to 0). In order to support link re-training feature
> this flag has to be emulated. The Link Training and Status State
> Machine (LTSSM) flag in Aardvark LMI config register could be used as
> a link training indicator. Indeed if the LTSSM is in L0 or upper state
> then link training has completed (see [1]).
>
> Unfortunately because after asking a link retraining it takes a while
> for the LTSSM state to become less than 0x10 (due to L0s to recovery
> state transition delays), LTSSM can still be in L0 while link training
> has not finished yet. So this waits for link to be in recovery or lesser
> state before returning after asking for a link retrain.
>
> [1] "PCI Express Base Specification", REV. 4.0
> PCI Express, February 19 2014, Table 4-14
>
> Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Here as well, sorry for the very long delay, and many thanks for the
great research work, including the arm-trusted-firmware fix. I reviewed
the implementation, and tested on my Armada 3720 DB board with a E1000E
NIC, and it all looks good to me.
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/11] PCI: altera: Use pci_parse_request_of_pci_ranges()
From: Rob Herring @ 2019-09-25 12:33 UTC (permalink / raw)
To: Andrew Murray
Cc: Lorenzo Pieralisi, linux-pci, rfi, Bjorn Helgaas, Ley Foon Tan,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190925102423.GR9720@e119886-lin.cambridge.arm.com>
On Wed, Sep 25, 2019 at 5:24 AM Andrew Murray <andrew.murray@arm.com> wrote:
>
> On Tue, Sep 24, 2019 at 04:46:21PM -0500, Rob Herring wrote:
> > Convert altera host bridge to use the common
> > pci_parse_request_of_pci_ranges().
> >
> > Cc: Ley Foon Tan <lftan@altera.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: rfi@lists.rocketboards.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > @@ -833,9 +800,8 @@ static int altera_pcie_probe(struct platform_device *pdev)
> > return ret;
> > }
> >
> > - INIT_LIST_HEAD(&pcie->resources);
> > -
> > - ret = altera_pcie_parse_request_of_pci_ranges(pcie);
> > + ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
>
> Does it matter that we now map any given IO ranges whereas we didn't
> previously?
>
> As far as I can tell there are no users that pass an IO range, if they
> did then with the existing code the probe would fail and they'd get
> a "I/O range found for %pOF. Please provide an io_base pointer...".
> However with the new code if any IO range was given (which would
> probably represent a misconfiguration), then we'd proceed to map the
> IO range. When that IO is used, who knows what would happen.
Yeah, I'm assuming that the DT doesn't have an IO range if IO is not
supported. IMO, it is not the kernel's job to validate the DT.
> I wonder if there is a better way for a host driver to indicate that
> it doesn't support IO?
We can probably test for this in the schema.
ranges:
items:
minItems: 7
items:
- not: { const: 0x01000000 }
Or "- enum: [ 0x42000000, 0x02000000 ]"
Of course, in theory, the bus, dev, fn fields could be non-zero and we
could use minium/maximum to handle those, but in practice I think they
are rarely used for FDT.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] i2c: at91: Send bus clear command if SCL or SDA is down
From: Codrin Ciubotariu @ 2019-09-25 12:59 UTC (permalink / raw)
To: linux-i2c, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, wsa, ludovic.desroches, Codrin Ciubotariu,
Claudiu.Beznea
After a transfer timeout, some faulty I2C slave devices might hold down
the SCL or the SDA pins. We can generate a bus clear command, hoping that
the slave might release the pins.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
Changes in v2:
- added '.has_clear_cmd' struct member to specify which IPs support the
clear command; for now, only SAMA5D2 supports it;
- added Ludovic's V1 ack since there were no major changes;
drivers/i2c/busses/i2c-at91-core.c | 8 ++++++++
drivers/i2c/busses/i2c-at91-master.c | 21 +++++++++++++++++++++
drivers/i2c/busses/i2c-at91.h | 7 ++++++-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 435c7d7377a3..cb07489e698f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_clear_cmd = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_clear_cmd = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index a3fcc35ffd3b..8082dff77724 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -440,6 +440,7 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
unsigned long time_left;
bool has_unre_flag = dev->pdata->has_unre_flag;
bool has_alt_cmd = dev->pdata->has_alt_cmd;
+ bool has_clear_cmd = dev->pdata->has_clear_cmd;
/*
* WARNING: the TXCOMP bit in the Status Register is NOT a clear on
@@ -599,6 +600,26 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
at91_twi_write(dev, AT91_TWI_CR,
AT91_TWI_THRCLR | AT91_TWI_LOCKCLR);
}
+
+ /*
+ * After timeout, some faulty I2C slave devices might hold SCL/SDA down;
+ * we can send a bus clear command, hoping that the pins will be
+ * released
+ */
+ if (has_clear_cmd && !(dev->transfer_status & AT91_TWI_SDA) ||
+ !(dev->transfer_status & AT91_TWI_SCL)) {
+ dev_dbg(dev->dev,
+ "SDA/SCL are down; sending bus clear command\n");
+ if (dev->use_alt_cmd) {
+ unsigned int acr;
+
+ acr = at91_twi_read(dev, AT91_TWI_ACR);
+ acr &= ~AT91_TWI_ACR_DATAL_MASK;
+ at91_twi_write(dev, AT91_TWI_ACR, acr);
+ }
+ at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_CLEAR);
+ }
+
return ret;
}
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506f6128..0827c28a84db 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -36,6 +36,7 @@
#define AT91_TWI_SVDIS BIT(5) /* Slave Transfer Disable */
#define AT91_TWI_QUICK BIT(6) /* SMBus quick command */
#define AT91_TWI_SWRST BIT(7) /* Software Reset */
+#define AT91_TWI_CLEAR BIT(15) /* Bus clear command */
#define AT91_TWI_ACMEN BIT(16) /* Alternative Command Mode Enable */
#define AT91_TWI_ACMDIS BIT(17) /* Alternative Command Mode Disable */
#define AT91_TWI_THRCLR BIT(24) /* Transmit Holding Register Clear */
@@ -69,6 +70,8 @@
#define AT91_TWI_NACK BIT(8) /* Not Acknowledged */
#define AT91_TWI_EOSACC BIT(11) /* End Of Slave Access */
#define AT91_TWI_LOCK BIT(23) /* TWI Lock due to Frame Errors */
+#define AT91_TWI_SCL BIT(24) /* TWI SCL status */
+#define AT91_TWI_SDA BIT(25) /* TWI SDA status */
#define AT91_TWI_INT_MASK \
(AT91_TWI_TXCOMP | AT91_TWI_RXRDY | AT91_TWI_TXRDY | AT91_TWI_NACK \
@@ -81,7 +84,8 @@
#define AT91_TWI_THR 0x0034 /* Transmit Holding Register */
#define AT91_TWI_ACR 0x0040 /* Alternative Command Register */
-#define AT91_TWI_ACR_DATAL(len) ((len) & 0xff)
+#define AT91_TWI_ACR_DATAL_MASK GENMASK(15, 0)
+#define AT91_TWI_ACR_DATAL(len) ((len) & AT91_TWI_ACR_DATAL_MASK)
#define AT91_TWI_ACR_DIR BIT(8)
#define AT91_TWI_FMR 0x0050 /* FIFO Mode Register */
@@ -108,6 +112,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_clear_cmd;
struct at_dma_slave dma_slave;
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: Allow disabling of the compat vDSO
From: Catalin Marinas @ 2019-09-25 13:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, Thomas Gleixner,
Vincenzo Frascino, Will Deacon
The compat vDSO building requires a cross-compiler than produces AArch32
binaries, defined via CONFIG_CROSS_COMPILE_COMPAT_VDSO or the
CROSS_COMPILE_COMPAT environment variable. If none of these is defined,
building the kernel always prints a warning as there is no way to
deselect the compat vDSO.
Add an arm64 Kconfig entry to allow the deselection of the compat vDSO.
In addition, make it an EXPERT option, default n, until other issues
with the compat vDSO are solved (64-bit only kernel headers included in
user-space vDSO code, CC_IS_CLANG irrelevant to CROSS_COMPILE_COMPAT).
Fixes: bfe801ebe84f ("arm64: vdso: Enable vDSO compat support")
Cc: Will Deacon <will@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
It looks like you can't really win with the current compat vDSO logic.
You either don't have a compat cross-compiler and you get a Makefile
warning or you have one and a get a compiler warning (or failure)
because of the 64-bit kernel headers included in 32-bit user-space code.
"depends on BROKEN" for ARM64_COMPAT_VDSO also work for me instead of
EXPERT. I'll leave it up to Will to decide but I'd like at least this
patch in -rc2 (even better if everything else is fixed before the final
5.4).
Suggestions for future improvements of the compat vDSO handling:
- replace the CROSS_COMPILE_COMPAT prefix with a full COMPATCC; maybe
check that it indeed produces 32-bit code
- check whether COMPATCC is clang or not rather than CC_IS_CLANG, which
only checks the native compiler
- clean up the headers includes; vDSO should not include kernel-only
headers that may even contain code patched at run-time
arch/arm64/Kconfig | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 866e05882799..83a9a78085c6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,7 +110,6 @@ config ARM64
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
select GENERIC_GETTIMEOFDAY
- select GENERIC_COMPAT_VDSO if (!CPU_BIG_ENDIAN && COMPAT)
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_PCI
@@ -1185,6 +1184,15 @@ config KUSER_HELPERS
Say N here only if you are absolutely certain that you do not
need these helpers; otherwise, the safe option is to say Y.
+config ARM64_COMPAT_VDSO
+ bool "Enable the 32-bit vDSO" if EXPERT
+ depends on !CPU_BIG_ENDIAN
+ select GENERIC_COMPAT_VDSO
+ help
+ Enable the vDSO support for 32-bit applications. You would
+ need to set the 32-bit cross-compiler prefix in
+ CONFIG_CROSS_COMPILE_COMPAT_VDSO or the CROSS_COMPILE_COMPAT
+ environment variable.
menuconfig ARMV8_DEPRECATED
bool "Emulate deprecated/obsolete ARMv8 instructions"
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] clk: meson: a1: add support for Amlogic A1 clock driver
From: Stephen Boyd @ 2019-09-25 13:12 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu, Neil Armstrong
Cc: Rob Herring, Jianxin Pan, devicetree, Martin Blumenstingl,
Kevin Hilman, Michael Turquette, linux-kernel, Jian Hu,
Qiufang Dai, linux-amlogic, linux-clk, linux-arm-kernel
In-Reply-To: <1569411888-98116-3-git-send-email-jian.hu@amlogic.com>
Quoting Jian Hu (2019-09-25 04:44:48)
> The Amlogic A1 clock includes three parts:
> peripheral clocks, pll clocks, CPU clocks.
> sys pll and CPU clocks will be sent in next patch.
>
> Unlike the previous series, there is no EE/AO domain
> in A1 CLK controllers.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
This second name didn't send the patch. Please follow the signoff
procedures documented in Documentation/process/submitting-patches.rst
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 16d7614..a48f67d 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -138,6 +138,7 @@ config ARCH_MESON
> select COMMON_CLK_AXG
> select COMMON_CLK_G12A
> select MESON_IRQ_GPIO
> + select COMMON_CLK_A1
Sort?
> help
> This enables support for the arm64 based Amlogic SoCs
> such as the s905, S905X/D, S912, A113X/D or S905X/D2
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index dabeb43..e6cb4c3 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -107,3 +107,13 @@ config COMMON_CLK_G12A
> help
> Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
> devices, aka g12a. Say Y if you want peripherals to work.
> +
> +config COMMON_CLK_A1
Probably should be placed somewhere alphabetically in this file?
> + bool
> + depends on ARCH_MESON
> + select COMMON_CLK_MESON_REGMAP
> + select COMMON_CLK_MESON_DUALDIV
> + select COMMON_CLK_MESON_PLL
> + help
> + Support for the clock controller on Amlogic A113L device,
> + aka a1. Say Y if you want peripherals to work.
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 3939f21..6be3a8f 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
> obj-$(CONFIG_COMMON_CLK_G12A) += g12a.o g12a-aoclk.o
> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
> +obj-$(CONFIG_COMMON_CLK_A1) += a1.o
I would guess this should be sorted on Kconfig name in this file?
> diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
> new file mode 100644
> index 0000000..26edae0f
> --- /dev/null
> +++ b/drivers/clk/meson/a1.c
> @@ -0,0 +1,2617 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/init.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_address.h>
> +#include "clk-mpll.h"
> +#include "clk-pll.h"
> +#include "clk-regmap.h"
> +#include "vid-pll-div.h"
> +#include "clk-dualdiv.h"
> +#include "meson-eeclk.h"
> +#include "a1.h"
> +
[...]
> +
> +/*
> + * The Meson A1 HIFI PLL is 614.4M, it requires
> + * a strict register sequence to enable the PLL.
> + * set meson_clk_pcie_pll_ops as its ops
Please remove this last line as it's obvious from the code what ops are
used.
> + */
> +static struct clk_regmap a1_hifi_pll = {
> + .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
> + .shift = 28,
> + .width = 1,
> + },
> + .m = {
> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
> + .shift = 0,
> + .width = 8,
> + },
> + .n = {
> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
> + .shift = 10,
> + .width = 5,
> + },
> + .frac = {
> + .reg_off = ANACTRL_HIFIPLL_CTRL1,
> + .shift = 0,
> + .width = 19,
> + },
> + .l = {
> + .reg_off = ANACTRL_HIFIPLL_STS,
> + .shift = 31,
> + .width = 1,
> + },
> + .table = a1_hifi_pll_params_table,
> + .init_regs = a1_hifi_init_regs,
> + .init_count = ARRAY_SIZE(a1_hifi_init_regs),
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "hifi_pll",
> + .ops = &meson_clk_pcie_pll_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &a1_xtal_hifipll.hw
> + },
> + .num_parents = 1,
> + },
> +};
> +
[..]
> +
> +static struct clk_regmap a1_fclk_div2 = {
> + .data = &(struct clk_regmap_gate_data){
> + .offset = ANACTRL_FIXPLL_CTRL0,
> + .bit_idx = 21,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "fclk_div2",
> + .ops = &clk_regmap_gate_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &a1_fclk_div2_div.hw
> + },
> + .num_parents = 1,
> + /*
> + * add CLK_IS_CRITICAL flag to avoid being disabled by clk core
> + * or its children clocks.
This comment is useless. Please replace it with an actual reason for
keeping the clk on instead of describing what the flag does.
> + */
> + .flags = CLK_IS_CRITICAL,
> + },
> +};
> +
[..]
> +static struct clk_regmap a1_dmc = {
> + .data = &(struct clk_regmap_gate_data){
> + .offset = DMC_CLK_CTRL,
> + .bit_idx = 8,
> + },
> + .hw.init = &(struct clk_init_data) {
> + .name = "dmc",
> + .ops = &clk_regmap_gate_ops,
> + .parent_hws = (const struct clk_hw *[]) {
> + &a1_dmc_sel2.hw
> + },
> + .num_parents = 1,
> + /*
> + * add CLK_IGNORE_UNUSED to avoid hangup
> + * DDR clock should not change at runtime
> + */
> + .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
So not CLK_IS_CRITICAL?
> + },
> +};
> +
[...]
> +
> +/*
> + * cpu clock register base address is 0xfd000080
> + */
> +static struct clk_regmap *const a1_cpu_clk_regmaps[] = {
> + /* TODO */
Can it be done?
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: imx: Skip return value check for some special SCU firmware APIs
From: Leonard Crestez @ 2019-09-25 13:13 UTC (permalink / raw)
To: Anson Huang, shawnguo@kernel.org, Aisheng Dong
Cc: s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1569406066-16626-1-git-send-email-Anson.Huang@nxp.com>
On 25.09.2019 13:09, Anson Huang wrote:
> The SCU firmware does NOT always have return value stored in message
> header's function element even the API has response data, those special
> APIs are defined as void function in SCU firmware, so they should be
> treated as return success always.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> - This patch is based on the patch of https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11129553%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cc0ced6cd07f04023977008d741a07367%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637050029712216472&sdata=Ccq%2Fb2RJdMqmnL7VXrl8YhOlUwC7bWiUG%2BNmiw4OsSM%3D&reserved=0
> ---
> drivers/firmware/imx/imx-scu.c | 34 ++++++++++++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
> index 869be7a..ced5b12 100644
> --- a/drivers/firmware/imx/imx-scu.c
> +++ b/drivers/firmware/imx/imx-scu.c
> @@ -78,6 +78,11 @@ static int imx_sc_linux_errmap[IMX_SC_ERR_LAST] = {
> -EIO, /* IMX_SC_ERR_FAIL */
> };
>
> +static const struct imx_sc_rpc_msg whitelist[] = {
> + { .svc = IMX_SC_RPC_SVC_MISC, .func = IMX_SC_MISC_FUNC_UNIQUE_ID },
> + { .svc = IMX_SC_RPC_SVC_MISC, .func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS },
> +};
Until now this low level IPC code didn't treat any svc/func specially
and this seems good.
The imx_scu_call_rpc function already has an have_resp argument and
callers are responsible to fill it. Can't we deal with this by adding an
additional err_ret flag passed by the caller?
We can add wrapper functions to avoid tree-wide changes for all callers.
> +
> static struct imx_sc_ipc *imx_sc_ipc_handle;
>
> static inline int imx_sc_to_linux_errno(int errno)
> @@ -157,11 +162,24 @@ static int imx_scu_ipc_write(struct imx_sc_ipc *sc_ipc, void *msg)
> return 0;
> }
>
> +static bool imx_scu_call_skip_return_value_check(uint8_t svc, uint8_t func)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(whitelist); i++)
> + if (svc == whitelist[i].svc &&
> + func == whitelist[i].func)
> + return true;
> +
> + return false;
> +}
> +
> /*
> * RPC command/response
> */
> int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, bool have_resp)
> {
> + uint8_t saved_svc, saved_func;
> struct imx_sc_rpc_msg *hdr;
> int ret;
>
> @@ -171,8 +189,11 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, bool have_resp)
> mutex_lock(&sc_ipc->lock);
> reinit_completion(&sc_ipc->done);
>
> - if (have_resp)
> + if (have_resp) {
> sc_ipc->msg = msg;
> + saved_svc = ((struct imx_sc_rpc_msg *)msg)->svc;
> + saved_func = ((struct imx_sc_rpc_msg *)msg)->func;
> + }
> sc_ipc->count = 0;
> ret = imx_scu_ipc_write(sc_ipc, msg);
> if (ret < 0) {
> @@ -190,7 +211,16 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, bool have_resp)
>
> /* response status is stored in hdr->func field */
> hdr = msg;
> - ret = hdr->func;
> + /*
> + * Some special SCU firmware APIs do NOT have return value
> + * in hdr->func, but they do have response data, those special
> + * APIs are defined as void function in SCU firmware, so they
> + * should be treated as return success always.
> + */
> + if (!imx_scu_call_skip_return_value_check(saved_svc, saved_func))
> + ret = hdr->func;
> + else
> + ret = 0;
> }
>
> out:
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] kselftest: exclude failed TARGETS from runlist
From: Cristian Marussi @ 2019-09-25 13:24 UTC (permalink / raw)
To: linux-kselftest, linux-arm-kernel, shuah; +Cc: dave.martin
In-Reply-To: <20190925132421.23572-1-cristian.marussi@arm.com>
A TARGET which failed to be built/installed should not be included in the
runlist generated inside the run_kselftest.sh script.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
As an example, here BPF failed to compile but was included in the runlist
and attempted to run anyway:
...
./KSFT_LAST_2/run_kselftest.sh: 37: cd: can't cd to bpf
TAP version 13
1..49
\# selftests: KSFT_LAST_2: test_verifier
\# Warning: file test_verifier is missing!
not ok 1 selftests: KSFT_LAST_2: test_verifier
\# selftests: KSFT_LAST_2: test_tag
\# Warning: file test_tag is missing!
---
tools/testing/selftests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 103936faa46d..e11ace11b07c 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -202,8 +202,12 @@ ifdef INSTALL_PATH
echo " cat /dev/null > \$$logfile" >> $(ALL_SCRIPT)
echo "fi" >> $(ALL_SCRIPT)
+ @# While building run_kselftest.sh skip also non-existent TARGET dirs:
+ @# they could be the result of a build failure and should NOT be
+ @# included in the generated runlist.
for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
+ [ ! -d $$INSTALL_PATH/$$TARGET ] && echo "Skipping non-existent dir: $$TARGET" && continue; \
echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
echo "cd $$TARGET" >> $(ALL_SCRIPT); \
echo -n "run_many" >> $(ALL_SCRIPT); \
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] kselftest: add capability to skip chosen TARGETS
From: Cristian Marussi @ 2019-09-25 13:24 UTC (permalink / raw)
To: linux-kselftest, linux-arm-kernel, shuah; +Cc: dave.martin
Let the user specify an optional TARGETS skiplist through the new optional
SKIP_TARGETS Makefile variable.
It is easier to skip at will a reduced and well defined list of possibly
problematic targets with SKIP_TARGETS then to provide a partially stripped
down list of good targets using the usual TARGETS variable.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
tools/testing/selftests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 25b43a8c2b15..103936faa46d 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -132,6 +132,10 @@ else
ARCH=$(ARCH) -C $(top_srcdir) headers_install
endif
+# User can optionally provide a TARGETS skiplist.
+SKIP_TARGETS ?=
+TARGETS := $(filter-out $(SKIP_TARGETS), $(TARGETS))
+
all: khdr
@for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH] interconnect: Replace of_icc_get() with icc_get() and reduce DT binding
From: Stephen Boyd @ 2019-09-25 13:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, linux-pm, linux-arm-msm, David Dai, linux-kernel,
Maxime Ripard, Rob Herring, Evan Green, Georgi Djakov,
linux-arm-kernel
In-Reply-To: <20190925055933.GA2810@tuxbook-pro>
Quoting Bjorn Andersson (2019-09-24 22:59:33)
> On Tue 24 Sep 22:41 PDT 2019, Stephen Boyd wrote:
>
> > The DT binding could also be simplified somewhat. Currently a path needs
> > to be specified in DT for each and every use case that is possible for a
> > device to want. Typically the path is to memory, which looks to be
> > reserved for in the binding with the "dma-mem" named path, but sometimes
> > the path is from a device to the CPU or more generically from a device
> > to another device which could be a CPU, cache, DMA master, or another
> > device if some sort of DMA to DMA scenario is happening. Let's remove
> > the pair part of the binding so that we just list out a device's
> > possible endpoints on the bus or busses that it's connected to.
> >
> > If the kernel wants to figure out what the path is to memory or the CPU
> > or a cache or something else it should be able to do that by finding the
> > node for the "destination" endpoint, extracting that node's
> > "interconnects" property, and deriving the path in software. For
> > example, we shouldn't need to write out each use case path by path in DT
> > for each endpoint node that wants to set a bandwidth to memory. We
> > should just be able to indicate what endpoint(s) a device sits on based
> > on the interconnect provider in the system and then walk the various
> > interconnects to find the path from that source endpoint to the
> > destination endpoint.
> >
>
> But doesn't this implies that the other end of the path is always some
> specific node, e.g. DDR? With a single node how would you describe
> CPU->LLCC or GPU->OCIMEM?
By only specifying the endpoint the device uses it describes what the
hardware block interfaces with. It doesn't imply that there's only one
other end of the path. It implies that the paths should be discoverable
by walking the interconnect graph given some source device node and
target device node. In most cases the target device node will be a DDR
controller node, but sometimes it could be LLCC or OCIMEM. We may need
to add some sort of "get the DDR controller device" API or work it into
the interconnect API somehow to indicate what target endpoint is
desired. By not listing all those paths in DT we gain flexibility to add
more paths later on without having to update or tweak DT to describe
more paths/routes through the interconnect.
>
> > Obviously this patch doesn't compile but I'm sending it out to start
> > this discussion so we don't get stuck on the binding or the kernel APIs
> > for a long time. It looks like we should be OK in terms of backwards
> > compatibility because we can just ignore the second element in an old
> > binding, but maybe we'll want to describe paths in different directions
> > (e.g. the path from the CPU to the SD controller may be different than
> > the path the SD controller takes to the CPU) and that may require
> > extending interconnect-names to indicate what direction/sort of path it
> > is. I'm basically thinking about master vs. slave ports in AXI land.
> >
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: <linux-pm@vger.kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: <devicetree@vger.kernel.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Evan Green <evgreen@chromium.org>
> > Cc: David Dai <daidavid1@codeaurora.org>
> > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > ---
> > .../bindings/interconnect/interconnect.txt | 19 ++++---------------
> > include/linux/interconnect.h | 13 ++-----------
> > 2 files changed, 6 insertions(+), 26 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > index 6f5d23a605b7..f8979186b8a7 100644
> > --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > @@ -11,7 +11,7 @@ The interconnect provider binding is intended to represent the interconnect
> > controllers in the system. Each provider registers a set of interconnect
> > nodes, which expose the interconnect related capabilities of the interconnect
> > to consumer drivers. These capabilities can be throughput, latency, priority
> > -etc. The consumer drivers set constraints on interconnect path (or endpoints)
> > +etc. The consumer drivers set constraints on interconnect paths (or endpoints)
> > depending on the use case. Interconnect providers can also be interconnect
> > consumers, such as in the case where two network-on-chip fabrics interface
> > directly.
> > @@ -42,23 +42,12 @@ multiple paths from different providers depending on use case and the
> > components it has to interact with.
> >
> > Required properties:
> > -interconnects : Pairs of phandles and interconnect provider specifier to denote
> > - the edge source and destination ports of the interconnect path.
> > -
> > -Optional properties:
> > -interconnect-names : List of interconnect path name strings sorted in the same
> > - order as the interconnects property. Consumers drivers will use
> > - interconnect-names to match interconnect paths with interconnect
> > - specifier pairs.
> > -
> > - Reserved interconnect names:
> > - * dma-mem: Path from the device to the main memory of
> > - the system
> > +interconnects : phandle and interconnect provider specifier to denote
> > + the edge source for this node.
> >
> > Example:
> >
> > sdhci@7864000 {
> > ...
> > - interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
> > - interconnect-names = "sdhc-mem";
> > + interconnects = <&pnoc MASTER_SDCC_1>;
>
> This example seems incomplete, as it doesn't describe the path between
> CPU and the config space, with this in place I think you need the
> interconnect-names.
>
>
> But with a single interconnect, the interconnect-names should be
> omitted, as done in other frameworks.
>
Sure, no names makes sense when it's just one path.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] ARM: Add support for Realtek SOC
From: Andreas Färber @ 2019-09-25 13:30 UTC (permalink / raw)
To: James Tai, 'Masahiro Yamada', 'Arnd Bergmann'
Cc: 'Jason A . Donenfeld', linux-realtek-soc,
CY_Huang[黃鉦晏], 'Linus Walleij',
'Stefan Agner', 'Benjamin Gaignard',
Simon Hsu[徐文翰],
'Mauro Carvalho Chehab',
Tom Ting[丁郁庭],
Jim Tsai [蔡維晉], Phinex Hung,
Edward Wu[吳奕寬], 'Rob Herring',
'Lorenzo Pieralisi', 'Russell King',
'Mike Rapoport', YH_Hsieh[謝宇勳],
TY_Chang[張子逸], 'Thierry Reding',
'jamestai.sky@gmail.com',
ZR_Chen[陳振榮], Hau, Yukuen,
Jinn.Cheng[鄭才進],
Chase Yen [顏呈育],
Stanley Chang[昌育德], 'Doug Anderson',
'Linux ARM', Eric Wang[王偉全], Adklei,
Edgar Lee [李承諭], 'Ard Biesheuvel',
PK.Chuang [莊博凱], 'Nicolas Pitre',
'Nick Desaulniers',
'linux-kernel@vger.kernel.org', 'Paul Burton',
phelic
In-Reply-To: <43B123F21A8CFE44A9641C099E4196FFCF8EA2B1@RTITMBSVM04.realtek.com.tw>
Hi James,
Am Mittwoch, den 25.09.2019, 06:43 +0000 schrieb James Tai:
> From: "james.tai" <james.tai@realtek.com>
>
> This patch adds the basic machine file for
> the Realtek RTD16XX and RTD13XX platform.
>
> Signed-off-by: james.tai <james.tai@realtek.com>
> ---
> Changes since last version:
> - Add RTD13XX platform.
> - Add PSCI support.
> - Add ARCH_MULTI_V7 config.
> - remove 'textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000' from
> 'arch/arm/Makefile'.
> - remove map_io,init_time,init_machine and smp_init from
> machine
> descriptor.
Thanks for your patch. Please subscribe yourself and colleagues to the
existing linux-realtek-soc@lists.infradead.org mailing list and make
sure it is in CC for your patches:
http://lists.infradead.org/mailman/listinfo/linux-realtek-soc
Further comments inline:
> ---
> arch/arm/Kconfig | 2 ++
> arch/arm/Makefile | 1 +
> arch/arm/mach-realtek/Kconfig | 20 +++++++++++++
> arch/arm/mach-realtek/Makefile | 3 ++
> arch/arm/mach-realtek/platsmp.c | 51
> +++++++++++++++++++++++++++++++++
> arch/arm/mach-realtek/platsmp.h | 6 ++++
> arch/arm/mach-realtek/realtek.c | 43 +++++++++++++++++++++++++++
> 7 files changed, 126 insertions(+)
> create mode 100644 arch/arm/mach-realtek/Kconfig
> create mode 100644 arch/arm/mach-realtek/Makefile
> create mode 100644 arch/arm/mach-realtek/platsmp.c
> create mode 100644 arch/arm/mach-realtek/platsmp.h
> create mode 100644 arch/arm/mach-realtek/realtek.c
As Arnd has already expressed, at least RTD13xx (if not also RTD16xx?)
is a 64-bit SoC, and we already have code - contributed and maintained
by me - for arch/arm64/. Please contribute to those efforts instead of
building your own sandcastle in arch/arm/. In fact, your work collides
with patches queued in my rtd129x-next branch for RTD1195, an actual
32-bit platform. Among other commits:
https://github.com/afaerber/linux/commit/b43fa4f790183d46e2b2c7f5af34f3010d315073
Those previous arm64 RTD129x and arm RTD1195 efforts were and are
blocked by irqchip, which I don't see addressed in this single patch.
https://github.com/afaerber/linux/commits/rtd1295-next
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 33b00579beff..1f7967c97267 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -793,6 +793,8 @@ source "arch/arm/mach-realview/Kconfig"
>
> source "arch/arm/mach-rockchip/Kconfig"
>
> +source "arch/arm/mach-realtek/Kconfig"
Ordering wrong.
> +
> source "arch/arm/mach-s3c24xx/Kconfig"
>
> source "arch/arm/mach-s3c64xx/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..560ae7d72aab 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -205,6 +205,7 @@ machine-$(CONFIG_ARCH_RDA) += rda
> machine-$(CONFIG_ARCH_REALVIEW) += realview
> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> machine-$(CONFIG_ARCH_RPC) += rpc
> +machine-$(CONFIG_ARCH_REALTEK) += realtek
Ditto.
> machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx
> machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
> machine-$(CONFIG_ARCH_S5PV210) += s5pv210
> diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-
> realtek/Kconfig
> new file mode 100644
> index 000000000000..a638f4322bb2
> --- /dev/null
> +++ b/arch/arm/mach-realtek/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig ARCH_REALTEK
> + bool "Realtek SoC Support"
> + depends on ARCH_MULTI_V7
> + help
> + Support for Realtek rtd16xx & rtd13xx SoCs.
> +
> +if ARCH_REALTEK
> +
> +config ARCH_RTD13XX
> + bool "Enable support for RTD1319"
> + select ARM_GIC_V3
> + select ARM_PSCI
> +
> +config ARCH_RTD16XX
> + bool "Enable support for RTD1619"
> + select ARM_GIC_V3
> + select ARM_PSCI
> +
> +endif
> diff --git a/arch/arm/mach-realtek/Makefile b/arch/arm/mach-
> realtek/Makefile
> new file mode 100644
> index 000000000000..9cdc1f1f2917
> --- /dev/null
> +++ b/arch/arm/mach-realtek/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_ARCH_REALTEK) += realtek.o
> +obj-$(CONFIG_SMP) += platsmp.o
> diff --git a/arch/arm/mach-realtek/platsmp.c b/arch/arm/mach-
> realtek/platsmp.c
> new file mode 100644
> index 000000000000..b3fc99447ad4
> --- /dev/null
> +++ b/arch/arm/mach-realtek/platsmp.c
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/delay.h>
> +#include <linux/jiffies.h>
> +#include <linux/io.h>
> +#include <linux/memory.h>
> +#include <linux/smp.h>
> +#include <linux/of.h>
> +#include <linux/arm-smccc.h>
> +#include <asm/smp_plat.h>
> +#include <asm/cacheflush.h>
> +#include <asm/cp15.h>
> +#include <asm/barrier.h>
> +
> +#define BL31_CMD 0x8400ff04
> +#define BL31_DAT 0x00001619
> +#define CORE_PWRDN_EN 0x1
> +
> +#define CPUPWRCTLR __ACCESS_CP15(c15, 0, c2, 7)
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +
> +static void rtk_cpu_die(unsigned int cpu)
> +{
> + struct arm_smccc_res res;
> + unsigned int cpu_pwr_ctrl;
> +
> + /* notify BL31 cpu hotplug */
> + arm_smccc_smc(BL31_CMD, BL31_DAT, 0, 0, 0, 0, 0, 0, &res);
BL31 is clearly for 64-bit only and will not work for RTD1195, so the
naming is much too generic.
> + v7_exit_coherency_flush(louis);
> +
> + cpu_pwr_ctrl = read_sysreg(CPUPWRCTLR);
> + cpu_pwr_ctrl |= CORE_PWRDN_EN;
> + write_sysreg(cpu_pwr_ctrl, CPUPWRCTLR);
> +
> + dsb(sy);
> +
> + for (;;)
> + wfi();
> +}
> +#endif
> +
> +struct smp_operations rtk_smp_ops __initdata = {
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_die = rtk_cpu_die,
> +#endif
> +};
> diff --git a/arch/arm/mach-realtek/platsmp.h b/arch/arm/mach-
> realtek/platsmp.h
> new file mode 100644
> index 000000000000..c9c4d712369c
> --- /dev/null
> +++ b/arch/arm/mach-realtek/platsmp.h
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +extern struct smp_operations rtk_smp_ops;
> diff --git a/arch/arm/mach-realtek/realtek.c b/arch/arm/mach-
> realtek/realtek.c
> new file mode 100644
> index 000000000000..2692ac53f59b
> --- /dev/null
> +++ b/arch/arm/mach-realtek/realtek.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/irqchip.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/io.h>
> +#include <linux/memblock.h>
> +#include <linux/delay.h>
> +#include <linux/clockchips.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/system_misc.h>
> +#include <asm/system_info.h>
> +
> +#include "platsmp.h"
> +
> +static const char *const rtd13xx_board_dt_compat[] = {
> + "realtek,rtd1319",
> + NULL,
> +};
> +
> +static const char *const rtd16xx_board_dt_compat[] = {
> + "realtek,rtd1619",
> + NULL,
> +};
> +
> +DT_MACHINE_START(RTD13XX, "Realtek rtd13xx platform")
> + .dt_compat = rtd13xx_board_dt_compat,
> + .smp = smp_ops(rtk_smp_ops),
> +MACHINE_END
> +
> +DT_MACHINE_START(RTD16XX, "Realtek rtd16xx platform")
> + .dt_compat = rtd16xx_board_dt_compat,
> + .smp = smp_ops(rtk_smp_ops),
> +MACHINE_END
I recall that 32-bit arm SMP can be selected via the DT and then does
not need multiple such structs per SoC, in particular they don't differ
at all and could use the default machine taking the text from the DT.
Also note that whenever possible I personally have a preference for
GPL-2.0-or-later and licensed my code that way whenever possible.
Question: Why are you not just implementing the above CPU logic in TF-A
BL31 and let Linux use the existing PSCI code paths? That will be the
only upstream-accepted solution for arm64.
Thanks,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] ARM: Add support for Realtek SOC
From: Andreas Färber @ 2019-09-25 13:31 UTC (permalink / raw)
To: James Tai, 'Masahiro Yamada', 'Arnd Bergmann'
Cc: 'Jason A . Donenfeld', linux-realtek-soc,
CY_Huang[黃鉦晏], 'Linus Walleij',
'Stefan Agner', 'Benjamin Gaignard',
Simon Hsu[徐文翰],
'Mauro Carvalho Chehab',
Tom Ting[丁郁庭],
Jim Tsai [蔡維晉], Phinex Hung,
Edward Wu[吳奕寬], 'Rob Herring',
'Lorenzo Pieralisi', 'Russell King',
'Mike Rapoport', YH_Hsieh[謝宇勳],
TY_Chang[張子逸], 'Thierry Reding',
'jamestai.sky@gmail.com',
ZR_Chen[陳振榮], Hau, Yukuen,
Jinn.Cheng[鄭才進],
Chase Yen [顏呈育],
Stanley Chang[昌育德], 'Doug Anderson',
'Linux ARM', Eric Wang[王偉全], Adklei,
Edgar Lee [李承諭], 'Ard Biesheuvel',
PK.Chuang [莊博凱], 'Nicolas Pitre',
'Nick Desaulniers',
'linux-kernel@vger.kernel.org', 'Paul Burton',
phelic
In-Reply-To: <43B123F21A8CFE44A9641C099E4196FFCF8EA2B1@RTITMBSVM04.realtek.com.tw>
Hi James,
Am Mittwoch, den 25.09.2019, 06:43 +0000 schrieb James Tai:
> From: "james.tai" <james.tai@realtek.com>
>
> This patch adds the basic machine file for
> the Realtek RTD16XX and RTD13XX platform.
>
> Signed-off-by: james.tai <james.tai@realtek.com>
> ---
> Changes since last version:
> - Add RTD13XX platform.
> - Add PSCI support.
> - Add ARCH_MULTI_V7 config.
> - remove 'textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000' from
> 'arch/arm/Makefile'.
> - remove map_io,init_time,init_machine and smp_init from
> machine
> descriptor.
Thanks for your patch. Please subscribe yourself and colleagues to the
existing linux-realtek-soc@lists.infradead.org mailing list and make
sure it is in CC for your patches:
http://lists.infradead.org/mailman/listinfo/linux-realtek-soc
Further comments inline:
> ---
> arch/arm/Kconfig | 2 ++
> arch/arm/Makefile | 1 +
> arch/arm/mach-realtek/Kconfig | 20 +++++++++++++
> arch/arm/mach-realtek/Makefile | 3 ++
> arch/arm/mach-realtek/platsmp.c | 51
> +++++++++++++++++++++++++++++++++
> arch/arm/mach-realtek/platsmp.h | 6 ++++
> arch/arm/mach-realtek/realtek.c | 43 +++++++++++++++++++++++++++
> 7 files changed, 126 insertions(+)
> create mode 100644 arch/arm/mach-realtek/Kconfig
> create mode 100644 arch/arm/mach-realtek/Makefile
> create mode 100644 arch/arm/mach-realtek/platsmp.c
> create mode 100644 arch/arm/mach-realtek/platsmp.h
> create mode 100644 arch/arm/mach-realtek/realtek.c
As Arnd has already expressed, at least RTD13xx (if not also RTD16xx?)
is a 64-bit SoC, and we already have code - contributed and maintained
by me - for arch/arm64/. Please contribute to those efforts instead of
building your own sandcastle in arch/arm/. In fact, your work collides
with patches queued in my rtd129x-next branch for RTD1195, an actual
32-bit platform. Among other commits:
https://github.com/afaerber/linux/commit/b43fa4f790183d46e2b2c7f5af34f3010d315073
Those previous arm64 RTD129x and arm RTD1195 efforts were and are
blocked by irqchip, which I don't see addressed in this single patch.
https://github.com/afaerber/linux/commits/rtd1295-next
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 33b00579beff..1f7967c97267 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -793,6 +793,8 @@ source "arch/arm/mach-realview/Kconfig"
>
> source "arch/arm/mach-rockchip/Kconfig"
>
> +source "arch/arm/mach-realtek/Kconfig"
Ordering wrong.
> +
> source "arch/arm/mach-s3c24xx/Kconfig"
>
> source "arch/arm/mach-s3c64xx/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..560ae7d72aab 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -205,6 +205,7 @@ machine-$(CONFIG_ARCH_RDA) += rda
> machine-$(CONFIG_ARCH_REALVIEW) += realview
> machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
> machine-$(CONFIG_ARCH_RPC) += rpc
> +machine-$(CONFIG_ARCH_REALTEK) += realtek
Ditto.
> machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx
> machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
> machine-$(CONFIG_ARCH_S5PV210) += s5pv210
> diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-
> realtek/Kconfig
> new file mode 100644
> index 000000000000..a638f4322bb2
> --- /dev/null
> +++ b/arch/arm/mach-realtek/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig ARCH_REALTEK
> + bool "Realtek SoC Support"
> + depends on ARCH_MULTI_V7
> + help
> + Support for Realtek rtd16xx & rtd13xx SoCs.
> +
> +if ARCH_REALTEK
> +
> +config ARCH_RTD13XX
> + bool "Enable support for RTD1319"
> + select ARM_GIC_V3
> + select ARM_PSCI
> +
> +config ARCH_RTD16XX
> + bool "Enable support for RTD1619"
> + select ARM_GIC_V3
> + select ARM_PSCI
> +
> +endif
> diff --git a/arch/arm/mach-realtek/Makefile b/arch/arm/mach-
> realtek/Makefile
> new file mode 100644
> index 000000000000..9cdc1f1f2917
> --- /dev/null
> +++ b/arch/arm/mach-realtek/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_ARCH_REALTEK) += realtek.o
> +obj-$(CONFIG_SMP) += platsmp.o
> diff --git a/arch/arm/mach-realtek/platsmp.c b/arch/arm/mach-
> realtek/platsmp.c
> new file mode 100644
> index 000000000000..b3fc99447ad4
> --- /dev/null
> +++ b/arch/arm/mach-realtek/platsmp.c
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/delay.h>
> +#include <linux/jiffies.h>
> +#include <linux/io.h>
> +#include <linux/memory.h>
> +#include <linux/smp.h>
> +#include <linux/of.h>
> +#include <linux/arm-smccc.h>
> +#include <asm/smp_plat.h>
> +#include <asm/cacheflush.h>
> +#include <asm/cp15.h>
> +#include <asm/barrier.h>
> +
> +#define BL31_CMD 0x8400ff04
> +#define BL31_DAT 0x00001619
> +#define CORE_PWRDN_EN 0x1
> +
> +#define CPUPWRCTLR __ACCESS_CP15(c15, 0, c2, 7)
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +
> +static void rtk_cpu_die(unsigned int cpu)
> +{
> + struct arm_smccc_res res;
> + unsigned int cpu_pwr_ctrl;
> +
> + /* notify BL31 cpu hotplug */
> + arm_smccc_smc(BL31_CMD, BL31_DAT, 0, 0, 0, 0, 0, 0, &res);
BL31 is clearly for 64-bit only and will not work for RTD1195, so the
naming is much too generic.
> + v7_exit_coherency_flush(louis);
> +
> + cpu_pwr_ctrl = read_sysreg(CPUPWRCTLR);
> + cpu_pwr_ctrl |= CORE_PWRDN_EN;
> + write_sysreg(cpu_pwr_ctrl, CPUPWRCTLR);
> +
> + dsb(sy);
> +
> + for (;;)
> + wfi();
> +}
> +#endif
> +
> +struct smp_operations rtk_smp_ops __initdata = {
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_die = rtk_cpu_die,
> +#endif
> +};
> diff --git a/arch/arm/mach-realtek/platsmp.h b/arch/arm/mach-
> realtek/platsmp.h
> new file mode 100644
> index 000000000000..c9c4d712369c
> --- /dev/null
> +++ b/arch/arm/mach-realtek/platsmp.h
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +extern struct smp_operations rtk_smp_ops;
> diff --git a/arch/arm/mach-realtek/realtek.c b/arch/arm/mach-
> realtek/realtek.c
> new file mode 100644
> index 000000000000..2692ac53f59b
> --- /dev/null
> +++ b/arch/arm/mach-realtek/realtek.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/irqchip.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/io.h>
> +#include <linux/memblock.h>
> +#include <linux/delay.h>
> +#include <linux/clockchips.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/system_misc.h>
> +#include <asm/system_info.h>
> +
> +#include "platsmp.h"
> +
> +static const char *const rtd13xx_board_dt_compat[] = {
> + "realtek,rtd1319",
> + NULL,
> +};
> +
> +static const char *const rtd16xx_board_dt_compat[] = {
> + "realtek,rtd1619",
> + NULL,
> +};
> +
> +DT_MACHINE_START(RTD13XX, "Realtek rtd13xx platform")
> + .dt_compat = rtd13xx_board_dt_compat,
> + .smp = smp_ops(rtk_smp_ops),
> +MACHINE_END
> +
> +DT_MACHINE_START(RTD16XX, "Realtek rtd16xx platform")
> + .dt_compat = rtd16xx_board_dt_compat,
> + .smp = smp_ops(rtk_smp_ops),
> +MACHINE_END
I recall that 32-bit arm SMP can be selected via the DT and then does
not need multiple such structs per SoC, in particular they don't differ
at all and could use the default machine taking the text from the DT.
Also note that whenever possible I personally have a preference for
GPL-2.0-or-later and licensed my code that way whenever possible.
Question: Why are you not just implementing the above CPU logic in TF-A
BL31 and let Linux use the existing PSCI code paths? That will be the
only upstream-accepted solution for arm64.
Thanks,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 247165 (AG München)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: timer: Convert Exynos MCT bindings to json-schema
From: Marek Szyprowski @ 2019-09-25 13:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Mark Rutland, Kukjin Kim, Andrzej Hajda, linux-kernel, devicetree,
linux-arm-kernel, linux-samsung-soc
Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>
Hi Krzysztof,
On 23.09.2019 18:14, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos Soc Multi Core Timer bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v3:
> 1. Use interrupts-extended instead of interrupts-map.
>
> Changes since v1:
> 1. Indent example with four spaces (more readable),
> 2. Rename nodes in example to timer,
> 3. Remove mct-map subnode.
> ---
> .../bindings/timer/samsung,exynos4210-mct.txt | 88 ------------
> .../timer/samsung,exynos4210-mct.yaml | 125 ++++++++++++++++++
> 2 files changed, 125 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> create mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
>
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> deleted file mode 100644
> index 8f78640ad64c..000000000000
> --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> +++ /dev/null
> @@ -1,88 +0,0 @@
> -Samsung's Multi Core Timer (MCT)
> -
> -The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
> -global timer and CPU local timers. The global timer is a 64-bit free running
> -up-counter and can generate 4 interrupts when the counter reaches one of the
> -four preset counter values. The CPU local timers are 32-bit free running
> -down-counters and generate an interrupt when the counter expires. There is
> -one CPU local timer instantiated in MCT for every CPU in the system.
> -
> -Required properties:
> -
> -- compatible: should be "samsung,exynos4210-mct".
> - (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
> - (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
> -
> -- reg: base address of the mct controller and length of the address space
> - it occupies.
> -
> -- interrupts: the list of interrupts generated by the controller. The following
> - should be the order of the interrupts specified. The local timer interrupts
> - should be specified after the four global timer interrupts have been
> - specified.
> -
> - 0: Global Timer Interrupt 0
> - 1: Global Timer Interrupt 1
> - 2: Global Timer Interrupt 2
> - 3: Global Timer Interrupt 3
> - 4: Local Timer Interrupt 0
> - 5: Local Timer Interrupt 1
> - 6: ..
> - 7: ..
> - i: Local Timer Interrupt n
> -
> - For MCT block that uses a per-processor interrupt for local timers, such
> - as ones compatible with "samsung,exynos4412-mct", only one local timer
> - interrupt might be specified, meaning that all local timers use the same
> - per processor interrupt.
> -
> -Example 1: In this example, the IP contains two local timers, using separate
> - interrupts, so two local timer interrupts have been specified,
> - in addition to four global timer interrupts.
> -
> - mct@10050000 {
> - compatible = "samsung,exynos4210-mct";
> - reg = <0x10050000 0x800>;
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>, <0 48 0>;
> - };
> -
> -Example 2: In this example, the timer interrupts are connected to two separate
> - interrupt controllers. Hence, an interrupt-map is created to map
> - the interrupts to the respective interrupt controllers.
> -
> - mct@101c0000 {
> - compatible = "samsung,exynos4210-mct";
> - reg = <0x101C0000 0x800>;
> - interrupt-parent = <&mct_map>;
> - interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
> -
> - mct_map: mct-map {
> - #interrupt-cells = <1>;
> - #address-cells = <0>;
> - #size-cells = <0>;
> - interrupt-map = <0 &gic 0 57 0>,
> - <1 &gic 0 69 0>,
> - <2 &combiner 12 6>,
> - <3 &combiner 12 7>,
> - <4 &gic 0 42 0>,
> - <5 &gic 0 48 0>;
> - };
> - };
> -
> -Example 3: In this example, the IP contains four local timers, but using
> - a per-processor interrupt to handle them. Either all the local
> - timer interrupts can be specified, with the same interrupt specifier
> - value or just the first one.
> -
> - mct@10050000 {
> - compatible = "samsung,exynos4412-mct";
> - reg = <0x10050000 0x800>;
> -
> - /* Both ways are possible in this case. Either: */
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>;
> - /* or: */
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
> - };
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> new file mode 100644
> index 000000000000..bff3f54a398f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/samsung,exynos4210-mct.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC Multi Core Timer (MCT)
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +description: |+
> + The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
> + global timer and CPU local timers. The global timer is a 64-bit free running
> + up-counter and can generate 4 interrupts when the counter reaches one of the
> + four preset counter values. The CPU local timers are 32-bit free running
> + down-counters and generate an interrupt when the counter expires. There is
> + one CPU local timer instantiated in MCT for every CPU in the system.
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,exynos4210-mct
> + - samsung,exynos4412-mct
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + description: |
> + Interrupts should be put in specific order. This is, the local timer
> + interrupts should be specified after the four global timer interrupts
> + have been specified:
> + 0: Global Timer Interrupt 0
> + 1: Global Timer Interrupt 1
> + 2: Global Timer Interrupt 2
> + 3: Global Timer Interrupt 3
> + 4: Local Timer Interrupt 0
> + 5: Local Timer Interrupt 1
> + 6: ..
> + 7: ..
> + i: Local Timer Interrupt n
> + For MCT block that uses a per-processor interrupt for local timers, such
> + as ones compatible with "samsung,exynos4412-mct", only one local timer
> + interrupt might be specified, meaning that all local timers use the same
> + per processor interrupt.
> + minItems: 5 # 4 Global + 1 local
> + maxItems: 20 # 4 Global + 16 local
> +
> + interrupts-extended:
> + description: |
> + If interrupts are coming from different controllers, this property
> + can be used instead of regular "interrupts" property.
> + The format is exactly the same as with "interrupts".
> + Interrupts should be put in specific order. This is, the local timer
> + minItems: 5 # 4 Global + 1 local
> + maxItems: 20 # 4 Global + 16 local
> +
> +required:
> + - compatible
> + - interrupts
> + - reg
> +
> +allOf:
> + - if:
> + not:
> + required:
> + - interrupts
> + then:
> + required:
> + - interrupts-extended
> +
> +examples:
> + - |
> + // In this example, the IP contains two local timers, using separate
> + // interrupts, so two local timer interrupts have been specified,
> + // in addition to four global timer interrupts.
> +
> + timer@10050000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x10050000 0x800>;
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>, <0 48 0>;
> + };
> +
> + - |
> + // In this example, the timer interrupts are connected to two separate
> + // interrupt controllers. Hence, an interrupts-extended is needed.
> +
> + timer@101c0000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x101C0000 0x800>;
> + interrupts-extended = <&gic 0 57 0>,
> + <&gic 0 69 0>,
> + <&combiner 12 6>,
> + <&combiner 12 7>,
> + <&gic 0 42 0>,
> + <&gic 0 48 0>;
> + };
> +
> + - |
> + // In this example, the IP contains four local timers, but using
> + // a per-processor interrupt to handle them. Only one first local
> + // interrupt is specified.
> +
> + timer@10050000 {
> + compatible = "samsung,exynos4412-mct";
> + reg = <0x10050000 0x800>;
> +
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>;
> + };
> +
> + - |
> + // In this example, the IP contains four local timers, but using
> + // a per-processor interrupt to handle them. All the local timer
> + // interrupts are specified.
> +
> + timer@10050000 {
> + compatible = "samsung,exynos4412-mct";
> + reg = <0x10050000 0x800>;
> +
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
> + };
I would add "#include <dt-bindings/interrupt-controller/arm-gic.h>" and
replace zeros with proper defines like GIC_SPI and GIC_PPI. The last two
examples describes per-processor-interrupts, but have 0 in the specifier
cell 0. I would also use proper IRQ_TYPE_LEVEL_HIGH at cell 3 instead
of 0. I would also consider adding artificial 'interrupt-parent = &git'
property to the 1st, 3rd and 4th examples to make it clear that they
refer to ARM GIC bindings.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v3, 3/3] Documentation: dt: binding: fsl: Add 'fsl, ippdexpcr-alt-addr' property
From: Li Yang @ 2019-09-25 14:07 UTC (permalink / raw)
To: Biwen Li
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, Ran Wang, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB4490684FE0E95695E89173948F870@DB7PR04MB4490.eurprd04.prod.outlook.com>
On Tue, Sep 24, 2019 at 11:27 PM Biwen Li <biwen.li@nxp.com> wrote:
>
> > > >
> > > > > > > > > >
> > > > > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle
> > > > > > > > > > an errata
> > > > > > > > > > A-008646 on LS1021A
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > > > > > > ---
> > > > > > > > > > Change in v3:
> > > > > > > > > > - rename property name
> > > > > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > > > > > >
> > > > > > > > > > Change in v2:
> > > > > > > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > > > > > > >
> > > > > > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > > > > > ++++++++++++++
> > > > > > > > > > 1 file changed, 14 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > > @@ -34,6 +34,11 @@ Chassis Version Example
> > > > Chips
> > > > > > > > > > Optional properties:
> > > > > > > > > > - little-endian : RCPM register block is Little Endian.
> > > > > > > > > > Without it
> > > > > RCPM
> > > > > > > > > > will be Big Endian (default case).
> > > > > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for
> > > > > > > > > > + SoC LS1021A,
> > > > > > > > >
> > > > > > > > > You probably should mention this is related to a hardware
> > > > > > > > > issue on LS1021a and only needed on LS1021a.
> > > > > > > > Okay, got it, thanks, I will add this in v4.
> > > > > > > > >
> > > > > > > > > > + Must include n + 1 entries (n =
> > > > > > > > > > + #fsl,rcpm-wakeup-cells, such
> > > as:
> > > > > > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include
> > > > > > > > > > + 2
> > > > > > > > > > + +
> > > > > > > > > > + 1
> > > > > entries).
> > > > > > > > >
> > > > > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR
> > > > > > > > > registers on an
> > > > > SoC.
> > > > > > > > > However you are defining an offset to scfg registers here.
> > > > > > > > > Why these two are related? The length here should
> > > > > > > > > actually be related to the #address-cells of the soc/.
> > > > > > > > > But since this is only needed for LS1021, you can
> > > > > > > > just make it 3.
> > > > > > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0
> > > > > > > > device node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > > > > > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for
> > > > > IPPDEXPCR1).
> > > > > > > > But because of the hardware issue on LS1021A, I need store
> > > > > > > > the value of IPPDEXPCR registers to an alt address. So I
> > > > > > > > defining an offset to scfg registers, then RCPM driver get
> > > > > > > > an abosolute address from offset, RCPM driver write the
> > > > > > > > value of IPPDEXPCR registers to these abosolute
> > > > > > > > addresses(backup the value of IPPDEXPCR
> > > > > registers).
> > > > > > >
> > > > > > > I understand what you are trying to do. The problem is that
> > > > > > > the new fsl,ippdexpcr-alt-addr property contains a phandle and an
> > offset.
> > > > > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > > > > > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> > > > > > SCFG_SPARECR8 */
> > > > >
> > > > > No. The #address-cell for the soc/ is 2, so the offset to scfg
> > > > > should be 0x0 0x51c. The total size should be 3, but it shouldn't
> > > > > be coming from #fsl,rcpm-wakeup-cells like you mentioned in the
> > binding.
> > > > Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with
> > > > #address-cells instead of #fsl,rcpm-wakeup-cells.
> > >
> > > Yes.
> > I got an example from drivers/pci/controller/dwc/pci-layerscape.c
> > and arch/arm/boot/dts/ls1021a.dtsi as follows:
> > fsl,pcie-scfg = <&scfg 0>, 0 is an index
> >
> > In my fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>, It means that 0x0 is an alt
> > offset address for IPPDEXPCR0, 0x51c is an alt offset address For
> > IPPDEXPCR1 instead of 0x0 and 0x51c compose to an alt address of
> > SCFG_SPARECR8.
> Maybe I need write it as:
> fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x0 0x0 0x51c>;
> first two 0x0 compose an alt offset address for IPPDEXPCR0,
> last 0x0 and 0x51c compose an alt address for IPPDEXPCR1,
I remember the hardware issue is only is only related to IPPDEXPCR1
register, no idea why you need to define IPPDEXPCR0 in the binding.
>
> Best Regards,
> Biwen Li
> > >
> > > Regards,
> > > Leo
> > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > > + The first entry must be a link to the SCFG device node.
> > > > > > > > > > + The non-first entry must be offset of registers of SCFG.
> > > > > > > > > >
> > > > > > > > > > Example:
> > > > > > > > > > The RCPM node for T4240:
> > > > > > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > +The RCPM node for LS1021A:
> > > > > > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > > > > > 2.1+";
> > > > > > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > > > > > > SCFG_SPARECR8 */
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > > -------------------------------------------
> > > > > > > > > > Required fsl,rcpm-wakeup property should be added to a
> > > > > > > > > > device node if the device
> > > > > > > > > > --
> > > > > > > > > > 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v1, 0/1] gpio: dts: aspeed: Add SGPIO driver
From: Linus Walleij @ 2019-09-25 14:15 UTC (permalink / raw)
To: Hongwei Zhang
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-aspeed, Bartosz Golaszewski, Andrew Jeffery,
linux-kernel@vger.kernel.org, Ard Biesheuvel, Russell King,
Mike Rapoport, open list:GPIO SUBSYSTEM, Rob Herring,
Joel Stanley, Benjamin Gaignard, Mauro Carvalho Chehab,
Doug Anderson, Andrew Morton, Linux ARM, Masahiro Yamada
In-Reply-To: <1569351740-6285-1-git-send-email-hongweiz@ami.com>
On Tue, Sep 24, 2019 at 9:02 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> The related SGPIO driver has been accepted and merged into v5.4:
> _http://patchwork.ozlabs.org/patch/1150357/
Oh what a mess, it didn't add the necessary code into Kconfig
and Makefile, also names it sgpio-gpio.c when everything
else is named gpio-sgpio.c.
I guess I have to fix it up. My fault for missing.
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] arm: move pcibios_report_status to <asm/pci.h>
From: Ben Dooks @ 2019-09-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
In-Reply-To: <20190925141604.23364-1-ben.dooks@codethink.co.uk>
Move the pcibios_report_status to <asm/pci.h> include to remove the
following sparse warning and to remove the extra definition in the
footbrdige dc21285.c driver:
arch/arm/kernel/bios32.c:59:6: warning: symbol 'pcibios_report_status' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/include/asm/pci.h | 2 ++
| 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
index 0abd389cf0ec..68e6f25784a4 100644
--- a/arch/arm/include/asm/pci.h
+++ b/arch/arm/include/asm/pci.h
@@ -27,5 +27,7 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
+extern void pcibios_report_status(unsigned int status_mask, int warn);
+
#endif /* __KERNEL__ */
#endif
--git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index 8b81a17f675d..416462e3f5d6 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -31,7 +31,6 @@
PCI_STATUS_PARITY) << 16)
extern int setup_arm_irq(int, struct irqaction *);
-extern void pcibios_report_status(u_int status_mask, int warn);
static unsigned long
dc21285_base_address(struct pci_bus *bus, unsigned int devfn)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] arm: arch_timer: include <asm/arch_timer.h>
From: Ben Dooks @ 2019-09-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
In-Reply-To: <20190925141604.23364-1-ben.dooks@codethink.co.uk>
The arch_timer_arch_init is defined in <asm/arch_timer.h> so include
that to fix the following sparse error:
arch/arm/kernel/arch_timer.c:31:12: warning: symbol 'arch_timer_arch_init' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/kernel/arch_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index c125582de2e7..b5e217907686 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -10,6 +10,7 @@
#include <linux/errno.h>
#include <asm/delay.h>
+#include <asm/arch_timer.h>
#include <clocksource/arm_arch_timer.h>
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] arm: make unexported items static
From: Ben Dooks @ 2019-09-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
Fixup the following sparse warnings by making the functions and structures
static.
arch/arm/mm/dma-mapping.c:1562:6: warning: symbol '__arm_iommu_free_attrs' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1586:6: warning: symbol 'arm_iommu_free_attrs' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1592:6: warning: symbol 'arm_coherent_iommu_free_attrs' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1716:5: warning: symbol 'arm_coherent_iommu_map_sg' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1734:5: warning: symbol 'arm_iommu_map_sg' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1767:6: warning: symbol 'arm_coherent_iommu_unmap_sg' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1784:6: warning: symbol 'arm_iommu_unmap_sg' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1798:6: warning: symbol 'arm_iommu_sync_sg_for_cpu' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:1816:6: warning: symbol 'arm_iommu_sync_sg_for_device' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:2018:26: warning: symbol 'iommu_ops' was not declared. Should it be static?
arch/arm/mm/dma-mapping.c:2040:26: warning: symbol 'iommu_coherent_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/mm/dma-mapping.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7d042d5c43e3..54d2dd55363a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1559,7 +1559,7 @@ static int arm_coherent_iommu_mmap_attrs(struct device *dev,
* free a page as defined by the above mapping.
* Must not be called with IRQs disabled.
*/
-void __arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
+static void __arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t handle, unsigned long attrs, int coherent_flag)
{
struct page **pages;
@@ -1583,13 +1583,14 @@ void __arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
__iommu_free_buffer(dev, pages, size, attrs);
}
-void arm_iommu_free_attrs(struct device *dev, size_t size,
- void *cpu_addr, dma_addr_t handle, unsigned long attrs)
+static void arm_iommu_free_attrs(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t handle,
+ unsigned long attrs)
{
__arm_iommu_free_attrs(dev, size, cpu_addr, handle, attrs, NORMAL);
}
-void arm_coherent_iommu_free_attrs(struct device *dev, size_t size,
+static void arm_coherent_iommu_free_attrs(struct device *dev, size_t size,
void *cpu_addr, dma_addr_t handle, unsigned long attrs)
{
__arm_iommu_free_attrs(dev, size, cpu_addr, handle, attrs, COHERENT);
@@ -1713,7 +1714,7 @@ static int __iommu_map_sg(struct device *dev, struct scatterlist *sg, int nents,
* possible) and tagged with the appropriate dma address and length. They are
* obtained via sg_dma_{address,length}.
*/
-int arm_coherent_iommu_map_sg(struct device *dev, struct scatterlist *sg,
+static int arm_coherent_iommu_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir, unsigned long attrs)
{
return __iommu_map_sg(dev, sg, nents, dir, attrs, true);
@@ -1731,7 +1732,7 @@ int arm_coherent_iommu_map_sg(struct device *dev, struct scatterlist *sg,
* tagged with the appropriate dma address and length. They are obtained via
* sg_dma_{address,length}.
*/
-int arm_iommu_map_sg(struct device *dev, struct scatterlist *sg,
+static int arm_iommu_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir, unsigned long attrs)
{
return __iommu_map_sg(dev, sg, nents, dir, attrs, false);
@@ -1764,8 +1765,8 @@ static void __iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
* Unmap a set of streaming mode DMA translations. Again, CPU access
* rules concerning calls here are the same as for dma_unmap_single().
*/
-void arm_coherent_iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction dir,
+static void arm_coherent_iommu_unmap_sg(struct device *dev,
+ struct scatterlist *sg, int nents, enum dma_data_direction dir,
unsigned long attrs)
{
__iommu_unmap_sg(dev, sg, nents, dir, attrs, true);
@@ -1781,9 +1782,10 @@ void arm_coherent_iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
* Unmap a set of streaming mode DMA translations. Again, CPU access
* rules concerning calls here are the same as for dma_unmap_single().
*/
-void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
- enum dma_data_direction dir,
- unsigned long attrs)
+static void arm_iommu_unmap_sg(struct device *dev,
+ struct scatterlist *sg, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
{
__iommu_unmap_sg(dev, sg, nents, dir, attrs, false);
}
@@ -1795,7 +1797,8 @@ void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
* @nents: number of buffers to map (returned from dma_map_sg)
* @dir: DMA transfer direction (same as was passed to dma_map_sg)
*/
-void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
+static void arm_iommu_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sg,
int nents, enum dma_data_direction dir)
{
struct scatterlist *s;
@@ -1813,7 +1816,8 @@ void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
* @nents: number of buffers to map (returned from dma_map_sg)
* @dir: DMA transfer direction (same as was passed to dma_map_sg)
*/
-void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
+static void arm_iommu_sync_sg_for_device(struct device *dev,
+ struct scatterlist *sg,
int nents, enum dma_data_direction dir)
{
struct scatterlist *s;
@@ -2015,7 +2019,7 @@ static void arm_iommu_sync_single_for_device(struct device *dev,
__dma_page_cpu_to_dev(page, offset, size, dir);
}
-const struct dma_map_ops iommu_ops = {
+static const struct dma_map_ops iommu_ops = {
.alloc = arm_iommu_alloc_attrs,
.free = arm_iommu_free_attrs,
.mmap = arm_iommu_mmap_attrs,
@@ -2037,7 +2041,7 @@ const struct dma_map_ops iommu_ops = {
.dma_supported = arm_dma_supported,
};
-const struct dma_map_ops iommu_coherent_ops = {
+static const struct dma_map_ops iommu_coherent_ops = {
.alloc = arm_coherent_iommu_alloc_attrs,
.free = arm_coherent_iommu_free_attrs,
.mmap = arm_coherent_iommu_mmap_attrs,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] arm: fix missing declartion of module_frob_arch_sections
From: Ben Dooks @ 2019-09-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
In-Reply-To: <20190925141604.23364-1-ben.dooks@codethink.co.uk>
The module_frob_arch_sections function is missing the header declaration
which is in <linux/moduleloader.h> so include that to fix the following
sparse warning:
arch/arm/kernel/module-plts.c:188:5: warning: symbol 'module_frob_arch_sections' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/kernel/module-plts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/module-plts.c b/arch/arm/kernel/module-plts.c
index b647741c0ab0..6e626abaefc5 100644
--- a/arch/arm/kernel/module-plts.c
+++ b/arch/arm/kernel/module-plts.c
@@ -7,6 +7,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sort.h>
+#include <linux/moduleloader.h>
#include <asm/cache.h>
#include <asm/opcodes.h>
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] clk: hisilicon: fix sparse warnings in clk-hi3670.c
From: Ben Dooks @ 2019-09-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
Fix the following warnings from sparse by removing the 0 initialiser
that is actually a pointer.
drivers/clk/hisilicon/clk-hi3670.c:298:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:300:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:302:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:304:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:306:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:308:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:310:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:312:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:314:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:316:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:318:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:320:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:322:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:324:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:326:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:328:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:330:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:332:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:334:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:336:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:338:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:340:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:342:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:344:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:346:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:348:65: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:350:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:352:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:488:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:490:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:492:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:494:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:496:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:498:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:500:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:502:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:504:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:506:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:508:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:510:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:512:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:514:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:516:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:518:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:520:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:522:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:524:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:526:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:528:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:530:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:532:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:534:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:536:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:538:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:611:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:614:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:616:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:653:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:655:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:657:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:659:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:661:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:663:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:665:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:735:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:737:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:739:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:741:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:743:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:745:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:802:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:804:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:806:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:808:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:810:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:812:69: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/clk/hisilicon/clk-hi3670.c | 152 ++++++++++++++---------------
1 file changed, 76 insertions(+), 76 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hi3670.c b/drivers/clk/hisilicon/clk-hi3670.c
index fd8c837a6ea3..4d05a71683a5 100644
--- a/drivers/clk/hisilicon/clk-hi3670.c
+++ b/drivers/clk/hisilicon/clk-hi3670.c
@@ -295,61 +295,61 @@ static const struct hisi_gate_clock hi3670_crgctrl_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_crgctrl_gate_clks[] = {
{ HI3670_AUTODIV_SYSBUS, "autodiv_sysbus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_AUTODIV_EMMC0BUS, "autodiv_emmc0bus", "autodiv_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 1, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 1, CLK_GATE_HIWORD_MASK, },
{ HI3670_PCLK_ANDGT_MMC1_PCIE, "pclk_andgt_mmc1_pcie", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xf8, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xf8, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_VCODECBUS_GT, "clk_gate_vcodecbus_gt", "clk_mux_vcodecbus",
- CLK_SET_RATE_PARENT, 0x0F0, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F0, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SD, "clk_andgt_sd", "clk_mux_sd_pll",
- CLK_SET_RATE_PARENT, 0xF4, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_SD_SYS_GT, "clk_sd_sys_gt", "clkin_sys",
- CLK_SET_RATE_PARENT, 0xF4, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SDIO, "clk_andgt_sdio", "clk_mux_sdio_pll",
- CLK_SET_RATE_PARENT, 0xF4, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_SDIO_SYS_GT, "clk_sdio_sys_gt", "clkin_sys",
- CLK_SET_RATE_PARENT, 0xF4, 6, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 6, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_A53HPM_ANDGT, "clk_a53hpm_andgt", "clk_mux_a53hpm",
- CLK_SET_RATE_PARENT, 0x0F4, 7, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F4, 7, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_320M_PLL_GT, "clk_320m_pll_gt", "clk_mux_320m",
- CLK_SET_RATE_PARENT, 0xF8, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UARTH, "clk_andgt_uarth", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 11, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 11, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UARTL, "clk_andgt_uartl", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UART0, "clk_andgt_uart0", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SPI, "clk_andgt_spi", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_PCIEAXI, "clk_andgt_pcieaxi", "clk_mux_pcieaxi",
- CLK_SET_RATE_PARENT, 0xfc, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xfc, 15, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_DIV_AO_ASP_GT, "clk_div_ao_asp_gt", "clk_mux_ao_asp",
- CLK_SET_RATE_PARENT, 0xF4, 4, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 4, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_CSI_TRANS, "clk_gate_csi_trans", "clk_ppll2",
- CLK_SET_RATE_PARENT, 0xF4, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_DSI_TRANS, "clk_gate_dsi_trans", "clk_ppll2",
- CLK_SET_RATE_PARENT, 0xF4, 1, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 1, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_PTP, "clk_andgt_ptp", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF8, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_OUT0, "clk_andgt_out0", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0xF0, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_OUT1, "clk_andgt_out1", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0xF0, 11, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 11, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLKGT_DP_AUDIO_PLL_AO, "clkgt_dp_audio_pll_ao", "clk_ppll6",
- CLK_SET_RATE_PARENT, 0xF8, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 15, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_VDEC, "clk_andgt_vdec", "clk_mux_vdec",
- CLK_SET_RATE_PARENT, 0xF0, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_VENC, "clk_andgt_venc", "clk_mux_venc",
- CLK_SET_RATE_PARENT, 0xF0, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_ANGT, "clk_isp_snclk_angt", "clk_div_a53hpm",
- CLK_SET_RATE_PARENT, 0x108, 2, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 2, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_RXDPHY, "clk_andgt_rxdphy", "clk_div_a53hpm",
- CLK_SET_RATE_PARENT, 0x0F0, 12, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F0, 12, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_ICS, "clk_andgt_ics", "clk_mux_ics",
- CLK_SET_RATE_PARENT, 0xf0, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xf0, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_AUTODIV_DMABUS, "autodiv_dmabus", "autodiv_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 3, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -485,57 +485,57 @@ static const struct hisi_mux_clock hi3670_crgctrl_mux_clks[] = {
static const struct hisi_divider_clock hi3670_crgctrl_divider_clks[] = {
{ HI3670_CLK_DIV_CFGBUS, "clk_div_cfgbus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0xEC, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xEC, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_MMC0BUS, "clk_div_mmc0bus", "autodiv_emmc0bus",
- CLK_SET_RATE_PARENT, 0x0EC, 2, 1, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0EC, 2, 1, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_MMC1BUS, "clk_div_mmc1bus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0x0EC, 3, 1, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0EC, 3, 1, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_PCLK_DIV_MMC1_PCIE, "pclk_div_mmc1_pcie", "pclk_andgt_mmc1_pcie",
- CLK_SET_RATE_PARENT, 0xb4, 6, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xb4, 6, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VCODECBUS, "clk_div_vcodecbus", "clk_gate_vcodecbus_gt",
- CLK_SET_RATE_PARENT, 0x0BC, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0BC, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SD, "clk_div_sd", "clk_andgt_sd",
- CLK_SET_RATE_PARENT, 0xB8, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB8, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SDIO, "clk_div_sdio", "clk_andgt_sdio",
- CLK_SET_RATE_PARENT, 0xC0, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC0, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UARTH, "clk_div_uarth", "clk_andgt_uarth",
- CLK_SET_RATE_PARENT, 0xB0, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 12, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UARTL, "clk_div_uartl", "clk_andgt_uartl",
- CLK_SET_RATE_PARENT, 0xB0, 8, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 8, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UART0, "clk_div_uart0", "clk_andgt_uart0",
- CLK_SET_RATE_PARENT, 0xB0, 4, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 4, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_I2C, "clk_div_i2c", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xE8, 4, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xE8, 4, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SPI, "clk_div_spi", "clk_andgt_spi",
- CLK_SET_RATE_PARENT, 0xC4, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC4, 12, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_PCIEAXI, "clk_div_pcieaxi", "clk_andgt_pcieaxi",
- CLK_SET_RATE_PARENT, 0xb4, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xb4, 0, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_AO_ASP, "clk_div_ao_asp", "clk_div_ao_asp_gt",
- CLK_SET_RATE_PARENT, 0x108, 6, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 6, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CSI_TRANS, "clk_div_csi_trans", "clk_gate_csi_trans",
- CLK_SET_RATE_PARENT, 0xD4, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD4, 0, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_DSI_TRANS, "clk_div_dsi_trans", "clk_gate_dsi_trans",
- CLK_SET_RATE_PARENT, 0xD4, 10, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD4, 10, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_PTP, "clk_div_ptp", "clk_andgt_ptp",
- CLK_SET_RATE_PARENT, 0xD8, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD8, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT0_PLL, "clk_div_clkout0_pll", "clk_andgt_out0",
- CLK_SET_RATE_PARENT, 0xe0, 4, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xe0, 4, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT1_PLL, "clk_div_clkout1_pll", "clk_andgt_out1",
- CLK_SET_RATE_PARENT, 0xe0, 10, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xe0, 10, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLKDIV_DP_AUDIO_PLL_AO, "clkdiv_dp_audio_pll_ao", "clkgt_dp_audio_pll_ao",
- CLK_SET_RATE_PARENT, 0xBC, 11, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xBC, 11, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VDEC, "clk_div_vdec", "clk_andgt_vdec",
- CLK_SET_RATE_PARENT, 0xC4, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC4, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VENC, "clk_div_venc", "clk_andgt_venc",
- CLK_SET_RATE_PARENT, 0xC0, 8, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC0, 8, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV0, "clk_isp_snclk_div0", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x108, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV1, "clk_isp_snclk_div1", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x10C, 14, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x10C, 14, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV2, "clk_isp_snclk_div2", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x10C, 11, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x10C, 11, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_ICS, "clk_div_ics", "clk_andgt_ics",
- CLK_SET_RATE_PARENT, 0xE4, 9, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xE4, 9, 6, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_pmuctrl */
@@ -608,12 +608,12 @@ static const struct hisi_gate_clock hi3670_sctrl_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_sctrl_gate_clks[] = {
{ HI3670_CLK_ANDGT_IOPERI, "clk_andgt_ioperi", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x270, 6, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x270, 6, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLKANDGT_ASP_SUBSYS_PERI, "clkandgt_asp_subsys_peri",
"clk_ppll0",
- CLK_SET_RATE_PARENT, 0x268, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x268, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANGT_ASP_SUBSYS, "clk_angt_asp_subsys", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x258, 0, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x258, 0, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -650,19 +650,19 @@ static const struct hisi_mux_clock hi3670_sctrl_mux_clks[] = {
static const struct hisi_divider_clock hi3670_sctrl_divider_clks[] = {
{ HI3670_CLK_DIV_AOBUS, "clk_div_aobus", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x254, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UFS_SUBSYS, "clk_div_ufs_subsys", "clk_mux_ufs_subsys",
- CLK_SET_RATE_PARENT, 0x274, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x274, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_IOPERI, "clk_div_ioperi", "clk_andgt_ioperi",
- CLK_SET_RATE_PARENT, 0x270, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x270, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT0_TCXO, "clk_div_clkout0_tcxo", "clkin_sys",
- CLK_SET_RATE_PARENT, 0x254, 6, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 6, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT1_TCXO, "clk_div_clkout1_tcxo", "clkin_sys",
- CLK_SET_RATE_PARENT, 0x254, 9, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 9, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ASP_SUBSYS_PERI_DIV, "clk_asp_subsys_peri_div", "clkandgt_asp_subsys_peri",
- CLK_SET_RATE_PARENT, 0x268, 0, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x268, 0, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_ASP_SUBSYS, "clk_div_asp_subsys", "clk_angt_asp_subsys",
- CLK_SET_RATE_PARENT, 0x250, 0, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x250, 0, 3, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_iomcu */
@@ -732,17 +732,17 @@ static const struct hisi_gate_clock hi3670_media1_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_media1_gate_clks[] = {
{ HI3670_CLK_GATE_VIVOBUS_ANDGT, "clk_gate_vivobus_andgt", "clk_mux_vivobus",
- CLK_SET_RATE_PARENT, 0x84, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_EDC0, "clk_andgt_edc0", "clk_mux_edc0",
- CLK_SET_RATE_PARENT, 0x84, 7, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 7, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_LDI0, "clk_andgt_ldi0", "clk_mux_ldi0",
- CLK_SET_RATE_PARENT, 0x84, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_LDI1, "clk_andgt_ldi1", "clk_mux_ldi1",
- CLK_SET_RATE_PARENT, 0x84, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_MMBUF_PLL_ANDGT, "clk_mmbuf_pll_andgt", "clk_sw_mmbuf",
- CLK_SET_RATE_PARENT, 0x84, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_PCLK_MMBUF_ANDGT, "pclk_mmbuf_andgt", "aclk_div_mmbuf",
- CLK_SET_RATE_PARENT, 0x84, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 15, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -799,17 +799,17 @@ static const struct hisi_mux_clock hi3670_media1_mux_clks[] = {
static const struct hisi_divider_clock hi3670_media1_divider_clks[] = {
{ HI3670_CLK_DIV_VIVOBUS, "clk_div_vivobus", "clk_gate_vivobus_andgt",
- CLK_SET_RATE_PARENT, 0x74, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x74, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_EDC0, "clk_div_edc0", "clk_andgt_edc0",
- CLK_SET_RATE_PARENT, 0x68, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x68, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_LDI0, "clk_div_ldi0", "clk_andgt_ldi0",
- CLK_SET_RATE_PARENT, 0x60, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x60, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_LDI1, "clk_div_ldi1", "clk_andgt_ldi1",
- CLK_SET_RATE_PARENT, 0x64, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x64, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_ACLK_DIV_MMBUF, "aclk_div_mmbuf", "clk_mmbuf_pll_andgt",
- CLK_SET_RATE_PARENT, 0x7C, 10, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x7C, 10, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_PCLK_DIV_MMBUF, "pclk_div_mmbuf", "pclk_mmbuf_andgt",
- CLK_SET_RATE_PARENT, 0x78, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x78, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_media2 */
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] clk: hisilicon: fix sparse warnings in clk-hi3670.c
From: Ben Dooks @ 2019-09-25 14:17 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ben Dooks, Russell King
Fix the following warnings from sparse by removing the 0 initialiser
that is actually a pointer.
drivers/clk/hisilicon/clk-hi3670.c:298:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:300:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:302:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:304:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:306:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:308:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:310:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:312:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:314:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:316:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:318:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:320:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:322:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:324:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:326:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:328:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:330:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:332:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:334:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:336:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:338:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:340:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:342:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:344:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:346:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:348:65: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:350:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:352:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:488:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:490:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:492:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:494:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:496:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:498:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:500:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:502:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:504:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:506:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:508:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:510:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:512:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:514:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:516:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:518:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:520:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:522:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:524:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:526:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:528:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:530:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:532:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:534:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:536:71: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:538:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:611:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:614:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:616:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:653:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:655:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:657:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:659:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:661:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:663:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:665:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:735:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:737:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:739:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:741:63: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:743:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:745:64: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:802:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:804:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:806:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:808:69: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:810:70: warning: Using plain integer as NULL pointer
drivers/clk/hisilicon/clk-hi3670.c:812:69: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/clk/hisilicon/clk-hi3670.c | 152 ++++++++++++++---------------
1 file changed, 76 insertions(+), 76 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hi3670.c b/drivers/clk/hisilicon/clk-hi3670.c
index fd8c837a6ea3..4d05a71683a5 100644
--- a/drivers/clk/hisilicon/clk-hi3670.c
+++ b/drivers/clk/hisilicon/clk-hi3670.c
@@ -295,61 +295,61 @@ static const struct hisi_gate_clock hi3670_crgctrl_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_crgctrl_gate_clks[] = {
{ HI3670_AUTODIV_SYSBUS, "autodiv_sysbus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_AUTODIV_EMMC0BUS, "autodiv_emmc0bus", "autodiv_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 1, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 1, CLK_GATE_HIWORD_MASK, },
{ HI3670_PCLK_ANDGT_MMC1_PCIE, "pclk_andgt_mmc1_pcie", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xf8, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xf8, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_VCODECBUS_GT, "clk_gate_vcodecbus_gt", "clk_mux_vcodecbus",
- CLK_SET_RATE_PARENT, 0x0F0, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F0, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SD, "clk_andgt_sd", "clk_mux_sd_pll",
- CLK_SET_RATE_PARENT, 0xF4, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_SD_SYS_GT, "clk_sd_sys_gt", "clkin_sys",
- CLK_SET_RATE_PARENT, 0xF4, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SDIO, "clk_andgt_sdio", "clk_mux_sdio_pll",
- CLK_SET_RATE_PARENT, 0xF4, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_SDIO_SYS_GT, "clk_sdio_sys_gt", "clkin_sys",
- CLK_SET_RATE_PARENT, 0xF4, 6, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 6, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_A53HPM_ANDGT, "clk_a53hpm_andgt", "clk_mux_a53hpm",
- CLK_SET_RATE_PARENT, 0x0F4, 7, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F4, 7, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_320M_PLL_GT, "clk_320m_pll_gt", "clk_mux_320m",
- CLK_SET_RATE_PARENT, 0xF8, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UARTH, "clk_andgt_uarth", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 11, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 11, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UARTL, "clk_andgt_uartl", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_UART0, "clk_andgt_uart0", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_SPI, "clk_andgt_spi", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF4, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_PCIEAXI, "clk_andgt_pcieaxi", "clk_mux_pcieaxi",
- CLK_SET_RATE_PARENT, 0xfc, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xfc, 15, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_DIV_AO_ASP_GT, "clk_div_ao_asp_gt", "clk_mux_ao_asp",
- CLK_SET_RATE_PARENT, 0xF4, 4, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 4, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_CSI_TRANS, "clk_gate_csi_trans", "clk_ppll2",
- CLK_SET_RATE_PARENT, 0xF4, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_GATE_DSI_TRANS, "clk_gate_dsi_trans", "clk_ppll2",
- CLK_SET_RATE_PARENT, 0xF4, 1, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF4, 1, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_PTP, "clk_andgt_ptp", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xF8, 5, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 5, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_OUT0, "clk_andgt_out0", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0xF0, 10, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 10, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_OUT1, "clk_andgt_out1", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0xF0, 11, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 11, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLKGT_DP_AUDIO_PLL_AO, "clkgt_dp_audio_pll_ao", "clk_ppll6",
- CLK_SET_RATE_PARENT, 0xF8, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF8, 15, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_VDEC, "clk_andgt_vdec", "clk_mux_vdec",
- CLK_SET_RATE_PARENT, 0xF0, 13, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 13, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_VENC, "clk_andgt_venc", "clk_mux_venc",
- CLK_SET_RATE_PARENT, 0xF0, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xF0, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_ANGT, "clk_isp_snclk_angt", "clk_div_a53hpm",
- CLK_SET_RATE_PARENT, 0x108, 2, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 2, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_RXDPHY, "clk_andgt_rxdphy", "clk_div_a53hpm",
- CLK_SET_RATE_PARENT, 0x0F0, 12, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0F0, 12, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_ICS, "clk_andgt_ics", "clk_mux_ics",
- CLK_SET_RATE_PARENT, 0xf0, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xf0, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_AUTODIV_DMABUS, "autodiv_dmabus", "autodiv_sysbus",
- CLK_SET_RATE_PARENT, 0x404, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x404, 3, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -485,57 +485,57 @@ static const struct hisi_mux_clock hi3670_crgctrl_mux_clks[] = {
static const struct hisi_divider_clock hi3670_crgctrl_divider_clks[] = {
{ HI3670_CLK_DIV_CFGBUS, "clk_div_cfgbus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0xEC, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xEC, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_MMC0BUS, "clk_div_mmc0bus", "autodiv_emmc0bus",
- CLK_SET_RATE_PARENT, 0x0EC, 2, 1, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0EC, 2, 1, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_MMC1BUS, "clk_div_mmc1bus", "clk_div_sysbus",
- CLK_SET_RATE_PARENT, 0x0EC, 3, 1, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0EC, 3, 1, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_PCLK_DIV_MMC1_PCIE, "pclk_div_mmc1_pcie", "pclk_andgt_mmc1_pcie",
- CLK_SET_RATE_PARENT, 0xb4, 6, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xb4, 6, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VCODECBUS, "clk_div_vcodecbus", "clk_gate_vcodecbus_gt",
- CLK_SET_RATE_PARENT, 0x0BC, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x0BC, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SD, "clk_div_sd", "clk_andgt_sd",
- CLK_SET_RATE_PARENT, 0xB8, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB8, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SDIO, "clk_div_sdio", "clk_andgt_sdio",
- CLK_SET_RATE_PARENT, 0xC0, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC0, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UARTH, "clk_div_uarth", "clk_andgt_uarth",
- CLK_SET_RATE_PARENT, 0xB0, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 12, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UARTL, "clk_div_uartl", "clk_andgt_uartl",
- CLK_SET_RATE_PARENT, 0xB0, 8, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 8, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UART0, "clk_div_uart0", "clk_andgt_uart0",
- CLK_SET_RATE_PARENT, 0xB0, 4, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xB0, 4, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_I2C, "clk_div_i2c", "clk_div_320m",
- CLK_SET_RATE_PARENT, 0xE8, 4, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xE8, 4, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_SPI, "clk_div_spi", "clk_andgt_spi",
- CLK_SET_RATE_PARENT, 0xC4, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC4, 12, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_PCIEAXI, "clk_div_pcieaxi", "clk_andgt_pcieaxi",
- CLK_SET_RATE_PARENT, 0xb4, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xb4, 0, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_AO_ASP, "clk_div_ao_asp", "clk_div_ao_asp_gt",
- CLK_SET_RATE_PARENT, 0x108, 6, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 6, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CSI_TRANS, "clk_div_csi_trans", "clk_gate_csi_trans",
- CLK_SET_RATE_PARENT, 0xD4, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD4, 0, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_DSI_TRANS, "clk_div_dsi_trans", "clk_gate_dsi_trans",
- CLK_SET_RATE_PARENT, 0xD4, 10, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD4, 10, 5, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_PTP, "clk_div_ptp", "clk_andgt_ptp",
- CLK_SET_RATE_PARENT, 0xD8, 0, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xD8, 0, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT0_PLL, "clk_div_clkout0_pll", "clk_andgt_out0",
- CLK_SET_RATE_PARENT, 0xe0, 4, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xe0, 4, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT1_PLL, "clk_div_clkout1_pll", "clk_andgt_out1",
- CLK_SET_RATE_PARENT, 0xe0, 10, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xe0, 10, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLKDIV_DP_AUDIO_PLL_AO, "clkdiv_dp_audio_pll_ao", "clkgt_dp_audio_pll_ao",
- CLK_SET_RATE_PARENT, 0xBC, 11, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xBC, 11, 4, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VDEC, "clk_div_vdec", "clk_andgt_vdec",
- CLK_SET_RATE_PARENT, 0xC4, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC4, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_VENC, "clk_div_venc", "clk_andgt_venc",
- CLK_SET_RATE_PARENT, 0xC0, 8, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xC0, 8, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV0, "clk_isp_snclk_div0", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x108, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x108, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV1, "clk_isp_snclk_div1", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x10C, 14, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x10C, 14, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ISP_SNCLK_DIV2, "clk_isp_snclk_div2", "clk_isp_snclk_fac",
- CLK_SET_RATE_PARENT, 0x10C, 11, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x10C, 11, 2, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_ICS, "clk_div_ics", "clk_andgt_ics",
- CLK_SET_RATE_PARENT, 0xE4, 9, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0xE4, 9, 6, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_pmuctrl */
@@ -608,12 +608,12 @@ static const struct hisi_gate_clock hi3670_sctrl_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_sctrl_gate_clks[] = {
{ HI3670_CLK_ANDGT_IOPERI, "clk_andgt_ioperi", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x270, 6, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x270, 6, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLKANDGT_ASP_SUBSYS_PERI, "clkandgt_asp_subsys_peri",
"clk_ppll0",
- CLK_SET_RATE_PARENT, 0x268, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x268, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANGT_ASP_SUBSYS, "clk_angt_asp_subsys", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x258, 0, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x258, 0, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -650,19 +650,19 @@ static const struct hisi_mux_clock hi3670_sctrl_mux_clks[] = {
static const struct hisi_divider_clock hi3670_sctrl_divider_clks[] = {
{ HI3670_CLK_DIV_AOBUS, "clk_div_aobus", "clk_ppll0",
- CLK_SET_RATE_PARENT, 0x254, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_UFS_SUBSYS, "clk_div_ufs_subsys", "clk_mux_ufs_subsys",
- CLK_SET_RATE_PARENT, 0x274, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x274, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_IOPERI, "clk_div_ioperi", "clk_andgt_ioperi",
- CLK_SET_RATE_PARENT, 0x270, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x270, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT0_TCXO, "clk_div_clkout0_tcxo", "clkin_sys",
- CLK_SET_RATE_PARENT, 0x254, 6, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 6, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_CLKOUT1_TCXO, "clk_div_clkout1_tcxo", "clkin_sys",
- CLK_SET_RATE_PARENT, 0x254, 9, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x254, 9, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_ASP_SUBSYS_PERI_DIV, "clk_asp_subsys_peri_div", "clkandgt_asp_subsys_peri",
- CLK_SET_RATE_PARENT, 0x268, 0, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x268, 0, 3, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_ASP_SUBSYS, "clk_div_asp_subsys", "clk_angt_asp_subsys",
- CLK_SET_RATE_PARENT, 0x250, 0, 3, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x250, 0, 3, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_iomcu */
@@ -732,17 +732,17 @@ static const struct hisi_gate_clock hi3670_media1_gate_sep_clks[] = {
static const struct hisi_gate_clock hi3670_media1_gate_clks[] = {
{ HI3670_CLK_GATE_VIVOBUS_ANDGT, "clk_gate_vivobus_andgt", "clk_mux_vivobus",
- CLK_SET_RATE_PARENT, 0x84, 3, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 3, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_EDC0, "clk_andgt_edc0", "clk_mux_edc0",
- CLK_SET_RATE_PARENT, 0x84, 7, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 7, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_LDI0, "clk_andgt_ldi0", "clk_mux_ldi0",
- CLK_SET_RATE_PARENT, 0x84, 9, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 9, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_ANDGT_LDI1, "clk_andgt_ldi1", "clk_mux_ldi1",
- CLK_SET_RATE_PARENT, 0x84, 8, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 8, CLK_GATE_HIWORD_MASK, },
{ HI3670_CLK_MMBUF_PLL_ANDGT, "clk_mmbuf_pll_andgt", "clk_sw_mmbuf",
- CLK_SET_RATE_PARENT, 0x84, 14, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 14, CLK_GATE_HIWORD_MASK, },
{ HI3670_PCLK_MMBUF_ANDGT, "pclk_mmbuf_andgt", "aclk_div_mmbuf",
- CLK_SET_RATE_PARENT, 0x84, 15, CLK_GATE_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x84, 15, CLK_GATE_HIWORD_MASK, },
};
static const char *const
@@ -799,17 +799,17 @@ static const struct hisi_mux_clock hi3670_media1_mux_clks[] = {
static const struct hisi_divider_clock hi3670_media1_divider_clks[] = {
{ HI3670_CLK_DIV_VIVOBUS, "clk_div_vivobus", "clk_gate_vivobus_andgt",
- CLK_SET_RATE_PARENT, 0x74, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x74, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_EDC0, "clk_div_edc0", "clk_andgt_edc0",
- CLK_SET_RATE_PARENT, 0x68, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x68, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_LDI0, "clk_div_ldi0", "clk_andgt_ldi0",
- CLK_SET_RATE_PARENT, 0x60, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x60, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_CLK_DIV_LDI1, "clk_div_ldi1", "clk_andgt_ldi1",
- CLK_SET_RATE_PARENT, 0x64, 0, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x64, 0, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_ACLK_DIV_MMBUF, "aclk_div_mmbuf", "clk_mmbuf_pll_andgt",
- CLK_SET_RATE_PARENT, 0x7C, 10, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x7C, 10, 6, CLK_DIVIDER_HIWORD_MASK, },
{ HI3670_PCLK_DIV_MMBUF, "pclk_div_mmbuf", "pclk_mmbuf_andgt",
- CLK_SET_RATE_PARENT, 0x78, 0, 2, CLK_DIVIDER_HIWORD_MASK, 0, },
+ CLK_SET_RATE_PARENT, 0x78, 0, 2, CLK_DIVIDER_HIWORD_MASK, },
};
/* clk_media2 */
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: clock: meson: add A1 clock controller bindings
From: Jerome Brunet @ 2019-09-25 14:29 UTC (permalink / raw)
To: Jian Hu, Neil Armstrong
Cc: Rob Herring, Jianxin Pan, devicetree, Martin Blumenstingl,
Kevin Hilman, Michael Turquette, linux-kernel, Stephen Boyd,
Jian Hu, Qiufang Dai, linux-amlogic, linux-clk, linux-arm-kernel
In-Reply-To: <1569411888-98116-2-git-send-email-jian.hu@amlogic.com>
On Wed 25 Sep 2019 at 19:44, Jian Hu <jian.hu@amlogic.com> wrote:
In addition to the comment expressed by Stephen on patch 2
> Add the documentation to support Amlogic A1 clock driver,
> and add A1 clock controller bindings.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
> ---
> .../devicetree/bindings/clock/amlogic,a1-clkc.yaml | 65 +++++++++++++
> include/dt-bindings/clock/a1-clkc.h | 102 +++++++++++++++++++++
> 2 files changed, 167 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
> create mode 100644 include/dt-bindings/clock/a1-clkc.h
>
> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
> new file mode 100644
> index 0000000..f012eb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> +/*
> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
> + */
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/clock/amlogic,a1-clkc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson A1 Clock Control Unit Device Tree Bindings
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> + - Jerome Brunet <jbrunet@baylibre.com>
> + - Jian Hu <jian.hu@jian.hu.com>
> +
> +properties:
> + compatible:
> + - enum:
> + - amlogic,a1-clkc
> +
> + reg:
> + minItems: 1
> + maxItems: 3
> + items:
> + - description: peripheral registers
> + - description: cpu registers
> + - description: pll registers
> +
> + reg-names:
> + items:
> + - const: peripheral
> + - const: pll
> + - const: cpu
> +
> + clocks:
> + maxItems: 1
> + items:
> + - description: Input Oscillator (usually at 24MHz)
> +
> + clock-names:
> + maxItems: 1
> + items:
> + - const: xtal
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - "#clock-cells"
> +
> +examples:
> + - |
> + clkc: clock-controller {
> + compatible = "amlogic,a1-clkc";
> + reg = <0x0 0xfe000800 0x0 0x100>,
> + <0x0 0xfe007c00 0x0 0x21c>,
> + <0x0 0xfd000080 0x0 0x20>;
> + reg-names = "peripheral", "pll", "cpu";
I'm sorry but I don't agree with this. You are trying to regroup several
controllers into one with this, and it is not OK
By the looks of it there are 3 different controllers, including one you
did not implement in the driver.
> + clocks = <&xtal;
> + clock-names = "xtal";
> + #clock-cells = <1>;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Catalin Marinas @ 2019-09-25 14:38 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Marc Zyngier, Anshuman Khandual, linux-kernel,
Matthew Wilcox, linux-mm, Jérôme Glisse, James Morse,
linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner, nd,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190925025922.176362-2-justin.he@arm.com>
On Wed, Sep 25, 2019 at 10:59:20AM +0800, Jia He wrote:
> We unconditionally set the HW_AFDBM capability and only enable it on
> CPUs which really have the feature. But sometimes we need to know
> whether this cpu has the capability of HW AF. So decouple AF from
> DBM by new helper cpu_has_hw_af().
>
> Signed-off-by: Jia He <justin.he@arm.com>
> Suggested-by: Suzuki Poulose <Suzuki.Poulose@arm.com>
> Reported-by: kbuild test robot <lkp@intel.com>
Which bug did the kbuild robot actually report? I'd drop this line.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Catalin Marinas @ 2019-09-25 14:42 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Marc Zyngier, Anshuman Khandual, linux-kernel,
Matthew Wilcox, linux-mm, Jérôme Glisse, James Morse,
linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner, nd,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190925025922.176362-4-justin.he@arm.com>
On Wed, Sep 25, 2019 at 10:59:22AM +0800, Jia He wrote:
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
> in case there can be some obscure use-case.(by Kirill)
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Signed-off-by: Jia He <justin.he@arm.com>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> mm/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 84 insertions(+), 15 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..a0a381b36ff2 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef arch_faults_on_old_pte
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return false;
> +}
> +#endif
> +
> static int __init disable_randmaps(char *s)
> {
> randomize_va_space = 0;
> @@ -2140,32 +2147,82 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
> return same;
> }
>
> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> +static inline bool cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
> + bool ret;
> + void *kaddr;
> + void __user *uaddr;
> + bool force_mkyoung;
> + struct vm_area_struct *vma = vmf->vma;
> + struct mm_struct *mm = vma->vm_mm;
> + unsigned long addr = vmf->address;
> +
> debug_dma_assert_idle(src);
>
> + if (likely(src)) {
> + copy_user_highpage(dst, src, addr, vma);
> + return true;
> + }
> +
> /*
> * If the source page was a PFN mapping, we don't have
> * a "struct page" for it. We do a best-effort copy by
> * just copying from the original user address. If that
> * fails, we just zero-fill it. Live with it.
> */
> - if (unlikely(!src)) {
> - void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + kaddr = kmap_atomic(dst);
> + uaddr = (void __user *)(addr & PAGE_MASK);
> +
> + /*
> + * On architectures with software "accessed" bits, we would
> + * take a double page fault, so mark it accessed here.
> + */
> + force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf->orig_pte);
> + if (force_mkyoung) {
> + pte_t entry;
> +
> + vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, &vmf->ptl);
> + if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> + /*
> + * Other thread has already handled the fault
> + * and we don't need to do anything. If it's
> + * not the case, the fault will be triggered
> + * again on the same address.
> + */
> + ret = false;
> + goto pte_unlock;
> + }
> +
> + entry = pte_mkyoung(vmf->orig_pte);
> + if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
> + update_mmu_cache(vma, addr, vmf->pte);
> + }
>
> + /*
> + * This really shouldn't fail, because the page is there
> + * in the page tables. But it might just be unreadable,
> + * in which case we just give up and fill the result with
> + * zeroes.
> + */
> + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> /*
> - * This really shouldn't fail, because the page is there
> - * in the page tables. But it might just be unreadable,
> - * in which case we just give up and fill the result with
> - * zeroes.
> + * Give a warn in case there can be some obscure
> + * use-case
> */
> - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> - clear_page(kaddr);
> - kunmap_atomic(kaddr);
> - flush_dcache_page(dst);
> - } else
> - copy_user_highpage(dst, src, va, vma);
> + WARN_ON_ONCE(1);
> + clear_page(kaddr);
> + }
> +
> + ret = true;
> +
> +pte_unlock:
> + if (force_mkyoung)
> + pte_unmap_unlock(vmf->pte, vmf->ptl);
> + kunmap_atomic(kaddr);
> + flush_dcache_page(dst);
> +
> + return ret;
> }
>
> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> @@ -2318,7 +2375,19 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> vmf->address);
> if (!new_page)
> goto oom;
> - cow_user_page(new_page, old_page, vmf->address, vma);
> +
> + if (!cow_user_page(new_page, old_page, vmf)) {
> + /*
> + * COW failed, if the fault was solved by other,
> + * it's fine. If not, userspace would re-fault on
> + * the same address and we will handle the fault
> + * from the second attempt.
> + */
> + put_page(new_page);
> + if (old_page)
> + put_page(old_page);
> + return 0;
> + }
> }
>
> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
> --
> 2.17.1
>
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
From: Nicolas Saenz Julienne @ 2019-09-25 14:52 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Matthias Brugger, linux-arm-msm, freedreno,
linux-wireless, linux-kernel@vger.kernel.org, dri-devel, etnaviv,
linux-tegra, Florian Fainelli, Stefan Wahren, james.quinlan,
linux-pci, open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM,
xen-devel, Dan Williams, Robin Murphy, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <CAL_Jsq+v+svTyna7UzQdRVqfNc5Z_bgWzxNRXv7-Wqv3NwDu2g@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2723 bytes --]
On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
> On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Hi All,
> > this series tries to address one of the issues blocking us from
> > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
> > devices not represented in DT which sit behind a PCI bus fail to get the
> > bus' DMA addressing constraints.
> >
> > This is due to the fact that of_dma_configure() assumes it's receiving a
> > DT node representing the device being configured, as opposed to the PCIe
> > bridge node we currently pass. This causes the code to directly jump
> > into PCI's parent node when checking for 'dma-ranges' and misses
> > whatever was set there.
> >
> > To address this I create a new API in OF - inspired from Robin Murphys
> > original proposal[2] - which accepts a bus DT node as it's input in
> > order to configure a device's DMA constraints. The changes go deep into
> > of/address.c's implementation, as a device being having a DT node
> > assumption was pretty strong.
> >
> > On top of this work, I also cleaned up of_dma_configure() removing its
> > redundant arguments and creating an alternative function for the special
> > cases
> > not applicable to either the above case or the default usage.
> >
> > IMO the resulting functions are more explicit. They will probably
> > surface some hacky usages that can be properly fixed as I show with the
> > DT fixes on the Layerscape platform.
> >
> > This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
> > on a Seattle AMD board.
>
> Humm, I've been working on this issue too. Looks similar though yours
> has a lot more churn and there's some other bugs I've found.
That's good news, and yes now that I see it, some stuff on my series is overly
complicated. Specially around of_translate_*().
On top of that, you removed in of_dma_get_range():
- /*
- * At least empty ranges has to be defined for parent node if
- * DMA is supported
- */
- if (!ranges)
- break;
Which I assumed was bound to the standard and makes things easier.
> Can you test out this branch[1]. I don't have any h/w needing this,
> but wrote a unittest and tested with modified QEMU.
I reviewed everything, I did find a minor issue, see the patch attached.
Also I tested your branch both on an RPi4, with a PCI device that depends on
these changes and by comparing the OF debugs logs on a Layerscape board which
uses dma-ranges, dma-coherent and IOMMU. All works as expected.
Will you send this series for v5.5? Please keep me in the loop, I'll review and
test the final version.
Regards,
Nicolas
[-- Attachment #1.1.2: 0001-of-device-do-not-bail-of_dma_configure-when-force_dm.patch --]
[-- Type: text/x-patch, Size: 959 bytes --]
From 26d51853c25c04c28dbc09061951a93c102dabcd Mon Sep 17 00:00:00 2001
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Date: Wed, 25 Sep 2019 16:26:57 +0200
Subject: [PATCH] of: device: do not bail of_dma_configure() when force_dma is
set
Some Xen devices call of_dma_configure() without an actual DT node in
order for it to set its 'dma_ops'. That's the original intent of
'force_dma', honor that behaviour.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index a45261e21144..7bc00f72468f 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -100,8 +100,6 @@ int of_dma_configure(struct device *dev, struct device_node *parent, bool force_
np = dev->of_node;
if (!np)
np = parent;
- if (!np)
- return -ENODEV;
ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
if (ret < 0) {
--
2.23.0
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox