* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Timur Tabi @ 2019-08-01 3:49 UTC (permalink / raw)
To: Jeffrey Hugo, Stephen Boyd, Lee Jones, Linus Walleij, Mark Brown
Cc: Bjorn Andersson, Lina Iyer, Linux ARM,
Kernel Build Reports Mailman List
In-Reply-To: <cbbe381e-a154-ced1-fbcb-9db2135e4e5b@codeaurora.org>
On 7/31/19 12:58 PM, Jeffrey Hugo wrote:
>>>
>>> Timur/Stephen: any ideas?
>
> Timur's CAF account is no longer valid, I added his @kernel one.
Delete everything specific to the QDF2400.
Qualcomm has made it very clear that they have no interest in developing
ARM server chips. No QDF2400 system ever made it to official production.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: Jeremy Linton @ 2019-08-01 3:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: lorenzo.pieralisi, catalin.marinas, rjw, Jeremy Linton,
linux-acpi, sudeep.holla, will, lenb
In-Reply-To: <20190801034634.26913-1-jeremy.linton@arm.com>
ACPI 6.3 adds a flag to the CPU node to indicate whether
the given PE is a thread. Add a function to return that
information for a given linux logical CPU.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/pptt.c | 54 +++++++++++++++++++++++++++++++++++++++++++-
include/linux/acpi.h | 5 ++++
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index 1e7ac0bd0d3a..84718f6cb741 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -540,6 +540,44 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag)
return retval;
}
+/**
+ * check_acpi_cpu_flag() - Determine if CPU node has a flag set
+ * @cpu: Kernel logical CPU number
+ * @rev: The PPTT revision defining the flag
+ * @flag: The flag itself
+ *
+ * Check the node representing a CPU for a given flag.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found or
+ * the table revision isn't new enough.
+ * 1, any passed flag set
+ * 0, flag unset
+ */
+static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct acpi_pptt_processor *cpu_node = NULL;
+ int ret = -ENOENT;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ acpi_pptt_warn_missing();
+ return ret;
+ }
+
+ if (table->revision >= rev)
+ cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+
+ if (cpu_node)
+ ret = (cpu_node->flags & flag) != 0;
+
+ acpi_put_table(table);
+
+ return ret;
+}
+
/**
* acpi_find_last_cache_level() - Determines the number of cache levels for a PE
* @cpu: Kernel logical CPU number
@@ -604,6 +642,21 @@ int cache_setup_acpi(unsigned int cpu)
return status;
}
+/**
+ * acpi_pptt_cpu_is_thread() - Determine if CPU is a thread
+ * @cpu: Kernel logical CPU number
+ *
+ *
+ * Return: 1, a thread
+ * 0, not a thread
+ * -ENOENT ,if the PPTT doesn't exist, the CPU cannot be found or
+ * the table revision isn't new enough.
+ */
+int acpi_pptt_cpu_is_thread(unsigned int cpu)
+{
+ return check_acpi_cpu_flag(cpu, 2, ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD);
+}
+
/**
* find_acpi_cpu_topology() - Determine a unique topology value for a given CPU
* @cpu: Kernel logical CPU number
@@ -664,7 +717,6 @@ int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
return ret;
}
-
/**
* find_acpi_cpu_topology_package() - Determine a unique CPU package value
* @cpu: Kernel logical CPU number
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 9426b9aaed86..9d0e20a2ac83 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1302,11 +1302,16 @@ static inline int lpit_read_residency_count_address(u64 *address)
#endif
#ifdef CONFIG_ACPI_PPTT
+int acpi_pptt_cpu_is_thread(unsigned int cpu);
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
#else
+static inline int acpi_pptt_cpu_is_thread(unsigned int cpu)
+{
+ return -EINVAL;
+}
static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
{
return -EINVAL;
--
2.21.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 v4 0/2] arm64/PPTT ACPI 6.3 thread flag support
From: Jeremy Linton @ 2019-08-01 3:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: lorenzo.pieralisi, catalin.marinas, rjw, Jeremy Linton,
linux-acpi, sudeep.holla, will, lenb
ACPI 6.3 adds a flag to the CPU node to indicate whether
the given CPU is a thread. Add a function to return that
information for a given linux logical CPU and then utilize
it while building the arm64 topology.
v3->v4: Remove table revision cache as this code path is only
called during boot and there aren't any
indications that it presents a perf issue.
Rebase to 5.3
v2->v3: Clarify and tweak the return from check_acpi_cpu_flag()
Cache the PPTT table revision to avoid repeat
acpi_table_get/put calls in the case of
missing or old PPTT tables.
v1->v2:
Return ENOENT instead on ENONET.
Jeremy Linton (2):
ACPI/PPTT: Add support for ACPI 6.3 thread flag
arm64: topology: Use PPTT to determine if PE is a thread
arch/arm64/kernel/topology.c | 8 ++++--
drivers/acpi/pptt.c | 54 +++++++++++++++++++++++++++++++++++-
include/linux/acpi.h | 5 ++++
3 files changed, 63 insertions(+), 4 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/2] arm64: topology: Use PPTT to determine if PE is a thread
From: Jeremy Linton @ 2019-08-01 3:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: lorenzo.pieralisi, catalin.marinas, rjw, Jeremy Linton,
linux-acpi, sudeep.holla, will, lenb
In-Reply-To: <20190801034634.26913-1-jeremy.linton@arm.com>
ACPI 6.3 adds a thread flag to represent if a CPU/PE is
actually a thread. Given that the MPIDR_MT bit may not
represent this information consistently on homogeneous machines
we should prefer the PPTT flag if its available.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/topology.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 0825c4a856e3..cbbedb53cf06 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -346,11 +346,9 @@ void remove_cpu_topology(unsigned int cpu)
*/
static int __init parse_acpi_topology(void)
{
- bool is_threaded;
+ int is_threaded;
int cpu, topology_id;
- is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
-
for_each_possible_cpu(cpu) {
int i, cache_id;
@@ -358,6 +356,10 @@ static int __init parse_acpi_topology(void)
if (topology_id < 0)
return topology_id;
+ is_threaded = acpi_pptt_cpu_is_thread(cpu);
+ if (is_threaded < 0)
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
if (is_threaded) {
cpu_topology[cpu].thread_id = topology_id;
topology_id = find_acpi_cpu_topology(cpu, 1);
--
2.21.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 v4.4 V2 11/43] arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
From: Viresh Kumar @ 2019-08-01 3:38 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190731123711.GB39768@lakrids.cambridge.arm.com>
On 31-07-19, 13:37, Mark Rutland wrote:
> On Fri, Jul 12, 2019 at 10:57:59AM +0530, Viresh Kumar wrote:
> > From: Will Deacon <will.deacon@arm.com>
> >
> > commit f71c2ffcb20dd8626880747557014bb9a61eb90e upstream.
> >
> > Like we've done for get_user and put_user, ensure that user pointers
> > are masked before invoking the underlying __arch_{clear,copy_*}_user
> > operations.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > [ v4.4: fixup for v4.4 style uaccess primitives ]
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> [...]
>
> > static inline unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n)
> > {
> > kasan_check_write(to, n);
> > - return __arch_copy_from_user(to, from, n);
> > + return __arch_copy_from_user(to, __uaccess_mask_ptr(from), n);
> > +
> > }
> >
> > static inline unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n)
> > {
> > kasan_check_read(from, n);
> > - return __arch_copy_to_user(to, from, n);
> > + return __arch_copy_to_user(__uaccess_mask_ptr(to), from, n);
> > +
> > }
>
> Can we please drop the trailing whitespace from each of these? That
> wasn't in the upstreadm commit or v4.9.y.
That was a mistake on my end it seems. Fixed now. Thanks.
--
viresh
_______________________________________________
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.4 V2 15/43] arm64: Move cpu_die_early to smp.c
From: Viresh Kumar @ 2019-08-01 3:35 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190731123532.GA39768@lakrids.cambridge.arm.com>
On 31-07-19, 13:35, Mark Rutland wrote:
> On Fri, Jul 12, 2019 at 10:58:03AM +0530, Viresh Kumar wrote:
> > From: Suzuki K Poulose <suzuki.poulose@arm.com>
> >
> > commit fce6361fe9b0caeba0c05b7d72ceda406f8780df upstream.
> >
> > This patch moves cpu_die_early to smp.c, where it fits better.
> > No functional changes, except for adding the necessary checks
> > for CONFIG_HOTPLUG_CPU.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > [ Viresh: Resolved rebase conflict ]
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> > +void cpu_die_early(void)
>
> > + asm(
> > + "1: wfe\n"
> > + " wfi\n"
> > + " b 1b");
> > +}
>
> Rather than open-coding this loop differently from upstream and the
> v4.9.y backport, please backport commit:
>
> c4bc34d20273db69 ("arm64: Add a helper for parking CPUs in a loop")
>
> ... as a prerequisite of this patch.
Done, thanks.
--
viresh
_______________________________________________
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 v2 2/2] ARM: dts: aspeed: Add Mihawk BMC platform
From: Andrew Jeffery @ 2019-08-01 3:10 UTC (permalink / raw)
To: Ben Pai, Rob Herring, mark.rutland, Joel Stanley, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
Cc: wangat
In-Reply-To: <20190731074742.23456-1-Ben_Pai@wistron.com>
Hi Ben,
Comments inline below. Also apologies for the IBM/IPS mixup in the previous
review, I've been corrected :)
On Wed, 31 Jul 2019, at 17:17, Ben Pai wrote:
> The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> Signed-off-by: Ben Pai <Ben_Pai@wistron.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 907 ++++++++++++++++++++
> 2 files changed, 908 insertions(+)
> create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index eb6de52c1936..262345544359 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1281,5 +1281,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-opp-vesnin.dtb \
> aspeed-bmc-opp-witherspoon.dtb \
> aspeed-bmc-opp-zaius.dtb \
> + aspeed-bmc-opp-mihawk.dtb \
This is a sorted list, please put it in the right spot.
> aspeed-bmc-portwell-neptune.dtb \
> aspeed-bmc-quanta-q71l.dtb
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> new file mode 100755
> index 000000000000..913c94326f3f
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> @@ -0,0 +1,907 @@
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/leds/leds-pca955x.h>
> +
> +/ {
> + model = "Mihawk BMC";
> + compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
> +
> +
> + chosen {
> + stdout-path = &uart5;
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@80000000 {
> + reg = <0x80000000 0x20000000>; /* address and size of RAM(512MB) */
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@98000000 {
> + no-map;
> + reg = <0x98000000 0x04000000>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x01000000>;
> + alignment = <0x01000000>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x02000000>; /* 32MM */
> + alignment = <0x01000000>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = <&gpio ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(F, 6)>;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(J, 2)>;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(Z, 2)>;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = <&gpio ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(Z, 0)>;
> + };
> + id-button {
> + label = "id-button";
> + gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(F, 1)>;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
Delete the #address-cells property (both it and the #size-cells properties
are not needed for the gpio-keys-polled node).
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = <&pca9552 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = <&pca9552 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = <&pca9552 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = <&pca9552 12 GPIO_ACTIVE_LOW>;
> + linux,code = <12>;
> + };
> +
> + fan4-presence {
> + label = "fan4-presence";
> + gpios = <&pca9552 13 GPIO_ACTIVE_LOW>;
> + linux,code = <13>;
> + };
> +
> + fan5-presence {
> + label = "fan5-presence";
> + gpios = <&pca9552 14 GPIO_ACTIVE_LOW>;
> + linux,code = <14>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_LOW>;
> + };
> +
> + power {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&gpio ASPEED_GPIO(AA, 1) GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-id {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-g {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&gpio ASPEED_GPIO(AA, 4) GPIO_ACTIVE_LOW>;
> + };
> +
> + rear-ok {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&gpio ASPEED_GPIO(Y, 0) GPIO_ACTIVE_LOW>;
> + };
> +
> + fan0 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan1 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan2 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan3 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan4 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + fan5 {
> + retain-state-shutdown;
> + default-state = "keep";
> + gpios = <&pca9552 5 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> + no-gpio-delays;
> +
> + clock-gpios = <&gpio ASPEED_GPIO(E, 6) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(E, 7) GPIO_ACTIVE_HIGH>;
> + mux-gpios = <&gpio ASPEED_GPIO(E, 5) GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> + iio-hwmon-12v {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 0>;
> + };
> +
> + iio-hwmon-5v {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 1>;
> + };
> +
> + iio-hwmon-3v {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 2>;
> + };
> +
> + iio-hwmon-vdd0 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 3>;
> + };
> +
> + iio-hwmon-vdd1 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 4>;
> + };
> +
> + iio-hwmon-vcs0 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 5>;
> + };
> +
> + iio-hwmon-vcs1 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 6>;
> + };
> +
> + iio-hwmon-vdn0 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 7>;
> + };
> +
> + iio-hwmon-vdn1 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 8>;
> + };
> +
> + iio-hwmon-vio0 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 9>;
> + };
> +
> + iio-hwmon-vio1 {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 10>;
> + };
> +
> + iio-hwmon-vddra {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 11>;
> + };
> +
> + iio-hwmon-vddrb {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 13>;
> + };
> +
> + iio-hwmon-vddrc {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 14>;
> + };
> +
> + iio-hwmon-vddrd {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 15>;
> + };
> +
> + iio-hwmon-battery {
> + compatible = "iio-hwmon";
> + io-channels = <&adc 12>;
> + };
> +};
> +
> +&pwm_tacho {
> + status = "okay";
> + /*compatible = "aspeed,ast2500-pwm-tacho";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x1e786000 0x1000>;
> + clocks = <&pwm_tacho_fixed_clk>;*/
I missed this commented block last time? Please remove it.
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default
> + &pinctrl_pwm2_default &pinctrl_pwm3_default
> + &pinctrl_pwm4_default &pinctrl_pwm5_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x00>;
> + };
> +
> + fan@1 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x01>;
> + };
> +
> + fan@2 {
> + reg = <0x02>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x02>;
> + };
> +
> + fan@3 {
> + reg = <0x03>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x03>;
> + };
> +
> + fan@4 {
> + reg = <0x04>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x04>;
> + };
> +
> + fan@5 {
> + reg = <0x05>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x05>;
> + };
> +
> + fan@6 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x06>;
> + };
> +
> + fan@7 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x07>;
> + };
> +
> + fan@8 {
> + reg = <0x02>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan@9 {
> + reg = <0x03>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan@10 {
> + reg = <0x04>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> + };
> +
> + fan@11 {
> + reg = <0x05>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
> + };
> +};
> +
> +&fmc {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + label = "bmc";
> + m25p,fast-read;
> + spi-max-frequency = <50000000>;
> + partitions {
> + #address-cells = < 1 >;
> + #size-cells = < 1 >;
> + compatible = "fixed-partitions";
> + u-boot@0 {
> + reg = < 0 0x60000 >;
> + label = "u-boot";
> + };
> + u-boot-env@60000 {
> + reg = < 0x60000 0x20000 >;
> + label = "u-boot-env";
> + };
> + obmc-ubi@80000 {
> + reg = < 0x80000 0x1F80000 >;
> + label = "obmc-ubi";
> + };
> + };
> + };
> + flash@1 {
> + status = "okay";
> + label = "alt-bmc";
> + m25p,fast-read;
> + spi-max-frequency = <50000000>;
> + partitions {
> + #address-cells = < 1 >;
> + #size-cells = < 1 >;
> + compatible = "fixed-partitions";
> + u-boot@0 {
> + reg = < 0 0x60000 >;
> + label = "alt-u-boot";
> + };
> + u-boot-env@60000 {
> + reg = < 0x60000 0x20000 >;
> + label = "alt-u-boot-env";
> + };
> + obmc-ubi@80000 {
> + reg = < 0x80000 0x1F80000 >;
> + label = "alt-obmc-ubi";
> + };
> + };
> + };
> +};
> +
> +&spi1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1_default>;
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> + spi-max-frequency = <100000000>;
> + };
> +};
> +
> +&lpc_ctrl {
> + status = "okay";
> + memory-region = <&flash_memory>;
> + flash = <&spi1>;
> +};
> +
> +&uart1 {
> + /* Rear RS-232 connector */
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_txd1_default
> + &pinctrl_rxd1_default
> + &pinctrl_nrts1_default
> + &pinctrl_ndtr1_default
> + &pinctrl_ndsr1_default
> + &pinctrl_ncts1_default
> + &pinctrl_ndcd1_default
> + &pinctrl_nri1_default>;
> +};
> +
> +&uart2 {
> + /* APSS */
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_txd2_default &pinctrl_rxd2_default>;
> +};
> +
> +&uart5 {
> + status = "okay";
> +};
> +
> +&mac0 {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rmii1_default>;
> + use-ncsi;
> +};
> +
> +&mac1 {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
> +};
> +
> +&i2c0 {
> + status = "disabled";
> +};
> +
> +&i2c1 {
> + status = "disabled";
> +};
> +
> +&i2c2 {
> + status = "okay";
> +
> + /* SAMTEC P0 */
> + /* SAMTEC P1 */
> +
> +};
> +
> +&i2c3 {
> + status = "okay";
> +
> + /* APSS */
> + /* CPLD */
> +
> + /* PCA9516 (repeater) ->
> + * CLK Buffer 9FGS9092
> + * CLK Buffer 9DBL0651BKILFT
> + * CLK Buffer 9DBL0651BKILFT
> + * Power Supply 0
> + * Power Supply 1
> + * PCA 9552 LED
> + */
> +
> + power-supply@58 {
> + compatible = "ibm,cffps1";
> + reg = <0x58>;
> + };
> +
> + power-supply@5b {
> + compatible = "ibm,cffps1";
> + reg = <0x5b>;
> + };
> +
> + pca9552: pca9552@60 {
> + compatible = "nxp,pca9552";
> + reg = <0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio@0 {
> + reg = <0>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@1 {
> + reg = <1>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@2 {
> + reg = <2>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@3 {
> + reg = <3>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@4 {
> + reg = <4>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@5 {
> + reg = <5>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@6 {
> + reg = <6>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@7 {
> + reg = <7>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@8 {
> + reg = <8>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@9 {
> + reg = <9>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@10 {
> + reg = <10>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@11 {
> + reg = <11>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@12 {
> + reg = <12>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@13 {
> + reg = <13>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@14 {
> + reg = <14>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> + gpio@15 {
> + reg = <15>;
> + type = <PCA955X_TYPE_GPIO>;
> + };
> +
> + };
> +
> +};
> +
> +&i2c4 {
> + status = "okay";
> +
> + /* CP0 VDD & VCS : IR35221 */
> + /* CP0 VDN : IR35221 */
> + /* CP0 VIO : IR38064 */
> + /* CP0 VDDR : PXM1330 */
> +
> + ir35221@70 {
> + compatible = "infineon,ir35221";
> + reg = <0x70>;
> + };
> +
> + ir35221@72 {
> + compatible = "infineon,ir35221";
> + reg = <0x72>;
> + };
> +
> +};
> +
> +&i2c5 {
> + status = "okay";
> +
> + /* CP0 VDD & VCS : IR35221 */
> + /* CP0 VDN : IR35221 */
> + /* CP0 VIO : IR38064 */
> + /* CP0 VDDR : PXM1330 */
> +
> + ir35221@70 {
> + compatible = "infineon,ir35221";
> + reg = <0x70>;
> + };
> +
> + ir35221@72 {
> + compatible = "infineon,ir35221";
> + reg = <0x72>;
> + };
> +
> +};
> +
> +&i2c6 {
> + status = "okay";
> +
> + /* pca9548 -> NVMe1 to 8 */
> +
> + pca9548@70 {
> + compatible = "nxp,pca9548";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + };
> +
> +};
> +
> +&i2c7 {
> + status = "okay";
> +
> + /* pca9548 -> NVMe9 to 16 */
> +
> + pca9548@70 {
> + compatible = "nxp,pca9548";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + };
> +
> +};
> +
> +&i2c8 {
> + status = "okay";
> +
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
> +};
> +
> +&i2c9 {
> + status = "okay";
> +
> + /* pca9545 Riser ->
> + * PCIe x8 Slot3
> + * PCIe x16 slot4
> + * PCIe x8 slot5
> + * I2C BMC RISER PCA9554
> + * BMC SCL/SDA PCA9554
> + * PCA9554
> + */
> +
> + /* pca9545 ->
> + * PCIe x16 Slot1
> + * PCIe x8 slot2
> + * PEX8748
> + */
> +
> + pca9545riser@70 {
> + compatible = "nxp,pca9545";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> +
> + i2c-mux-idle-disconnect;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pca9545@71 {
> + compatible = "nxp,pca9545";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x71>;
> +
> + i2c-mux-idle-disconnect;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +};
> +
> +&i2c10 {
> + status = "okay";
> +
> + /* pca9545 Riser ->
> + * PCIe x8 Slot8
> + * PCIe x16 slot9
> + * PCIe x8 slot10
> + * I2C BMC RISER PCA9554
> + * BMC SCL/SDA PCA9554
> + * PCA9554
> + */
> +
> + /* pca9545 ->
> + * PCIe x16 Slot1
> + * PCIe x8 slot2
> + * PEX8748
> + */
> +
> + pca9545riser@70 {
> + compatible = "nxp,pca9545";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> +
> + i2c-mux-idle-disconnect;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pca9545@71 {
> + compatible = "nxp,pca9545";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x71>;
> +
> + i2c-mux-idle-disconnect;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +};
> +
> +&i2c11 {
> + status = "okay";
> +
> + /* TPM */
> + /* RTC RX8900CE */
> + /* FPGA for power sequence */
> + /* TMP275A */
> + /* TMP275A */
> + /* EMC1462 */
> +
> + tpm@57 {
> + compatible = "infineon,slb9645tt";
> + reg = <0x57>;
> + };
> +
> + rtc@32 {
> + compatible = "epson,rx8900";
> + reg = <0x32>;
> + };
> +
> + tmp275@48 {
> + compatible = "ti,tmp275";
> + reg = <0x48>;
> + };
> +
> + tmp275@49 {
> + compatible = "ti,tmp275";
> + reg = <0x49>;
> + };
> +
> + /* chip emc1462 use emc1403 driver */
> + emc1403@4c {
> + compatible = "smsc,emc1403";
> + reg = <0x4c>;
> + };
> +
> +};
> +
> +&i2c12 {
> + status = "okay";
> +
> + /* pca9545 ->
> + * SAS BP1
> + * SAS BP2
> + * NVMe BP
> + * M.2 riser
> + */
> +
> + pca9545@70 {
> + compatible = "nxp,pca9545";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
> + };
> +
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
> + };
> +
> + i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> +
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> +
> + tmp275@48 {
> + compatible = "ti,tmp275";
> + reg = <0x48>;
> + };
> + };
> +
> + };
> +
> +};
> +
> +&i2c13 {
> + status = "okay";
> +
> + /* pca9548 ->
> + * NVMe BP
> + * NVMe HDD17 to 24
> + */
> +
> + pca9548@70 {
> + compatible = "nxp,pca9548";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + };
> +};
> +
> +&vuart {
> + status = "okay";
> +};
> +
> +&gfx {
> + status = "okay";
> + memory-region = <&gfx_memory>;
> +};
> +
> +&adc {
> + status = "okay";
You're still missing the pinmux properties for the ADC lines being used.
Please add them.
Cheers,
Andrew
> +};
> +
> +&wdt1 {
> + aspeed,reset-type = "none";
> + aspeed,external-signal;
> + aspeed,ext-push-pull;
> + aspeed,ext-active-high;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdtrst1_default>;
> +};
> +
> +&wdt2 {
> + aspeed,alt-boot;
> +};
> +
> +&ibt {
> + status = "okay";
> +};
> +
> +&vhub {
> + status = "okay";
> +};
> +
> +&video {
> + status = "okay";
> + memory-region = <&video_engine_memory>;
> +};
> +
> +#include "ibm-power9-dual.dtsi"
> +
> --
> 2.17.1
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
> This email contains confidential or legally privileged information and
> is for the sole use of its intended recipient.
> Any unauthorized review, use, copying or distribution of this email or
> the content of this email is strictly prohibited.
> If you are not the intended recipient, you may reply to the sender and
> should delete this e-mail immediately.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
_______________________________________________
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 v2 3/5] arm64: atomics: avoid out-of-line ll/sc atomics
From: Boqun Feng @ 2019-08-01 3:10 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Will Deacon,
Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190731161256.22210-4-andrew.murray@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 2534 bytes --]
Hi Andrew,
On Wed, Jul 31, 2019 at 05:12:54PM +0100, Andrew Murray wrote:
[...]
> +
> +#define __lse_ll_sc_body(op, ...) \
> +({ \
> + system_uses_lse_atomics() ? \
> + __lse_##op(__VA_ARGS__) : \
> + __ll_sc_##op(__VA_ARGS__); \
> +})
> +
> +#define ATOMIC_OP(op) \
> +static inline void arch_##op(int i, atomic_t *v) \
> +{ \
> + __lse_ll_sc_body(op, i, v); \
> +}
> +
> +ATOMIC_OP(atomic_andnot)
> +ATOMIC_OP(atomic_or)
> +ATOMIC_OP(atomic_xor)
> +ATOMIC_OP(atomic_add)
> +ATOMIC_OP(atomic_and)
> +ATOMIC_OP(atomic_sub)
> +
> +
> +#define ATOMIC_FETCH_OP(name, op) \
> +static inline int arch_##op##name(int i, atomic_t *v) \
> +{ \
> + return __lse_ll_sc_body(op, i, v); \
Color me blind if I'm wrong, but should't this be:
return __lse_ll_sc_body(op##name, i, v); \
? Otherwise all variants will use the fully-ordered implementation.
> +}
> +
> +#define ATOMIC_FETCH_OPS(op) \
> + ATOMIC_FETCH_OP(_relaxed, op) \
> + ATOMIC_FETCH_OP(_acquire, op) \
> + ATOMIC_FETCH_OP(_release, op) \
> + ATOMIC_FETCH_OP( , op)
> +
> +ATOMIC_FETCH_OPS(atomic_fetch_andnot)
> +ATOMIC_FETCH_OPS(atomic_fetch_or)
> +ATOMIC_FETCH_OPS(atomic_fetch_xor)
> +ATOMIC_FETCH_OPS(atomic_fetch_add)
> +ATOMIC_FETCH_OPS(atomic_fetch_and)
> +ATOMIC_FETCH_OPS(atomic_fetch_sub)
> +ATOMIC_FETCH_OPS(atomic_add_return)
> +ATOMIC_FETCH_OPS(atomic_sub_return)
> +
> +
> +#define ATOMIC64_OP(op) \
> +static inline void arch_##op(long i, atomic64_t *v) \
> +{ \
> + __lse_ll_sc_body(op, i, v); \
> +}
> +
> +ATOMIC64_OP(atomic64_andnot)
> +ATOMIC64_OP(atomic64_or)
> +ATOMIC64_OP(atomic64_xor)
> +ATOMIC64_OP(atomic64_add)
> +ATOMIC64_OP(atomic64_and)
> +ATOMIC64_OP(atomic64_sub)
> +
> +
> +#define ATOMIC64_FETCH_OP(name, op) \
> +static inline long arch_##op##name(long i, atomic64_t *v) \
> +{ \
> + return __lse_ll_sc_body(op, i, v); \
Ditto.
Regards,
Boqun
> +}
> +
> +#define ATOMIC64_FETCH_OPS(op) \
> + ATOMIC64_FETCH_OP(_relaxed, op) \
> + ATOMIC64_FETCH_OP(_acquire, op) \
> + ATOMIC64_FETCH_OP(_release, op) \
> + ATOMIC64_FETCH_OP( , op)
> +
> +ATOMIC64_FETCH_OPS(atomic64_fetch_andnot)
> +ATOMIC64_FETCH_OPS(atomic64_fetch_or)
> +ATOMIC64_FETCH_OPS(atomic64_fetch_xor)
> +ATOMIC64_FETCH_OPS(atomic64_fetch_add)
> +ATOMIC64_FETCH_OPS(atomic64_fetch_and)
> +ATOMIC64_FETCH_OPS(atomic64_fetch_sub)
> +ATOMIC64_FETCH_OPS(atomic64_add_return)
> +ATOMIC64_FETCH_OPS(atomic64_sub_return)
> +
> +
[...]
[-- Attachment #1.2: signature.asc --]
[-- 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
* Re: [RFC 1/2] mm/sparsemem: Add vmem_altmap support in vmemmap_populate_basepages()
From: Anshuman Khandual @ 2019-08-01 3:09 UTC (permalink / raw)
To: Will Deacon
Cc: Fenghua Yu, Tony Luck, linux-ia64, Catalin Marinas, Dave Hansen,
Will Deacon, x86, linux-kernel, linux-mm, Andy Lutomirski,
Andrew Morton, linux-arm-kernel
In-Reply-To: <20190731161047.ypye54x5c5jje5sq@willie-the-truck>
On 07/31/2019 09:40 PM, Will Deacon wrote:
> On Fri, Jun 28, 2019 at 10:14:42AM +0530, Anshuman Khandual wrote:
>> Generic vmemmap_populate_basepages() is used across platforms for vmemmap
>> as standard or as fallback when huge pages mapping fails. On arm64 it is
>> used for configs with ARM64_SWAPPER_USES_SECTION_MAPS applicable both for
>> ARM64_16K_PAGES and ARM64_64K_PAGES which cannot use huge pages because of
>> alignment requirements.
>>
>> This prevents those configs from allocating from device memory for vmemap
>> mapping as vmemmap_populate_basepages() does not support vmem_altmap. This
>> enables that required support. Each architecture should evaluate and decide
>> on enabling device based base page allocation when appropriate. Hence this
>> keeps it disabled for all architectures to preserve the existing semantics.
>
> This commit message doesn't really make sense to me. There's a huge amount
> of arm64-specific detail, followed by vague references to "this" and
> "those" and "that" and I lost track of what you're trying to solve.
Hmm, will clean up.
>
> However, I puzzled through the code and I think it does make sense, so:
>
> Acked-by: Will Deacon <will@kernel.org>
>
> assuming you rewrite the commit message.
Thanks, will do.
>
> However, this has a dependency on your hot remove series which has open
> comments from Mark Rutland afaict.
Yeah it has dependency on the hot-remove series. The only outstanding issue
there being whether to call free_empty_tables() in vmemmap tear down path
or not. Mark had asked for more details regarding the implications in cases
where free_empty_tables() is called or is not called. I did evaluate those
details recently and we should be able to take a decision sooner.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 2/2] arm64/mm: Enable device memory allocation and free for vmemmap mapping
From: Anshuman Khandual @ 2019-08-01 3:03 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Will Deacon, linux-kernel,
linux-mm, linux-arm-kernel
In-Reply-To: <20190731161103.kqv3v2xlq4vnyjhp@willie-the-truck>
On 07/31/2019 09:41 PM, Will Deacon wrote:
> On Fri, Jun 28, 2019 at 10:14:43AM +0530, Anshuman Khandual wrote:
>> This enables vmemmap_populate() and vmemmap_free() functions to incorporate
>> struct vmem_altmap based device memory allocation and free requests. With
>> this device memory with specific atlmap configuration can be hot plugged
>> and hot removed as ZONE_DEVICE memory on arm64 platforms.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/mm/mmu.c | 57 ++++++++++++++++++++++++++++++++++-------------------
>> 1 file changed, 37 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 39e18d1..8867bbd 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -735,15 +735,26 @@ int kern_addr_valid(unsigned long addr)
>> }
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> -static void free_hotplug_page_range(struct page *page, size_t size)
>> +static void free_hotplug_page_range(struct page *page, size_t size,
>> + struct vmem_altmap *altmap)
>> {
>> - WARN_ON(!page || PageReserved(page));
>> - free_pages((unsigned long)page_address(page), get_order(size));
>> + if (altmap) {
>> + /*
>> + * vmemmap_populate() creates vmemmap mapping either at pte
>> + * or pmd level. Unmapping request at any other level would
>> + * be a problem.
>> + */
>> + WARN_ON((size != PAGE_SIZE) && (size != PMD_SIZE));
>> + vmem_altmap_free(altmap, size >> PAGE_SHIFT);
>> + } else {
>> + WARN_ON(!page || PageReserved(page));
>> + free_pages((unsigned long)page_address(page), get_order(size));
>> + }
>> }
>>
>> static void free_hotplug_pgtable_page(struct page *page)
>> {
>> - free_hotplug_page_range(page, PAGE_SIZE);
>> + free_hotplug_page_range(page, PAGE_SIZE, NULL);
>> }
>>
>> static void free_pte_table(pmd_t *pmdp, unsigned long addr)
>> @@ -807,7 +818,8 @@ static void free_pud_table(pgd_t *pgdp, unsigned long addr)
>> }
>>
>> static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
>> - unsigned long end, bool sparse_vmap)
>> + unsigned long end, bool sparse_vmap,
>> + struct vmem_altmap *altmap)
>
> Do you still need the sparse_vmap parameter, or can you just pass a NULL
> altmap pointer when sparse_vmap is false?
Yes, we will still require sparse_vmap parameter because vmemmap mapping
does not necessarily be created only for ZONE_DEVICE range with an altmap.
vmemmap can still be present with altmap as NULL (regular memory and device
memory without altmap) in which cases it will not be possible to
differentiate between linear and vmemmap mapping.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v7 2/2] gpio: aspeed: Add SGPIO driver
From: Andrew Jeffery @ 2019-08-01 2:59 UTC (permalink / raw)
To: Hongwei Zhang, Linus Walleij, linux-gpio
Cc: linux-arm-kernel, Bartosz Golaszewski, Joel Stanley, linux-aspeed,
linux-kernel
In-Reply-To: <1564603297-1391-3-git-send-email-hongweiz@ami.com>
On Thu, 1 Aug 2019, at 05:32, Hongwei Zhang wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Adding my Reviewed-by tag is a bit keen, I only gave it for the bindings on v6.
However, having looked over the patch you've addressed all of the issues I've
found, so you can keep it.
Andrew
> ---
> drivers/gpio/sgpio-aspeed.c | 530 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 530 insertions(+)
> create mode 100644 drivers/gpio/sgpio-aspeed.c
>
> diff --git a/drivers/gpio/sgpio-aspeed.c b/drivers/gpio/sgpio-aspeed.c
> new file mode 100644
> index 0000000..752efea
> --- /dev/null
> +++ b/drivers/gpio/sgpio-aspeed.c
> @@ -0,0 +1,530 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2019 American Megatrends International LLC.
> + *
> + * Author: Karthikeyan Mani <karthikeyanm@amiindia.co.in>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/hashtable.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +#include <linux/string.h>
> +
> +#define MAX_NR_SGPIO 80
> +
> +#define ASPEED_SGPIO_CTRL 0x54
> +
> +#define ASPEED_SGPIO_PINS_MASK GENMASK(9, 6)
> +#define ASPEED_SGPIO_CLK_DIV_MASK GENMASK(31, 16)
> +#define ASPEED_SGPIO_ENABLE BIT(0)
> +
> +struct aspeed_sgpio {
> + struct gpio_chip chip;
> + struct clk *pclk;
> + spinlock_t lock;
> + void __iomem *base;
> + uint32_t dir_in[3];
> + int irq;
> +};
> +
> +struct aspeed_sgpio_bank {
> + uint16_t val_regs;
> + uint16_t rdata_reg;
> + uint16_t irq_regs;
> + const char names[4][3];
> +};
> +
> +/*
> + * Note: The "value" register returns the input value when the GPIO is
> + * configured as an input.
> + *
> + * The "rdata" register returns the output value when the GPIO is
> + * configured as an output.
> + */
> +static const struct aspeed_sgpio_bank aspeed_sgpio_banks[] = {
> + {
> + .val_regs = 0x0000,
> + .rdata_reg = 0x0070,
> + .irq_regs = 0x0004,
> + .names = { "A", "B", "C", "D" },
> + },
> + {
> + .val_regs = 0x001C,
> + .rdata_reg = 0x0074,
> + .irq_regs = 0x0020,
> + .names = { "E", "F", "G", "H" },
> + },
> + {
> + .val_regs = 0x0038,
> + .rdata_reg = 0x0078,
> + .irq_regs = 0x003C,
> + .names = { "I", "J" },
> + },
> +};
> +
> +enum aspeed_sgpio_reg {
> + reg_val,
> + reg_rdata,
> + reg_irq_enable,
> + reg_irq_type0,
> + reg_irq_type1,
> + reg_irq_type2,
> + reg_irq_status,
> +};
> +
> +#define GPIO_VAL_VALUE 0x00
> +#define GPIO_IRQ_ENABLE 0x00
> +#define GPIO_IRQ_TYPE0 0x04
> +#define GPIO_IRQ_TYPE1 0x08
> +#define GPIO_IRQ_TYPE2 0x0C
> +#define GPIO_IRQ_STATUS 0x10
> +
> +static void __iomem *bank_reg(struct aspeed_sgpio *gpio,
> + const struct aspeed_sgpio_bank *bank,
> + const enum aspeed_sgpio_reg reg)
> +{
> + switch (reg) {
> + case reg_val:
> + return gpio->base + bank->val_regs + GPIO_VAL_VALUE;
> + case reg_rdata:
> + return gpio->base + bank->rdata_reg;
> + case reg_irq_enable:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_ENABLE;
> + case reg_irq_type0:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE0;
> + case reg_irq_type1:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE1;
> + case reg_irq_type2:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE2;
> + case reg_irq_status:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_STATUS;
> + default:
> + /* acturally if code runs to here, it's an error case */
> + BUG_ON(1);
> + }
> +}
> +
> +#define GPIO_BANK(x) ((x) >> 5)
> +#define GPIO_OFFSET(x) ((x) & 0x1f)
> +#define GPIO_BIT(x) BIT(GPIO_OFFSET(x))
> +
> +static const struct aspeed_sgpio_bank *to_bank(unsigned int offset)
> +{
> + unsigned int bank = GPIO_BANK(offset);
> +
> + WARN_ON(bank >= ARRAY_SIZE(aspeed_sgpio_banks));
> + return &aspeed_sgpio_banks[bank];
> +}
> +
> +static int aspeed_sgpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + const struct aspeed_sgpio_bank *bank = to_bank(offset);
> + unsigned long flags;
> + enum aspeed_sgpio_reg reg;
> + bool is_input;
> + int rc = 0;
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + is_input = gpio->dir_in[GPIO_BANK(offset)] & GPIO_BIT(offset);
> + reg = is_input ? reg_val : reg_rdata;
> + rc = !!(ioread32(bank_reg(gpio, bank, reg)) & GPIO_BIT(offset));
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return rc;
> +}
> +
> +static void __aspeed_sgpio_set(struct gpio_chip *gc, unsigned int
> offset, int val)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + const struct aspeed_sgpio_bank *bank = to_bank(offset);
> + void __iomem *addr;
> + u32 reg = 0;
> +
> + addr = bank_reg(gpio, bank, reg_val);
> + reg = ioread32(addr);
> +
> + if (val)
> + reg |= GPIO_BIT(offset);
> + else
> + reg &= ~GPIO_BIT(offset);
> +
> + iowrite32(reg, addr);
> +}
> +
> +static void aspeed_sgpio_set(struct gpio_chip *gc, unsigned int
> offset, int val)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + __aspeed_sgpio_set(gc, offset, val);
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +}
> +
> +static int aspeed_sgpio_dir_in(struct gpio_chip *gc, unsigned int
> offset)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> + gpio->dir_in[GPIO_BANK(offset)] |= GPIO_BIT(offset);
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return 0;
> +}
> +
> +static int aspeed_sgpio_dir_out(struct gpio_chip *gc, unsigned int
> offset, int val)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + gpio->dir_in[GPIO_BANK(offset)] &= ~GPIO_BIT(offset);
> + __aspeed_sgpio_set(gc, offset, val);
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return 0;
> +}
> +
> +static int aspeed_sgpio_get_direction(struct gpio_chip *gc, unsigned
> int offset)
> +{
> + int dir_status;
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> + dir_status = gpio->dir_in[GPIO_BANK(offset)] & GPIO_BIT(offset);
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return dir_status;
> +
> +}
> +
> +static void irqd_to_aspeed_sgpio_data(struct irq_data *d,
> + struct aspeed_sgpio **gpio,
> + const struct aspeed_sgpio_bank **bank,
> + u32 *bit, int *offset)
> +{
> + struct aspeed_sgpio *internal;
> +
> + *offset = irqd_to_hwirq(d);
> + internal = irq_data_get_irq_chip_data(d);
> + WARN_ON(!internal);
> +
> + *gpio = internal;
> + *bank = to_bank(*offset);
> + *bit = GPIO_BIT(*offset);
> +}
> +
> +static void aspeed_sgpio_irq_ack(struct irq_data *d)
> +{
> + const struct aspeed_sgpio_bank *bank;
> + struct aspeed_sgpio *gpio;
> + unsigned long flags;
> + void __iomem *status_addr;
> + int offset;
> + u32 bit;
> +
> + irqd_to_aspeed_sgpio_data(d, &gpio, &bank, &bit, &offset);
> +
> + status_addr = bank_reg(gpio, bank, reg_irq_status);
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + iowrite32(bit, status_addr);
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +}
> +
> +static void aspeed_sgpio_irq_set_mask(struct irq_data *d, bool set)
> +{
> + const struct aspeed_sgpio_bank *bank;
> + struct aspeed_sgpio *gpio;
> + unsigned long flags;
> + u32 reg, bit;
> + void __iomem *addr;
> + int offset;
> +
> + irqd_to_aspeed_sgpio_data(d, &gpio, &bank, &bit, &offset);
> + addr = bank_reg(gpio, bank, reg_irq_enable);
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + reg = ioread32(addr);
> + if (set)
> + reg |= bit;
> + else
> + reg &= ~bit;
> +
> + iowrite32(reg, addr);
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +}
> +
> +static void aspeed_sgpio_irq_mask(struct irq_data *d)
> +{
> + aspeed_sgpio_irq_set_mask(d, false);
> +}
> +
> +static void aspeed_sgpio_irq_unmask(struct irq_data *d)
> +{
> + aspeed_sgpio_irq_set_mask(d, true);
> +}
> +
> +static int aspeed_sgpio_set_type(struct irq_data *d, unsigned int type)
> +{
> + u32 type0 = 0;
> + u32 type1 = 0;
> + u32 type2 = 0;
> + u32 bit, reg;
> + const struct aspeed_sgpio_bank *bank;
> + irq_flow_handler_t handler;
> + struct aspeed_sgpio *gpio;
> + unsigned long flags;
> + void __iomem *addr;
> + int offset;
> +
> + irqd_to_aspeed_sgpio_data(d, &gpio, &bank, &bit, &offset);
> +
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_BOTH:
> + type2 |= bit;
> + /* fall through */
> + case IRQ_TYPE_EDGE_RISING:
> + type0 |= bit;
> + /* fall through */
> + case IRQ_TYPE_EDGE_FALLING:
> + handler = handle_edge_irq;
> + break;
> + case IRQ_TYPE_LEVEL_HIGH:
> + type0 |= bit;
> + /* fall through */
> + case IRQ_TYPE_LEVEL_LOW:
> + type1 |= bit;
> + handler = handle_level_irq;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> +
> + addr = bank_reg(gpio, bank, reg_irq_type0);
> + reg = ioread32(addr);
> + reg = (reg & ~bit) | type0;
> + iowrite32(reg, addr);
> +
> + addr = bank_reg(gpio, bank, reg_irq_type1);
> + reg = ioread32(addr);
> + reg = (reg & ~bit) | type1;
> + iowrite32(reg, addr);
> +
> + addr = bank_reg(gpio, bank, reg_irq_type2);
> + reg = ioread32(addr);
> + reg = (reg & ~bit) | type2;
> + iowrite32(reg, addr);
> +
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + irq_set_handler_locked(d, handler);
> +
> + return 0;
> +}
> +
> +static void aspeed_sgpio_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *ic = irq_desc_get_chip(desc);
> + struct aspeed_sgpio *data = gpiochip_get_data(gc);
> + unsigned int i, p, girq;
> + unsigned long reg;
> +
> + chained_irq_enter(ic, desc);
> +
> + for (i = 0; i < ARRAY_SIZE(aspeed_sgpio_banks); i++) {
> + const struct aspeed_sgpio_bank *bank = &aspeed_sgpio_banks[i];
> +
> + reg = ioread32(bank_reg(data, bank, reg_irq_status));
> +
> + for_each_set_bit(p, ®, 32) {
> + girq = irq_find_mapping(gc->irq.domain, i * 32 + p);
> + generic_handle_irq(girq);
> + }
> +
> + }
> +
> + chained_irq_exit(ic, desc);
> +}
> +
> +static struct irq_chip aspeed_sgpio_irqchip = {
> + .name = "aspeed-sgpio",
> + .irq_ack = aspeed_sgpio_irq_ack,
> + .irq_mask = aspeed_sgpio_irq_mask,
> + .irq_unmask = aspeed_sgpio_irq_unmask,
> + .irq_set_type = aspeed_sgpio_set_type,
> +};
> +
> +static int aspeed_sgpio_setup_irqs(struct aspeed_sgpio *gpio,
> + struct platform_device *pdev)
> +{
> + int rc, i;
> + const struct aspeed_sgpio_bank *bank;
> +
> + rc = platform_get_irq(pdev, 0);
> + if (rc < 0)
> + return rc;
> +
> + gpio->irq = rc;
> +
> + /* Disable IRQ and clear Interrupt status registers for all SPGIO
> Pins. */
> + for (i = 0; i < ARRAY_SIZE(aspeed_sgpio_banks); i++) {
> + bank = &aspeed_sgpio_banks[i];
> + /* disable irq enable bits */
> + iowrite32(0x00000000, bank_reg(gpio, bank, reg_irq_enable));
> + /* clear status bits */
> + iowrite32(0xffffffff, bank_reg(gpio, bank, reg_irq_status));
> + }
> +
> + rc = gpiochip_irqchip_add(&gpio->chip, &aspeed_sgpio_irqchip,
> + 0, handle_bad_irq, IRQ_TYPE_NONE);
> + if (rc) {
> + dev_info(&pdev->dev, "Could not add irqchip\n");
> + return rc;
> + }
> +
> + gpiochip_set_chained_irqchip(&gpio->chip, &aspeed_sgpio_irqchip,
> + gpio->irq, aspeed_sgpio_irq_handler);
> +
> + /* set IRQ settings and Enable Interrupt */
> + for (i = 0; i < ARRAY_SIZE(aspeed_sgpio_banks); i++) {
> + bank = &aspeed_sgpio_banks[i];
> + /* set falling or level-low irq */
> + iowrite32(0x00000000, bank_reg(gpio, bank, reg_irq_type0));
> + /* trigger type is edge */
> + iowrite32(0x00000000, bank_reg(gpio, bank, reg_irq_type1));
> + /* dual edge trigger mode. */
> + iowrite32(0xffffffff, bank_reg(gpio, bank, reg_irq_type2));
> + /* enable irq */
> + iowrite32(0xffffffff, bank_reg(gpio, bank, reg_irq_enable));
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_sgpio_of_table[] = {
> + { .compatible = "aspeed,ast2400-sgpio" },
> + { .compatible = "aspeed,ast2500-sgpio" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, aspeed_sgpio_of_table);
> +
> +static int __init aspeed_sgpio_probe(struct platform_device *pdev)
> +{
> + struct aspeed_sgpio *gpio;
> + u32 nr_gpios, sgpio_freq, sgpio_clk_div;
> + int rc;
> + unsigned long apb_freq;
> +
> + gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
> + if (!gpio)
> + return -ENOMEM;
> +
> + gpio->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(gpio->base))
> + return PTR_ERR(gpio->base);
> +
> + rc = of_property_read_u32(pdev->dev.of_node, "ngpios", &nr_gpios);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not read ngpios property\n");
> + return -EINVAL;
> + } else if (nr_gpios > MAX_NR_SGPIO) {
> + dev_err(&pdev->dev, "Number of GPIOs exceeds the maximum of %d:
> %d\n",
> + MAX_NR_SGPIO, nr_gpios);
> + return -EINVAL;
> + }
> +
> + rc = of_property_read_u32(pdev->dev.of_node, "bus-frequency",
> &sgpio_freq);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not read bus-frequency property\n");
> + return -EINVAL;
> + }
> +
> + gpio->pclk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(gpio->pclk)) {
> + dev_err(&pdev->dev, "devm_clk_get failed\n");
> + return PTR_ERR(gpio->pclk);
> + }
> +
> + apb_freq = clk_get_rate(gpio->pclk);
> +
> + /*
> + * From the datasheet,
> + * SGPIO period = 1/PCLK * 2 * (GPIO254[31:16] + 1)
> + * period = 2 * (GPIO254[31:16] + 1) / PCLK
> + * frequency = 1 / (2 * (GPIO254[31:16] + 1) / PCLK)
> + * frequency = PCLK / (2 * (GPIO254[31:16] + 1))
> + * frequency * 2 * (GPIO254[31:16] + 1) = PCLK
> + * GPIO254[31:16] = PCLK / (frequency * 2) - 1
> + */
> + if (sgpio_freq == 0)
> + return -EINVAL;
> +
> + sgpio_clk_div = (apb_freq / (sgpio_freq * 2)) - 1;
> +
> + if (sgpio_clk_div > (1 << 16) - 1)
> + return -EINVAL;
> +
> + iowrite32(FIELD_PREP(ASPEED_SGPIO_CLK_DIV_MASK, sgpio_clk_div) |
> + FIELD_PREP(ASPEED_SGPIO_PINS_MASK, (nr_gpios / 8)) |
> + ASPEED_SGPIO_ENABLE,
> + gpio->base + ASPEED_SGPIO_CTRL);
> +
> + spin_lock_init(&gpio->lock);
> +
> + gpio->chip.parent = &pdev->dev;
> + gpio->chip.ngpio = nr_gpios;
> + gpio->chip.direction_input = aspeed_sgpio_dir_in;
> + gpio->chip.direction_output = aspeed_sgpio_dir_out;
> + gpio->chip.get_direction = aspeed_sgpio_get_direction;
> + gpio->chip.request = NULL;
> + gpio->chip.free = NULL;
> + gpio->chip.get = aspeed_sgpio_get;
> + gpio->chip.set = aspeed_sgpio_set;
> + gpio->chip.set_config = NULL;
> + gpio->chip.label = dev_name(&pdev->dev);
> + gpio->chip.base = -1;
> +
> + /* set all SGPIO pins as input (1). */
> + memset(gpio->dir_in, 0xff, sizeof(gpio->dir_in));
> +
> + rc = devm_gpiochip_add_data(&pdev->dev, &gpio->chip, gpio);
> + if (rc < 0)
> + return rc;
> +
> + return aspeed_sgpio_setup_irqs(gpio, pdev);
> +}
> +
> +static struct platform_driver aspeed_sgpio_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .of_match_table = aspeed_sgpio_of_table,
> + },
> +};
> +
> +module_platform_driver_probe(aspeed_sgpio_driver, aspeed_sgpio_probe);
> +MODULE_DESCRIPTION("Aspeed Serial GPIO Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.7.4
>
>
_______________________________________________
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 v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-01 2:42 UTC (permalink / raw)
To: Sunil Mohan Adapa; +Cc: Maxime Ripard, Martin Ayotte, linux-arm-kernel
In-Reply-To: <20190727210307.17607-1-sunil@medhas.org>
On Sun, Jul 28, 2019 at 5:03 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
>
> A64-OLinuXino board has three variants that have eMMC support. Add support for
> eMMC on boards that have it.
>
> This patch has been tested on A64-OLinuXino-1Ge16GW with Linux 5.0 from Debain.
> Basic benchmarks using Flexible IO Tester show reasonable performance from the
> eMMC.
>
> eMMC - Random Write: 23.1MiB/s
> eMMC - Sequential Write: 74.5MiB/s
> SD Card - Random Write: 1690KiB/s
> SD Card - Sequential Write: 11.0MiB/s
>
> v2: Fix descriptions for VCC and VCCQ.
>
> [sunil@medhas.org Fix descriptions for VCC and VCCQ]
> Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
> Tested-by: Sunil Mohan Adapa <sunil@medhas.org>
>
> From: Martin Ayotte <martinayotte@gmail.com>
> Link: https://github.com/armbian/build/commit/174953de1eb09e6aa1ef7075066b573dba625398
Thanks. The patch looks good overall. The authorship is a little confusing
though. If it was initially done by Martin (CC-ed), then he should be the
author, and we should get his Signed-off-by if possible.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 1/1] nvmem: sunxi_sid: fix A64 SID controller support
From: Vasily Khoruzhick @ 2019-08-01 1:42 UTC (permalink / raw)
To: wens
Cc: Stefan Mavrodiev, Maxime Ripard, open list, linux-sunxi,
Srinivas Kandagatla,
moderated list:ARM/Allwinner sunXi SoC support
In-Reply-To: <CAGb2v64tzMypnB5Ho2A-gWPk2yYsmH9tNn+OKfb51c+d6pK=kw@mail.gmail.com>
On Wed, Jul 31, 2019 at 1:43 AM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Wed, Jul 31, 2019 at 3:15 PM Stefan Mavrodiev <stefan@olimex.com> wrote:
> >
> > Like in H3, A64 SID controller doesn't return correct data
> > when using direct access. It appears that on A64, SID needs
> > 8 bytes of word_size.
> >
> > Workaround is to enable read by registers.
I came up with identical patch while adding A64 support into
sun8i-thermal driver, so:
> >
> > Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
>
> And for single patches, you don't need to write a separate cover letter.
> Just put whatever you need to add after the "---" separator.
>
> > ---
> > drivers/nvmem/sunxi_sid.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> > index a079a80ddf2c..e26ef1bbf198 100644
> > --- a/drivers/nvmem/sunxi_sid.c
> > +++ b/drivers/nvmem/sunxi_sid.c
> > @@ -186,6 +186,7 @@ static const struct sunxi_sid_cfg sun8i_h3_cfg = {
> > static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> > .value_offset = 0x200,
> > .size = 0x100,
> > + .need_register_readout = true,
> > };
> >
> > static const struct sunxi_sid_cfg sun50i_h6_cfg = {
> > --
> > 2.17.1
> >
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAGb2v64tzMypnB5Ho2A-gWPk2yYsmH9tNn%2BOKfb51c%2Bd6pK%3Dkw%40mail.gmail.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: André Roth @ 2019-08-01 1:28 UTC (permalink / raw)
To: linux-omap
Cc: Nishanth Menon, Kevin Hilman, Thara Gopinath, Shweta Gulati,
linux-arm-kernel
In-Reply-To: <20190801012823.28730-1-neolynx@gmail.com>
From: Thara Gopinath <thara@ti.com>
Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
default expects that OMAP's I2C_SR is plugged in to TWL's I2C
and calls omap3_twl_set_sr_bit. On platforms where I2C_SR is not connected,
the board files are expected to call omap3_twl_set_sr_bit(false) to
ensure that I2C_SR path is not set for voltage control and prevent
the default behavior of omap3_twl_init.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/omap_twl.c | 60 ++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 6787f1e72c6b..1dae906128c2 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -43,8 +43,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool __initdata twl_sr_enable_autoinit;
+#define TWL4030_DCDC_GLOBAL_CFG 0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -241,6 +248,18 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ /*
+ * The smartreflex bit on twl4030 specifies if the setting of voltage
+ * is done over the I2C_SR path. Since this setting is independent of
+ * the actual usage of smartreflex AVS module, we enable TWL SR bit
+ * by default irrespective of whether smartreflex AVS module is enabled
+ * on the OMAP side or not. This is because without this bit enabled,
+ * the voltage scaling through vp forceupdate/bypass mechanism of
+ * voltage scaling will not function on TWL over I2C_SR.
+ */
+ if (!twl_sr_enable_autoinit)
+ omap3_twl_set_sr_bit(true);
+
voltdm = voltdm_lookup("mpu_iva");
omap_voltage_register_pmic(voltdm, &omap3_mpu_pmic);
@@ -249,3 +268,44 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - Set/Clear SR bit on TWL
+ * @enable: enable SR mode in twl or not
+ *
+ * If 'enable' is true, enables Smartreflex bit on TWL 4030 to make sure
+ * voltage scaling through OMAP SR works. Else, the smartreflex bit
+ * on twl4030 is cleared as there are platforms which use OMAP3 and T2 but
+ * use Synchronized Scaling Hardware Strategy (ENABLE_VMODE=1) and Direct
+ * Strategy Software Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared (enable = false).
+ *
+ * Returns 0 on sucess, error is returned if I2C read/write fails.
+ */
+int __init omap3_twl_set_sr_bit(bool enable)
+{
+ u8 temp;
+ int ret;
+ if (twl_sr_enable_autoinit)
+ pr_warning("%s: unexpected multiple calls\n", __func__);
+
+ ret = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, &temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (enable)
+ temp |= SMARTREFLEX_ENABLE;
+ else
+ temp &= ~SMARTREFLEX_ENABLE;
+
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (!ret) {
+ twl_sr_enable_autoinit = true;
+ return 0;
+ }
+err:
+ pr_err("%s: Error access to TWL4030 (%d)\n", __func__, ret);
+ return ret;
+}
--
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: [PATCH v2] arm64: Add support for relocating the kernel with RELR relocations
From: Peter Collingbourne @ 2019-08-01 1:19 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, clang-built-linux, Catalin Marinas, Ard Biesheuvel,
Nick Desaulniers, Masahiro Yamada, Linux ARM
In-Reply-To: <20190731164818.m2und6msyhlbf5oi@willie-the-truck>
On Wed, Jul 31, 2019 at 9:48 AM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Jul 12, 2019 at 12:38:46PM -0700, Peter Collingbourne wrote:
> > RELR is a relocation packing format for relative relocations.
> > The format is described in a generic-abi proposal:
> > https://groups.google.com/d/topic/generic-abi/bX460iggiKg/discussion
> >
> > The LLD linker can be instructed to pack relocations in the RELR
> > format by passing the flag --pack-dyn-relocs=relr.
> >
> > This patch adds a new config option, CONFIG_RELR. Enabling this option
> > instructs the linker to pack vmlinux's relative relocations in the RELR
> > format, and causes the kernel to apply the relocations at startup along
> > with the RELA relocations. RELA relocations still need to be applied
> > because the linker will emit RELA relative relocations if they are
> > unrepresentable in the RELR format (i.e. address not a multiple of 2).
> >
> > Enabling CONFIG_RELR reduces the size of a defconfig kernel image
> > with CONFIG_RANDOMIZE_BASE by 3.5MB/16% uncompressed, or 550KB/5%
> > compressed (lz4).
> >
> > Signed-off-by: Peter Collingbourne <pcc@google.com>
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > Changes in v2:
> > - Reverted change to RELA processing
> > - Added more comments, as requested by Nick and Will
> > - Added a feature test for NM and OBJCOPY
> > - Made CONFIG_RELR=y the default if the tools support it
> >
> > arch/arm64/Kconfig | 10 ++++
> > arch/arm64/Makefile | 4 ++
> > arch/arm64/kernel/head.S | 96 ++++++++++++++++++++++++++++++---
> > arch/arm64/kernel/vmlinux.lds.S | 9 ++++
> > init/Kconfig | 3 ++
> > scripts/tools-support-relr.sh | 16 ++++++
> > 6 files changed, 132 insertions(+), 6 deletions(-)
> > create mode 100755 scripts/tools-support-relr.sh
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 7442edbcabfc3..cf3907d21d097 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1476,6 +1476,16 @@ config RELOCATABLE
> > relocation pass at runtime even if the kernel is loaded at the
> > same address it was linked at.
> >
> > +config RELR
> > + bool "Use RELR relocation packing"
> > + depends on RELOCATABLE && TOOLS_SUPPORT_RELR
> > + default y
> > + help
> > + Store the kernel's dynamic relocations in the RELR relocation packing
> > + format. Requires a compatible linker (currently only LLD supports
>
> Drop "currently" because it will just rot
Done in v3.
> > + this feature), as well as compatible NM and OBJCOPY utilities
> > + (llvm-nm and llvm-objcopy are compatible).
> > +
> > config RANDOMIZE_BASE
> > bool "Randomize the address of the kernel image"
> > select ARM64_MODULE_PLTS if MODULES
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index bb1f1dbb34e8f..11f84450c7784 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -22,6 +22,10 @@ LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro \
> > $(call ld-option, --no-apply-dynamic-relocs)
> > endif
> >
> > +ifeq ($(CONFIG_RELR),y)
> > + LDFLAGS_vmlinux += --pack-dyn-relocs=relr
> > +endif
>
> RELR isn't arm64-specific, right? So we could put this in the top-level
> Makefile and have arm64 select ARCH_HAS_RELR if relocatable, so that other
> architecture can easily support this in future.
Makes sense, done in v3.
> > ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
> > ifeq ($(call ld-option, --fix-cortex-a53-843419),)
> > $(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum)
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 2cdacd1c141b9..cc23302e9d95e 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -102,6 +102,8 @@ pe_header:
> > * x23 stext() .. start_kernel() physical misalignment/KASLR offset
> > * x28 __create_page_tables() callee preserved temp register
> > * x19/x20 __primary_switch() callee preserved temp registers
> > + * x24 __primary_switch() .. relocate_kernel()
> > + * current RELR displacement
> > */
> > ENTRY(stext)
> > bl preserve_boot_args
> > @@ -834,14 +836,93 @@ __relocate_kernel:
> >
> > 0: cmp x9, x10
> > b.hs 1f
> > - ldp x11, x12, [x9], #24
> > - ldr x13, [x9, #-8]
> > - cmp w12, #R_AARCH64_RELATIVE
> > + ldp x12, x13, [x9], #24
> > + ldr x14, [x9, #-8]
> > + cmp w13, #R_AARCH64_RELATIVE
> > b.ne 0b
> > - add x13, x13, x23 // relocate
> > - str x13, [x11, x23]
> > + add x14, x14, x23 // relocate
> > + str x14, [x12, x23]
> > b 0b
> > -1: ret
> > +
> > +1:
> > +#ifdef CONFIG_RELR
> > + /*
> > + * Apply RELR relocations.
> > + *
> > + * RELR is a compressed format for storing relative relocations. The
> > + * encoded sequence of entries looks like:
> > + * [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ]
>
> I assume these are treated as an array of u64 types for the purposes of
> endianness?
Yes, the element type is defined as an integer whose endianness
matches the ELF endianness and whose size matches the ELF bitness.
This may be one of the many things that would need to be adjusted for
a hypothetical ILP32 kernel however because ILP32 on aarch64 uses
32-bit ELF according to the latest spec.
> (have you tested with a big-endian kernel?).
Unfortunately I have no easy way to test that because LLD doesn't
currently support big-endian aarch64.
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] arm64: Add support for relocating the kernel with RELR relocations
From: Peter Collingbourne @ 2019-08-01 1:18 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Masahiro Yamada
Cc: clang-built-linux, Nick Desaulniers, Peter Collingbourne,
linux-arm-kernel
In-Reply-To: <20190712193846.174893-1-pcc@google.com>
RELR is a relocation packing format for relative relocations.
The format is described in a generic-abi proposal:
https://groups.google.com/d/topic/generic-abi/bX460iggiKg/discussion
The LLD linker can be instructed to pack relocations in the RELR
format by passing the flag --pack-dyn-relocs=relr.
This patch adds a new config option, CONFIG_RELR. Enabling this option
instructs the linker to pack vmlinux's relative relocations in the RELR
format, and causes the kernel to apply the relocations at startup along
with the RELA relocations. RELA relocations still need to be applied
because the linker will emit RELA relative relocations if they are
unrepresentable in the RELR format (i.e. address not a multiple of 2).
Enabling CONFIG_RELR reduces the size of a defconfig kernel image
with CONFIG_RANDOMIZE_BASE by 3.5MB/16% uncompressed, or 550KB/5%
compressed (lz4).
Signed-off-by: Peter Collingbourne <pcc@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
---
Notes:
Changes in v3:
- Move Kconfig/Makefile logic to arch-independent location
- Tweak CONFIG_RELR documentation to remove "currently"
Changes in v2:
- Reverted change to RELA processing
- Added more comments, as requested by Nick and Will
- Added a feature test for NM and OBJCOPY
- Made CONFIG_RELR=y the default if the tools support it
Makefile | 4 ++
arch/Kconfig | 14 +++++
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/head.S | 96 ++++++++++++++++++++++++++++++---
arch/arm64/kernel/vmlinux.lds.S | 9 ++++
init/Kconfig | 3 ++
scripts/tools-support-relr.sh | 16 ++++++
7 files changed, 137 insertions(+), 6 deletions(-)
create mode 100755 scripts/tools-support-relr.sh
diff --git a/Makefile b/Makefile
index 5ee6f68898693..23ed9dbef12a1 100644
--- a/Makefile
+++ b/Makefile
@@ -912,6 +912,10 @@ ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
LDFLAGS_vmlinux += $(call ld-option, -X,)
endif
+ifeq ($(CONFIG_RELR),y)
+LDFLAGS_vmlinux += --pack-dyn-relocs=relr
+endif
+
# insure the checker run with the right endianness
CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)
diff --git a/arch/Kconfig b/arch/Kconfig
index d4c1f0551dfe0..719b27275f86a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -936,6 +936,20 @@ config LOCK_EVENT_COUNTS
the chance of application behavior change because of timing
differences. The counts are reported via debugfs.
+# Select if the architecture has support for applying RELR relocations.
+config ARCH_HAS_RELR
+ bool
+
+config RELR
+ bool "Use RELR relocation packing"
+ depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
+ default y
+ help
+ Store the kernel's dynamic relocations in the RELR relocation packing
+ format. Requires a compatible linker (LLD supports this feature), as
+ well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
+ are compatible).
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 399f595ef852e..ac1bc9cc22a26 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1467,6 +1467,7 @@ endif
config RELOCATABLE
bool
+ select ARCH_HAS_RELR
help
This builds the kernel as a Position Independent Executable (PIE),
which retains all relocation metadata required to relocate the
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 2cdacd1c141b9..cc23302e9d95e 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -102,6 +102,8 @@ pe_header:
* x23 stext() .. start_kernel() physical misalignment/KASLR offset
* x28 __create_page_tables() callee preserved temp register
* x19/x20 __primary_switch() callee preserved temp registers
+ * x24 __primary_switch() .. relocate_kernel()
+ * current RELR displacement
*/
ENTRY(stext)
bl preserve_boot_args
@@ -834,14 +836,93 @@ __relocate_kernel:
0: cmp x9, x10
b.hs 1f
- ldp x11, x12, [x9], #24
- ldr x13, [x9, #-8]
- cmp w12, #R_AARCH64_RELATIVE
+ ldp x12, x13, [x9], #24
+ ldr x14, [x9, #-8]
+ cmp w13, #R_AARCH64_RELATIVE
b.ne 0b
- add x13, x13, x23 // relocate
- str x13, [x11, x23]
+ add x14, x14, x23 // relocate
+ str x14, [x12, x23]
b 0b
-1: ret
+
+1:
+#ifdef CONFIG_RELR
+ /*
+ * Apply RELR relocations.
+ *
+ * RELR is a compressed format for storing relative relocations. The
+ * encoded sequence of entries looks like:
+ * [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ]
+ *
+ * i.e. start with an address, followed by any number of bitmaps. The
+ * address entry encodes 1 relocation. The subsequent bitmap entries
+ * encode up to 63 relocations each, at subsequent offsets following
+ * the last address entry.
+ *
+ * The bitmap entries must have 1 in the least significant bit. The
+ * assumption here is that an address cannot have 1 in lsb. Odd
+ * addresses are not supported. Any odd addresses are stored in the RELA
+ * section, which is handled above.
+ *
+ * Excluding the least significant bit in the bitmap, each non-zero
+ * bit in the bitmap represents a relocation to be applied to
+ * a corresponding machine word that follows the base address
+ * word. The second least significant bit represents the machine
+ * word immediately following the initial address, and each bit
+ * that follows represents the next word, in linear order. As such,
+ * a single bitmap can encode up to 63 relocations in a 64-bit object.
+ *
+ * In this implementation we store the address of the next RELR table
+ * entry in x9, the address being relocated by the current address or
+ * bitmap entry in x13 and the address being relocated by the current
+ * bit in x14.
+ *
+ * Because addends are stored in place in the binary, RELR relocations
+ * cannot be applied idempotently. We use x24 to keep track of the
+ * currently applied displacement so that we can correctly relocate if
+ * __relocate_kernel is called twice with non-zero displacements (i.e.
+ * if there is both a physical misalignment and a KASLR displacement).
+ */
+ ldr w9, =__relr_offset // offset to reloc table
+ ldr w10, =__relr_size // size of reloc table
+ add x9, x9, x11 // __va(.relr)
+ add x10, x9, x10 // __va(.relr) + sizeof(.relr)
+
+ sub x15, x23, x24 // delta from previous offset
+ cbz x15, 7f // nothing to do if unchanged
+ mov x24, x23 // save new offset
+
+2: cmp x9, x10
+ b.hs 7f
+ ldr x11, [x9], #8
+ tbnz x11, #0, 3f // branch to handle bitmaps
+ add x13, x11, x23
+ ldr x12, [x13] // relocate address entry
+ add x12, x12, x15
+ str x12, [x13], #8 // adjust to start of bitmap
+ b 2b
+
+3: mov x14, x13
+4: lsr x11, x11, #1
+ cbz x11, 6f
+ tbz x11, #0, 5f // skip bit if not set
+ ldr x12, [x14] // relocate bit
+ add x12, x12, x15
+ str x12, [x14]
+
+5: add x14, x14, #8 // move to next bit's address
+ b 4b
+
+6: /*
+ * Move to the next bitmap's address. 8 is the word size, and 63 is the
+ * number of significant bits in a bitmap entry.
+ */
+ add x13, x13, #(8 * 63)
+ b 2b
+
+7:
+#endif
+ ret
+
ENDPROC(__relocate_kernel)
#endif
@@ -854,6 +935,9 @@ __primary_switch:
adrp x1, init_pg_dir
bl __enable_mmu
#ifdef CONFIG_RELOCATABLE
+#ifdef CONFIG_RELR
+ mov x24, #0 // no RELR displacement yet
+#endif
bl __relocate_kernel
#ifdef CONFIG_RANDOMIZE_BASE
ldr x8, =__primary_switched
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7fa0083749078..31716afa30f65 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -200,6 +200,15 @@ SECTIONS
__rela_offset = ABSOLUTE(ADDR(.rela.dyn) - KIMAGE_VADDR);
__rela_size = SIZEOF(.rela.dyn);
+#ifdef CONFIG_RELR
+ .relr.dyn : ALIGN(8) {
+ *(.relr.dyn)
+ }
+
+ __relr_offset = ABSOLUTE(ADDR(.relr.dyn) - KIMAGE_VADDR);
+ __relr_size = SIZEOF(.relr.dyn);
+#endif
+
. = ALIGN(SEGMENT_ALIGN);
__initdata_end = .;
__init_end = .;
diff --git a/init/Kconfig b/init/Kconfig
index bd7d650d4a996..d96127ebc44e0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -30,6 +30,9 @@ config CC_CAN_LINK
config CC_HAS_ASM_GOTO
def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
+config TOOLS_SUPPORT_RELR
+ def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
+
config CC_HAS_WARN_MAYBE_UNINITIALIZED
def_bool $(cc-option,-Wmaybe-uninitialized)
help
diff --git a/scripts/tools-support-relr.sh b/scripts/tools-support-relr.sh
new file mode 100755
index 0000000000000..97a2c844a95e4
--- /dev/null
+++ b/scripts/tools-support-relr.sh
@@ -0,0 +1,16 @@
+#!/bin/sh -eu
+# SPDX-License-Identifier: GPL-2.0
+
+tmp_file=$(mktemp)
+trap "rm -f $tmp_file.o $tmp_file $tmp_file.bin" EXIT
+
+cat << "END" | "$CC" -c -x c - -o $tmp_file.o >/dev/null 2>&1
+void *p = &p;
+END
+"$LD" $tmp_file.o -shared -Bsymbolic --pack-dyn-relocs=relr -o $tmp_file
+
+# Despite printing an error message, GNU nm still exits with exit code 0 if it
+# sees a relr section. So we need to check that nothing is printed to stderr.
+test -z "$("$NM" $tmp_file 2>&1 >/dev/null)"
+
+"$OBJCOPY" -O binary $tmp_file $tmp_file.bin
--
2.22.0.709.g102302147b-goog
_______________________________________________
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/3] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: André Roth @ 2019-08-01 1:04 UTC (permalink / raw)
To: neolynx
Cc: Nishanth Menon, Kevin Hilman, Thara Gopinath, Shweta Gulati,
linux-arm-kernel
In-Reply-To: <20190801010450.27863-1-neolynx@gmail.com>
From: Thara Gopinath <thara@ti.com>
Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
default expects that OMAP's I2C_SR is plugged in to TWL's I2C
and calls omap3_twl_set_sr_bit. On platforms where I2C_SR is not connected,
the board files are expected to call omap3_twl_set_sr_bit(false) to
ensure that I2C_SR path is not set for voltage control and prevent
the default behavior of omap3_twl_init.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/omap_twl.c | 60 ++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 6787f1e72c6b..1dae906128c2 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -43,8 +43,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool __initdata twl_sr_enable_autoinit;
+#define TWL4030_DCDC_GLOBAL_CFG 0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -241,6 +248,18 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ /*
+ * The smartreflex bit on twl4030 specifies if the setting of voltage
+ * is done over the I2C_SR path. Since this setting is independent of
+ * the actual usage of smartreflex AVS module, we enable TWL SR bit
+ * by default irrespective of whether smartreflex AVS module is enabled
+ * on the OMAP side or not. This is because without this bit enabled,
+ * the voltage scaling through vp forceupdate/bypass mechanism of
+ * voltage scaling will not function on TWL over I2C_SR.
+ */
+ if (!twl_sr_enable_autoinit)
+ omap3_twl_set_sr_bit(true);
+
voltdm = voltdm_lookup("mpu_iva");
omap_voltage_register_pmic(voltdm, &omap3_mpu_pmic);
@@ -249,3 +268,44 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - Set/Clear SR bit on TWL
+ * @enable: enable SR mode in twl or not
+ *
+ * If 'enable' is true, enables Smartreflex bit on TWL 4030 to make sure
+ * voltage scaling through OMAP SR works. Else, the smartreflex bit
+ * on twl4030 is cleared as there are platforms which use OMAP3 and T2 but
+ * use Synchronized Scaling Hardware Strategy (ENABLE_VMODE=1) and Direct
+ * Strategy Software Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared (enable = false).
+ *
+ * Returns 0 on sucess, error is returned if I2C read/write fails.
+ */
+int __init omap3_twl_set_sr_bit(bool enable)
+{
+ u8 temp;
+ int ret;
+ if (twl_sr_enable_autoinit)
+ pr_warning("%s: unexpected multiple calls\n", __func__);
+
+ ret = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, &temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (enable)
+ temp |= SMARTREFLEX_ENABLE;
+ else
+ temp &= ~SMARTREFLEX_ENABLE;
+
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (!ret) {
+ twl_sr_enable_autoinit = true;
+ return 0;
+ }
+err:
+ pr_err("%s: Error access to TWL4030 (%d)\n", __func__, ret);
+ return ret;
+}
--
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
* subcribe linux arm mailing lists
From: Jiangyiwen @ 2019-08-01 0:59 UTC (permalink / raw)
To: linux-arm-kernel
subcribe linux arm mailing lists
_______________________________________________
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] net: mdio-octeon: Fix build error and Kconfig warning
From: Randy Dunlap @ 2019-07-31 23:52 UTC (permalink / raw)
To: Nathan Chancellor, davem
Cc: devel, andrew, f.fainelli, kbuild test robot,
kernel-build-reports, gregkh, willy, broonie, linux-next, netdev,
linux-arm-kernel, hkallweit1
In-Reply-To: <b3444283-7a77-ece8-7ac6-41756aa7dc60@infradead.org>
On 7/31/19 2:55 PM, Randy Dunlap wrote:
> On 7/31/19 11:50 AM, Nathan Chancellor wrote:
>> arm allyesconfig warns:
>>
>> WARNING: unmet direct dependencies detected for MDIO_OCTEON
>> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
>> && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=y]
>> Selected by [y]:
>> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC &&
>> NETDEVICES [=y] || COMPILE_TEST [=y])
>>
>> and errors:
>>
>> In file included from ../drivers/net/phy/mdio-octeon.c:14:
>> ../drivers/net/phy/mdio-octeon.c: In function 'octeon_mdiobus_probe':
>> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
>> function 'writeq'; did you mean 'writeb'?
>> [-Werror=implicit-function-declaration]
>> 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
>> | ^~~~~~
>> ../drivers/net/phy/mdio-octeon.c:56:2: note: in expansion of macro
>> 'oct_mdio_writeq'
>> 56 | oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
>> | ^~~~~~~~~~~~~~~
>> cc1: some warnings being treated as errors
>>
>> This allows MDIO_OCTEON to be built with COMPILE_TEST as well and
>> includes the proper header for readq/writeq. This does not address
>> the several -Wint-to-pointer-cast and -Wpointer-to-int-cast warnings
>> that appeared as a result of commit 171a9bae68c7 ("staging/octeon:
>> Allow test build on !MIPS") in these files.
>>
>> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
>> Reported-by: kbuild test robot <lkp@intel.com>
>> Reported-by: Mark Brown <broonie@kernel.org>
>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
>
> With today's linux-next (20190731), I am still seeing a Kconfig warning and
> build errors (building for i386):
>
> and applying Greg's "depends on NETDEVICES" patch and this patch:
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=m] && MDIO_BUS [=m] && (64BIT [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] && OF_MDIO [=n]
> Selected by [m]:
> - OCTEON_ETHERNET [=m] && STAGING [=y] && (CAVIUM_OCTEON_SOC || COMPILE_TEST [=y]) && NETDEVICES [=y]
>
> ERROR: "cavium_mdiobus_write" [drivers/net/phy/mdio-octeon.ko] undefined!
> ERROR: "cavium_mdiobus_read" [drivers/net/phy/mdio-octeon.ko] undefined!
>
>
> kernel .config file is attached.
>
> Am I missing another patch?
>
> thanks.
If I add this to drivers/staging/octeon/Kconfig:
select MDIO_OCTEON
+ select MDIO_CAVIUM
help
then the build succeeds.
This isn't being done by make *config because MDIO_OCTEON depends on OF_MDIO,
which is not set in my .config file, so the "select MDIO_CAVIUM" in MDIO_OCTEON
is not done.
However, there are lots of type/cast warnings in both mdio-octeon and mdio-cavium:
../drivers/net/phy/mdio-octeon.c: In function ‘octeon_mdiobus_probe’:
../drivers/net/phy/mdio-octeon.c:48:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(u64)devm_ioremap(&pdev->dev, mdio_phys, regsize);
^
In file included from ../drivers/net/phy/mdio-octeon.c:14:0:
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-octeon.c:56:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-octeon.c:77:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-octeon.c: In function ‘octeon_mdiobus_remove’:
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-octeon.c:91:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
^~~~~~~~~~~~~~~
and
CC [M] drivers/net/phy/mdio-cavium.o
In file included from ../drivers/net/phy/mdio-cavium.c:11:0:
../drivers/net/phy/mdio-cavium.c: In function ‘cavium_mdiobus_set_mode’:
../drivers/net/phy/mdio-cavium.h:114:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_readq(addr) readq((void *)addr)
^
../drivers/net/phy/mdio-cavium.c:21:16: note: in expansion of macro ‘oct_mdio_readq’
smi_clk.u64 = oct_mdio_readq(p->register_base + SMI_CLK);
^~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:24:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_clk.u64, p->register_base + SMI_CLK);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.c: In function ‘cavium_mdiobus_c45_addr’:
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:39:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_wr.u64, p->register_base + SMI_WR_DAT);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:47:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_cmd.u64, p->register_base + SMI_CMD);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:114:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_readq(addr) readq((void *)addr)
^
../drivers/net/phy/mdio-cavium.c:54:16: note: in expansion of macro ‘oct_mdio_readq’
smi_wr.u64 = oct_mdio_readq(p->register_base + SMI_WR_DAT);
^~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.c: In function ‘cavium_mdiobus_read’:
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:86:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_cmd.u64, p->register_base + SMI_CMD);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:114:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_readq(addr) readq((void *)addr)
^
../drivers/net/phy/mdio-cavium.c:93:16: note: in expansion of macro ‘oct_mdio_readq’
smi_rd.u64 = oct_mdio_readq(p->register_base + SMI_RD_DAT);
^~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.c: In function ‘cavium_mdiobus_write’:
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:125:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_wr.u64, p->register_base + SMI_WR_DAT);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:113:48: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
^
../drivers/net/phy/mdio-cavium.c:131:2: note: in expansion of macro ‘oct_mdio_writeq’
oct_mdio_writeq(smi_cmd.u64, p->register_base + SMI_CMD);
^~~~~~~~~~~~~~~
../drivers/net/phy/mdio-cavium.h:114:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define oct_mdio_readq(addr) readq((void *)addr)
^
../drivers/net/phy/mdio-cavium.c:138:16: note: in expansion of macro ‘oct_mdio_readq’
smi_wr.u64 = oct_mdio_readq(p->register_base + SMI_WR_DAT);
^~~~~~~~~~~~~~
>> ---
>> drivers/net/phy/Kconfig | 2 +-
>> drivers/net/phy/mdio-cavium.h | 2 ++
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>> index 20f14c5fbb7e..ed2edf4b5b0e 100644
>> --- a/drivers/net/phy/Kconfig
>> +++ b/drivers/net/phy/Kconfig
>> @@ -159,7 +159,7 @@ config MDIO_MSCC_MIIM
>>
>> config MDIO_OCTEON
>> tristate "Octeon and some ThunderX SOCs MDIO buses"
>> - depends on 64BIT
>> + depends on 64BIT || COMPILE_TEST
>> depends on HAS_IOMEM && OF_MDIO
>> select MDIO_CAVIUM
>> help
>> diff --git a/drivers/net/phy/mdio-cavium.h b/drivers/net/phy/mdio-cavium.h
>> index ed5f9bb5448d..b7f89ad27465 100644
>> --- a/drivers/net/phy/mdio-cavium.h
>> +++ b/drivers/net/phy/mdio-cavium.h
>> @@ -108,6 +108,8 @@ static inline u64 oct_mdio_readq(u64 addr)
>> return cvmx_read_csr(addr);
>> }
>> #else
>> +#include <linux/io-64-nonatomic-lo-hi.h>
>> +
>> #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
>> #define oct_mdio_readq(addr) readq((void *)addr)
>> #endif
>>
>
>
--
~Randy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
From: Leo Li @ 2019-07-31 23:28 UTC (permalink / raw)
To: Ashish Kumar, Rob Herring, Han Xu
Cc: devicetree@vger.kernel.org, bbrezillon@kernel.org, Kuldeep Singh,
broonie@kernel.org, linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB4015206CD4AAA1E54C5978DA95DD0@VI1PR04MB4015.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Ashish Kumar
> Sent: Monday, July 29, 2019 4:09 AM
> To: Rob Herring <robh@kernel.org>; Leo Li <leoyang.li@nxp.com>
> Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org; broonie@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-mtd@lists.infradead.org;
> Kuldeep Singh <kuldeep.singh@nxp.com>
> Subject: RE: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add
> bindings of ls1088a and ls1012a
>
>
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: Wednesday, July 10, 2019 1:39 AM
> > To: Ashish Kumar <ashish.kumar@nxp.com>
> > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-mtd@lists.infradead.org; Ashish Kumar <ashish.kumar@nxp.com>;
> > Kuldeep Singh <kuldeep.singh@nxp.com>; Ashish Kumar
> > <ashish.kumar@nxp.com>
> > Subject: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add
> > bindings of ls1088a and ls1012a
> >
> > Caution: EXT Email
> >
> > On Wed, 19 Jun 2019 16:41:54 +0530, Ashish Kumar wrote:
> > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > ---
> > > v3:
> > > Rebase to top
> > > v2:
> > > Convert to patch series and rebasing done on top of tree
> > >
> > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Hi Leo,
>
> I think Rob, is waiting for you ack.
Binding patches usually go through subsystem tree. So I think this actually need ack from qspi maintainer Han Xu and be picked up by SPI maintainer.
Regards,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Leo Li @ 2019-07-31 23:26 UTC (permalink / raw)
To: Ashish Kumar, Rob Herring, Han Xu
Cc: devicetree@vger.kernel.org, bbrezillon@kernel.org, Kuldeep Singh,
broonie@kernel.org, linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB4015B154965BA4BEF402890B95DD0@VI1PR04MB4015.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Ashish Kumar
> Sent: Monday, July 29, 2019 4:11 AM
> To: Rob Herring <robh@kernel.org>; Leo Li <leoyang.li@nxp.com>
> Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org; broonie@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-mtd@lists.infradead.org;
> Kuldeep Singh <kuldeep.singh@nxp.com>
> Subject: RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a
> compatibility string to bindings
>
>
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: Wednesday, July 10, 2019 1:39 AM
> > To: Ashish Kumar <ashish.kumar@nxp.com>
> > Cc: devicetree@vger.kernel.org; bbrezillon@kernel.org;
> > broonie@kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-mtd@lists.infradead.org; Ashish Kumar <ashish.kumar@nxp.com>;
> > Kuldeep Singh <kuldeep.singh@nxp.com>; Ashish Kumar
> > <ashish.kumar@nxp.com>
> > Subject: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add
> > ls2080a compatibility string to bindings
> >
> > Caution: EXT Email
> >
> > On Wed, 19 Jun 2019 16:41:53 +0530, Ashish Kumar wrote:
> > > There are 2 version of QSPI-IP, according to which controller
> > > registers sets can be big endian or little endian.There are some
> > > other minor changes like RX fifo depth etc.
> > >
> > > The big endian version uses driver compatible "fsl,ls1021a-qspi" and
> > > little endian version uses driver compatible "fsl,ls2080a-qspi"
> > >
> > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > ---
> > > v3:
> > > Rebase to top
> > > v2:
> > > Convert to patch series and rebasing done on top of tree
> > >
> > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Hi Leo,
>
> I think Rob, is waiting for you ack.
Binding patches usually go through subsystem tree. So I think this actually need ack from qspi maintainer Han Xu and be picked up by SPI maintainer.
Regards,
Leo
_______________________________________________
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 3/3] arm64: dts: ls1088a: Revise gpio registers to little-endian
From: Li Yang @ 2019-07-31 23:19 UTC (permalink / raw)
To: Chuanhua Han
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-gpio, Linus Walleij, lkml, Bartosz Golaszewski, Rob Herring,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190529083254.39581-3-chuanhua.han@nxp.com>
On Wed, May 29, 2019 at 3:32 AM Chuanhua Han <chuanhua.han@nxp.com> wrote:
>
> Since fsl-ls1088a Soc GPIO registers are used as little endian,
> the patch adds the little-endian attribute to each gpio node.
>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 661137ffa319..3e6d20d065bd 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -272,6 +272,7 @@
> compatible = "fsl,qoriq-gpio";
> reg = <0x0 0x2300000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> @@ -282,6 +283,7 @@
> compatible = "fsl,qoriq-gpio";
> reg = <0x0 0x2310000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> @@ -292,6 +294,7 @@
> compatible = "fsl,qoriq-gpio";
> reg = <0x0 0x2320000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> @@ -302,6 +305,7 @@
> compatible = "fsl,qoriq-gpio";
> reg = <0x0 0x2330000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> --
> 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: [PATCH 1/2] arm64: dts: ls1028a: Fix GPIO work fail.
From: Li Yang @ 2019-07-31 23:17 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-gpio, Linus Walleij, lkml, Bartosz Golaszewski, Rob Herring,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190718094902.15562-1-hui.song_1@nxp.com>
On Thu, Jul 18, 2019 at 4:59 AM Hui Song <hui.song_1@nxp.com> wrote:
>
Change the title to be something like:
arm64: dts: ls1028a: fix gpio nodes
> From: Song Hui <hui.song_1@nxp.com>
>
> Add ls1028a device specify compatible.
Please submit a separate patch to update the device tree binding too.
> Make gpio as little-endian deal.
"Update the nodes to include little-endian property to be consistent
with the hardware."
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 7975519..488602b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -277,33 +277,36 @@
> };
>
> gpio1: gpio@2300000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> reg = <0x0 0x2300000 0x0 0x10000>;
> interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> gpio2: gpio@2310000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> reg = <0x0 0x2310000 0x0 0x10000>;
> interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> gpio3: gpio@2320000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> reg = <0x0 0x2320000 0x0 0x10000>;
> interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + little-endian;
> };
>
> usb0: usb@3100000 {
> --
> 2.9.5
>
_______________________________________________
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] net: stmmac: Use netif_tx_napi_add() for TX polling function
From: David Miller @ 2019-07-31 23:10 UTC (permalink / raw)
To: brgl
Cc: fisaksen, alexandre.torgue, netdev, linux-kernel, bgolaszewski,
joabreu, mcoquelin.stm32, peppe.cavallaro, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190730113814.13825-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Tue, 30 Jul 2019 13:38:14 +0200
> From: Frode Isaksen <fisaksen@baylibre.com>
>
> This variant of netif_napi_add() should be used from drivers
> using NAPI to exclusively poll a TX queue.
>
> Signed-off-by: Frode Isaksen <fisaksen@baylibre.com>
> Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied and queued up for -stable.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: WARNING in __mmdrop
From: Jason Gunthorpe @ 2019-07-31 23:00 UTC (permalink / raw)
To: Jason Wang
Cc: mhocko, Michael S. Tsirkin, peterz, ldv, james.bottomley,
linux-mm, namit, mingo, elena.reshetova, keescook, aarcange,
davem, hch, christian, syzbot, syzkaller-bugs, jglisse, viro,
linux-arm-kernel, wad, linux-parisc, linux-kernel, luto, ebiederm,
akpm, guro
In-Reply-To: <421a1af6-df06-e4a6-b34f-526ac123bc4a@redhat.com>
On Wed, Jul 31, 2019 at 04:49:32PM +0800, Jason Wang wrote:
> Yes, looking at the synchronization implemented by other MMU notifiers.
> Vhost is even the simplest.
I think that is only because it calls gup under a spinlock, which is,
IMHO, not great.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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