* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: James Hogan @ 2016-10-24 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477138444-14993-1-git-send-email-ynorov@caviumnetworks.com>
On Sat, Oct 22, 2016 at 03:14:04PM +0300, Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> unistd.h prior to including asm-generic/unistd.h, and adjust all
> architectures using the generic syscall list to define it so that no
> in-tree architectures are affected.
>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Richard Kuo <rkuo@codeaurora.org>
> Cc: James Hogan <james.hogan@imgtec.com>
> Cc: Ley Foon Tan <lftan@altera.com>
> Cc: Jonas Bonn <jonas@southpole.se>
> Cc: Chen Liqin <liqin.linux@gmail.com>
> Cc: Lennox Wu <lennox.wu@gmail.com>
> Cc: Chris Metcalf <cmetcalf@mellanox.com>
> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Pinski <Andrew.Pinski@cavium.com>
> Cc: linux-snps-arc at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-c6x-dev at linux-c6x.org
> Cc: uclinux-h8-devel at lists.sourceforge.jp
> Cc: linux-hexagon at vger.kernel.org
> Cc: linux-metag at vger.kernel.org
> Cc: nios2-dev at lists.rocketboards.org
> Cc: linux-arch at vger.kernel.or
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
>
> ---
> arch/arc/include/uapi/asm/unistd.h | 1 +
> arch/arm64/include/uapi/asm/unistd.h | 1 +
> arch/c6x/include/uapi/asm/unistd.h | 1 +
> arch/h8300/include/uapi/asm/unistd.h | 1 +
> arch/hexagon/include/uapi/asm/unistd.h | 1 +
> arch/metag/include/uapi/asm/unistd.h | 1 +
Acked-by: James Hogan <james.hogan@imgtec.com> [metag]
Cheers
James
> arch/nios2/include/uapi/asm/unistd.h | 1 +
> arch/openrisc/include/uapi/asm/unistd.h | 1 +
> arch/score/include/uapi/asm/unistd.h | 1 +
> arch/tile/include/uapi/asm/unistd.h | 1 +
> arch/unicore32/include/uapi/asm/unistd.h | 1 +
> include/uapi/asm-generic/unistd.h | 5 +++++
> 12 files changed, 16 insertions(+)
>
> diff --git a/arch/arc/include/uapi/asm/unistd.h b/arch/arc/include/uapi/asm/unistd.h
> index 41fa2ec..928546d 100644
> --- a/arch/arc/include/uapi/asm/unistd.h
> +++ b/arch/arc/include/uapi/asm/unistd.h
> @@ -16,6 +16,7 @@
> #define _UAPI_ASM_ARC_UNISTD_H
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #define __ARCH_WANT_SYS_EXECVE
> #define __ARCH_WANT_SYS_CLONE
> #define __ARCH_WANT_SYS_VFORK
> diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h
> index 043d17a..48355a6 100644
> --- a/arch/arm64/include/uapi/asm/unistd.h
> +++ b/arch/arm64/include/uapi/asm/unistd.h
> @@ -15,5 +15,6 @@
> */
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>
> #include <asm-generic/unistd.h>
> diff --git a/arch/c6x/include/uapi/asm/unistd.h b/arch/c6x/include/uapi/asm/unistd.h
> index 12d73d9..f676231 100644
> --- a/arch/c6x/include/uapi/asm/unistd.h
> +++ b/arch/c6x/include/uapi/asm/unistd.h
> @@ -15,6 +15,7 @@
> */
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #define __ARCH_WANT_SYS_CLONE
>
> /* Use the standard ABI for syscalls. */
> diff --git a/arch/h8300/include/uapi/asm/unistd.h b/arch/h8300/include/uapi/asm/unistd.h
> index 7dd20ef..2f98394 100644
> --- a/arch/h8300/include/uapi/asm/unistd.h
> +++ b/arch/h8300/include/uapi/asm/unistd.h
> @@ -1,5 +1,6 @@
> #define __ARCH_NOMMU
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>
> #include <asm-generic/unistd.h>
> diff --git a/arch/hexagon/include/uapi/asm/unistd.h b/arch/hexagon/include/uapi/asm/unistd.h
> index 2151760..52d585c 100644
> --- a/arch/hexagon/include/uapi/asm/unistd.h
> +++ b/arch/hexagon/include/uapi/asm/unistd.h
> @@ -28,6 +28,7 @@
>
> #define sys_mmap2 sys_mmap_pgoff
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #define __ARCH_WANT_SYS_EXECVE
> #define __ARCH_WANT_SYS_CLONE
> #define __ARCH_WANT_SYS_VFORK
> diff --git a/arch/metag/include/uapi/asm/unistd.h b/arch/metag/include/uapi/asm/unistd.h
> index 459b6ec..16b5cb3 100644
> --- a/arch/metag/include/uapi/asm/unistd.h
> +++ b/arch/metag/include/uapi/asm/unistd.h
> @@ -8,6 +8,7 @@
> */
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>
> /* Use the standard ABI for syscalls. */
> #include <asm-generic/unistd.h>
> diff --git a/arch/nios2/include/uapi/asm/unistd.h b/arch/nios2/include/uapi/asm/unistd.h
> index 51a32c7..b0dda4d 100644
> --- a/arch/nios2/include/uapi/asm/unistd.h
> +++ b/arch/nios2/include/uapi/asm/unistd.h
> @@ -18,6 +18,7 @@
> #define sys_mmap2 sys_mmap_pgoff
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>
> /* Use the standard ABI for syscalls */
> #include <asm-generic/unistd.h>
> diff --git a/arch/openrisc/include/uapi/asm/unistd.h b/arch/openrisc/include/uapi/asm/unistd.h
> index 471905b..6812d81 100644
> --- a/arch/openrisc/include/uapi/asm/unistd.h
> +++ b/arch/openrisc/include/uapi/asm/unistd.h
> @@ -21,6 +21,7 @@
> #define sys_mmap2 sys_mmap_pgoff
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #define __ARCH_WANT_SYS_FORK
> #define __ARCH_WANT_SYS_CLONE
>
> diff --git a/arch/score/include/uapi/asm/unistd.h b/arch/score/include/uapi/asm/unistd.h
> index d4008c3..7ad1bdc 100644
> --- a/arch/score/include/uapi/asm/unistd.h
> +++ b/arch/score/include/uapi/asm/unistd.h
> @@ -1,6 +1,7 @@
> #define __ARCH_HAVE_MMU
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #define __ARCH_WANT_SYSCALL_NO_AT
> #define __ARCH_WANT_SYSCALL_NO_FLAGS
> #define __ARCH_WANT_SYSCALL_OFF_T
> diff --git a/arch/tile/include/uapi/asm/unistd.h b/arch/tile/include/uapi/asm/unistd.h
> index 24e9187..cf0505f 100644
> --- a/arch/tile/include/uapi/asm/unistd.h
> +++ b/arch/tile/include/uapi/asm/unistd.h
> @@ -13,6 +13,7 @@
> */
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> #if !defined(__LP64__) || defined(__SYSCALL_COMPAT)
> /* Use the flavor of this syscall that matches the 32-bit API better. */
> #define __ARCH_WANT_SYNC_FILE_RANGE2
> diff --git a/arch/unicore32/include/uapi/asm/unistd.h b/arch/unicore32/include/uapi/asm/unistd.h
> index 1f63c47..ef25aec 100644
> --- a/arch/unicore32/include/uapi/asm/unistd.h
> +++ b/arch/unicore32/include/uapi/asm/unistd.h
> @@ -11,6 +11,7 @@
> */
>
> #define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
>
> /* Use the standard ABI for syscalls. */
> #include <asm-generic/unistd.h>
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index 9b1462e..bbaeac0 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -465,10 +465,15 @@ __SYSCALL(__NR_uname, sys_newuname)
> __SYSCALL(__NR_sethostname, sys_sethostname)
> #define __NR_setdomainname 162
> __SYSCALL(__NR_setdomainname, sys_setdomainname)
> +
> +#ifdef __ARCH_WANT_SET_GET_RLIMIT
> +/* getrlimit and setrlimit are superseded with prlimit64 */
> #define __NR_getrlimit 163
> __SC_COMP(__NR_getrlimit, sys_getrlimit, compat_sys_getrlimit)
> #define __NR_setrlimit 164
> __SC_COMP(__NR_setrlimit, sys_setrlimit, compat_sys_setrlimit)
> +#endif
> +
> #define __NR_getrusage 165
> __SC_COMP(__NR_getrusage, sys_getrusage, compat_sys_getrusage)
> #define __NR_umask 166
> --
> 2.7.4
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/43e985fd/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Geert Uytterhoeven @ 2016-10-24 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg382kv9.fsf@belgarion.home>
On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>> What's the point of the x32 mode?
>>
>> On x86, the motivation is faster code for most use cases that
>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>> cache footprint than 64-bit pointers.
>
> For completness, the second point of x32 AFAIU is the IP-relative addressing
> which is not available in standard 32 bit mode, which improves PIC code. For
> simple not algorithmic code (think Android HAL for example) with many shared
> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
> the push-to-stack and pop register.
But that's not an advantage compared to full am64 mode, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Geert Uytterhoeven @ 2016-10-24 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3851270.xZRcP9hae0@wuerfel>
Hi Arnd,
On Fri, Oct 21, 2016 at 3:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> - a lot of the less common architectures just don't get updated
> in time, out of 22 architectures that don't use asm-generic/unistd.h,
> only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
Should everybody implement pkey_mprotect?
"x86, pkeys: remove cruft from never-merged syscalls" and
arch/powerpc/include/asm/unistd.h:#define __IGNORE_pkey_mprotect
aren't that reassuring...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V4 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Suzuki K Poulose @ 2016-10-24 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477071013-29563-3-git-send-email-tbaicar@codeaurora.org>
On 21/10/16 18:30, Tyler Baicar wrote:
> Currently when a RAS error is reported it is not timestamped.
> The ACPI 6.1 spec adds the timestamp field to the generic error
> data entry v3 structure. The timestamp of when the firmware
> generated the error is now being reported.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
> drivers/acpi/apei/ghes.c | 14 +++++++---
> drivers/firmware/efi/cper.c | 67 +++++++++++++++++++++++++++++++++++++--------
> include/acpi/ghes.h | 10 +++++++
> include/linux/cper.h | 12 ++++++++
> 4 files changed, 88 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 7d020b0..7610f08 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -419,7 +419,8 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
> int flags = -1;
> int sec_sev = ghes_severity(gdata->error_severity);
> struct cper_sec_mem_err *mem_err;
> - mem_err = (struct cper_sec_mem_err *)(gdata + 1);
> +
> + mem_err = acpi_hest_generic_data_payload(gdata);
>
> if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
> return;
> @@ -449,14 +450,18 @@ static void ghes_do_proc(struct ghes *ghes,
> {
> int sev, sec_sev;
> struct acpi_hest_generic_data *gdata;
> + uuid_le sec_type;
>
> sev = ghes_severity(estatus->error_severity);
> apei_estatus_for_each_section(estatus, gdata) {
> sec_sev = ghes_severity(gdata->error_severity);
> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> + sec_type = *(uuid_le *)gdata->section_type;
> +
> + if (!uuid_le_cmp(sec_type,
> CPER_SEC_PLATFORM_MEM)) {
> struct cper_sec_mem_err *mem_err;
> - mem_err = (struct cper_sec_mem_err *)(gdata+1);
> +
> + mem_err = acpi_hest_generic_data_payload(gdata);
> ghes_edac_report_mem_error(ghes, sev, mem_err);
>
> arch_apei_report_mem_error(sev, mem_err);
> @@ -466,7 +471,8 @@ static void ghes_do_proc(struct ghes *ghes,
> else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> CPER_SEC_PCIE)) {
> struct cper_sec_pcie *pcie_err;
> - pcie_err = (struct cper_sec_pcie *)(gdata+1);
> +
> + pcie_err = acpi_hest_generic_data_payload(gdata);
> if (sev == GHES_SEV_RECOVERABLE &&
> sec_sev == GHES_SEV_RECOVERABLE &&
> pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index d425374..af7e1e9 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -32,6 +32,9 @@
> #include <linux/acpi.h>
> #include <linux/pci.h>
> #include <linux/aer.h>
> +#include <linux/printk.h>
> +#include <linux/bcd.h>
> +#include <acpi/ghes.h>
>
> #define INDENT_SP " "
>
> @@ -386,13 +389,37 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> }
>
> +static void cper_estatus_print_section_v300(const char *pfx,
> + const struct acpi_hest_generic_data_v300 *gdata)
> +{
> + __u8 hour, min, sec, day, mon, year, century, *timestamp;
> +
> + if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
> + timestamp = (__u8 *)&(gdata->time_stamp);
> + sec = bcd2bin(timestamp[0]);
> + min = bcd2bin(timestamp[1]);
> + hour = bcd2bin(timestamp[2]);
> + day = bcd2bin(timestamp[4]);
> + mon = bcd2bin(timestamp[5]);
> + year = bcd2bin(timestamp[6]);
> + century = bcd2bin(timestamp[7]);
> + printk("%stime: %7s %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
> + 0x01 & *(timestamp + 3) ? "precise" : "", century,
> + year, mon, day, hour, min, sec);
> + }
> +}
> +
> static void cper_estatus_print_section(
> - const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
> + const char *pfx, struct acpi_hest_generic_data *gdata, int sec_no)
> {
> uuid_le *sec_type = (uuid_le *)gdata->section_type;
> __u16 severity;
> char newpfx[64];
>
> + if (acpi_hest_generic_data_version(gdata))
> + cper_estatus_print_section_v300(pfx,
> + (const struct acpi_hest_generic_data_v300 *)gdata);
> +
> severity = gdata->error_severity;
> printk("%s""Error %d, type: %s\n", pfx, sec_no,
> cper_severity_str(severity));
> @@ -403,14 +430,18 @@ static void cper_estatus_print_section(
>
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
> - struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
> + struct cper_sec_proc_generic *proc_err;
> +
> + proc_err = acpi_hest_generic_data_payload(gdata);
> printk("%s""section_type: general processor error\n", newpfx);
> if (gdata->error_data_length >= sizeof(*proc_err))
> cper_print_proc_generic(newpfx, proc_err);
> else
> goto err_section_too_small;
> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> - struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
> + struct cper_sec_mem_err *mem_err;
> +
> + mem_err = acpi_hest_generic_data_payload(gdata);
> printk("%s""section_type: memory error\n", newpfx);
> if (gdata->error_data_length >=
> sizeof(struct cper_sec_mem_err_old))
> @@ -419,7 +450,9 @@ static void cper_estatus_print_section(
> else
> goto err_section_too_small;
> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
> - struct cper_sec_pcie *pcie = (void *)(gdata + 1);
> + struct cper_sec_pcie *pcie;
> +
> + pcie = acpi_hest_generic_data_payload(gdata);
> printk("%s""section_type: PCIe error\n", newpfx);
> if (gdata->error_data_length >= sizeof(*pcie))
> cper_print_pcie(newpfx, pcie, gdata);
> @@ -438,6 +471,7 @@ void cper_estatus_print(const char *pfx,
> const struct acpi_hest_generic_status *estatus)
> {
> struct acpi_hest_generic_data *gdata;
> + struct acpi_hest_generic_data_v300 *gdata_v3 = NULL;
> unsigned int data_len, gedata_len;
> int sec_no = 0;
> char newpfx[64];
> @@ -451,12 +485,22 @@ void cper_estatus_print(const char *pfx,
> printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> + if (acpi_hest_generic_data_version(gdata))
> + gdata_v3 = (struct acpi_hest_generic_data_v300 *)gdata;
I think the acpi_hest_generic_data_version() doesn't check if the version is
V3 or higher ?
> +
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> +
> while (data_len >= sizeof(*gdata)) {
> gedata_len = gdata->error_data_length;
> cper_estatus_print_section(newpfx, gdata, sec_no);
> - data_len -= gedata_len + sizeof(*gdata);
> - gdata = (void *)(gdata + 1) + gedata_len;
> + if(gdata_v3) {
> + data_len -= gedata_len + sizeof(*gdata_v3);
> + gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
> + gdata = (struct acpi_hest_generic_data *)gdata_v3;
> + } else {
> + data_len -= gedata_len + sizeof(*gdata);
> + gdata = (void *)(gdata + 1) + gedata_len;
> + }
Could we not use the helpers we define below to unify the code here and avoid the
switch ?
> sec_no++;
> }
> }
> @@ -486,12 +530,13 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
> return rc;
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> - while (data_len >= sizeof(*gdata)) {
> - gedata_len = gdata->error_data_length;
> - if (gedata_len > data_len - sizeof(*gdata))
> +
> + while (data_len >= acpi_hest_generic_data_size(gdata)) {
> + gedata_len = acpi_hest_generic_data_error_length(gdata);
> + if (gedata_len > data_len - acpi_hest_generic_data_size(gdata))
> return -EINVAL;
> - data_len -= gedata_len + sizeof(*gdata);
> - gdata = (void *)(gdata + 1) + gedata_len;
> + data_len -= gedata_len + acpi_hest_generic_data_size(gdata);
> + gdata = acpi_hest_generic_data_next(gdata);
> }
> if (data_len)
> return -EINVAL;
> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
> index 68f088a..56b9679 100644
> --- a/include/acpi/ghes.h
> +++ b/include/acpi/ghes.h
> @@ -73,3 +73,13 @@ static inline void ghes_edac_unregister(struct ghes *ghes)
> {
> }
> #endif
> +
> +#define acpi_hest_generic_data_version(gdata) \
> + (gdata->revision >> 8)
> +
>
> +#define acpi_hest_generic_data_error_length(gdata) \
> + (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
> +#define acpi_hest_generic_data_size(gdata) \
> + ((acpi_hest_generic_data_version(gdata) >= 3) ? \
> + sizeof(struct acpi_hest_generic_data_v300) : \
> + sizeof(struct acpi_hest_generic_data))
> +#define acpi_hest_generic_data_record_size(gdata) \
> + (acpi_hest_generic_data_size(gdata) + \
> + acpi_hest_generic_data_error_length(gdata))
> +#define acpi_hest_generic_data_next(gdata) \
> + ((void *)(gdata) + acpi_hest_generic_data_record_size(gdata))
> +
Rest looks good
Cheers
Suzuki
^ permalink raw reply
* Question about arm64 earlycon
From: Arnd Bergmann @ 2016-10-24 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDnB3QBjODYNTndBsexGQfnL1rj6DAUPcf1nT9+aJaqCtw@mail.gmail.com>
On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
> Hi Catalin, Marc, Mark, Arnd,
>
> I am testing with 3.12 kernel with earlyprintk enabled and I see some
> garbage characters in the console log right before the message
> indicating that the real console device is initialized:
>
> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
> console [ttyS0] enabled, bootconsole disabled
>
> I looked through early_prink.c file and printk.c file and it looks
> like there is case that some early boot code can touch the UART
> hardware via ealy console driver while the 'real' console driver is
> setting up the same UART port? Please let me know if I missed some
> important piece of code that can prevent this.
I don't think we every supported earlyprintk on arm64, and
earlycon support may have been added later.
If you can't use a modern kernel, try backporting all the
relevant earlycon changes.
Arnd
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Lee Jones @ 2016-10-24 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbd16837-a260-b574-1b1a-1bede038e3de@redhat.com>
On Tue, 18 Oct 2016, Hans de Goede wrote:
> On 18-10-16 07:25, Chen-Yu Tsai wrote:
> > On Wed, Oct 5, 2016 at 11:51 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > > The i2c subsys does not load modules by compatible, only by
> > > i2c-id, with e.g. a modalias of: "i2c:axp209".
> > >
> > > Populate the axp20x_i2c_id[] table with supported ids, so that
> > > module auto-loading will work.
> > >
> > > Reported-by: Dennis Gilmore <dennis@ausil.us>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> > Acked-by: Chen-Yu Tsai <wens@csie.org>
> >
> > Even though axp20x-i2c seems to be the only "DT only" i2c client,
> > would it make sense to add DT-based module autoloading to the i2c
> > core?
>
> If it is not too invasive, then yes that would be a sensible addition IMHO.
If I understand you correctly, I already have a patch-set on the ML
that does this.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/3] arm64: arch_timer: Work around QorIQ Erratum Hisilicon-161x01
From: Marc Zyngier @ 2016-10-24 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07862fac-b32a-9246-c01f-fc3e55635f54@huawei.com>
On 23/10/16 04:21, Ding Tianhong wrote:
> Erratum Hisilicon-161x01 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread TVAL and count registers until successive
> reads return the limited range value (32) by back-to-back reads. Writes to TVAL are
> replaced with an equivalent write to CVAL.
>
> The workaround is enabled if the hisilicon,erratum-161x01 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.hisilicon-161x01 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> Documentation/kernel-parameters.txt | 9 ++
> arch/arm64/include/asm/arch_timer.h | 41 +++++++--
> drivers/clocksource/Kconfig | 14 ++-
> drivers/clocksource/arm_arch_timer.c | 153 +++++++++++++++++++++++++++------
> 5 files changed, 182 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 405da11..3a79803 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,3 +63,4 @@ stable kernels.
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> | | | | |
> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> +| Hisilicon | Hip05/Hip06/Hip07 | #161x01 | HISILICON_ERRATUM_161x01|
Please keep the columns aligned. If the affected component doesn't fit
in the allocated space, use multiple lines, or write it in a condensed
way (Hip0{5,6,7} for example). Also, please use spaces instead of tabs
to match the rest of the file.
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 6fa1d8a..175f349 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -707,6 +707,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> erratum. If unspecified, the workaround is
> enabled based on the device tree.
>
> + clocksource.arm_arch_timer.hisilicon-161x01=
> + [ARM64]
> + Format: <bool>
> + Enable/disable the workaround of Hisilicon
> + erratum 161x01. This can be useful for KVM
> + guests, if the guest device tree doesn't show the
> + erratum. If unspecified, the workaround is
> + enabled based on the device tree.
> +
> clearcpuid=BITNUM [X86]
> Disable CPUID feature X for the kernel. See
> arch/x86/include/asm/cpufeatures.h for the valid bit
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..6b510db 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -29,17 +29,24 @@
>
> #include <clocksource/arm_arch_timer.h>
>
> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> extern struct static_key_false arch_timer_read_ool_enabled;
> -#define needs_fsl_a008585_workaround() \
> +extern struct arch_timer_erratum_workaround *erratum_workaround;
> +#define needs_timer_erratum_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
> #else
> -#define needs_fsl_a008585_workaround() false
> +#define needs_timer_erratum_workaround() false
> #endif
>
> -u32 __fsl_a008585_read_cntp_tval_el0(void);
> -u32 __fsl_a008585_read_cntv_tval_el0(void);
> -u64 __fsl_a008585_read_cntvct_el0(void);
> +struct clock_event_device;
> +
> +struct arch_timer_erratum_workaround {
> + int erratum;
> + u32 (*read_cntp_tval_el0)(void);
> + u32 (*read_cntv_tval_el0)(void);
> + u64 (*read_cntvct_el0)(void);
> +};
> +extern struct arch_timer_erratum_workaround *erratum_workaround;
You seem to be doing two things in this patch:
- Introducing a more generic erratum handling mechanism
- Adding a workaround for your particular erratum
Please make this two patches.
>
> /*
> * The number of retries is an arbitrary value well beyond the highest number
> @@ -59,16 +66,34 @@ u64 __fsl_a008585_read_cntvct_el0(void);
> _new; \
> })
>
> +#define __hisi_161x01_read_reg(reg) ({ \
> + u64 _old, _new; \
> + int _retries = 200; \
How has this number of retries been determined?
> + \
> + do { \
> + _old = read_sysreg(reg); \
> + _new = read_sysreg(reg); \
> + _retries--; \
> + } while (unlikely((_new - _old) >> 5) && _retries); \
Please document why ignoring the bottom 5 bits is a reasonable thing to do.
> + \
> + WARN_ON_ONCE(!_retries); \
> + _new; \
> +})
> +
> +
> +
> #define arch_timer_reg_read_stable(reg) \
> ({ \
> u64 _val; \
> - if (needs_fsl_a008585_workaround()) \
> - _val = __fsl_a008585_read_##reg(); \
> + if (needs_timer_erratum_workaround()) \
> + _val = erratum_workaround->read_##reg(); \
> else \
> _val = read_sysreg(reg); \
> _val; \
> })
>
> +
> +
> /*
> * These register accessors are marked inline so the compiler can
> * nicely work out which register we want, and chuck away the rest of
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8a753fd..fcfcdc7 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
> help
> This option enables a workaround for Freescale/NXP Erratum
> A-008585 ("ARM generic timer may contain an erroneous
> - value"). The workaround will only be active if the
> + value"). The workaround will be active if the
> fsl,erratum-a008585 property is found in the timer node.
> + This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
> + boot parameter.
> +
> +config HISILICON_ERRATUM_161X01
> + bool "Workaround for Hisilicon Erratum 161201"
> + default y
> + depends on ARM_ARCH_TIMER && ARM64
> + help
> + This option enables a workaround for Hisilicon Erratum
> + 161201. The workaround will be active if the hisi,erratum-161201
> + property is found in the timer node. This can be overridden with
> + the clocksource.arm_arch_timer.hisi-161201 boot parameter.
Please pick a side. This is either called 161X01 or 161201.
>
> config ARM_GLOBAL_TIMER
> bool "Support for the ARM global timer" if COMPILE_TEST
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487d..e1cf0ad 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -90,16 +90,23 @@ static int __init early_evtstrm_cfg(char *buf)
> }
> early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
>
> -/*
> - * Architected system timer support.
> - */
> +#define FSL_A008585 1
> +#define HISILICON_161X01 2
> +
> +struct arch_timer_erratum_workaround *erratum_workaround;
> +
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> +static int arch_timer_uses_erratum = 0;
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
> EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
> +#endif
>
> -static int fsl_a008585_enable = -1;
> +/*
> + * Architected system timer support.
> + */
>
> +#ifdef CONFIG_FSL_ERRATUM_A008585
> static int __init early_fsl_a008585_cfg(char *buf)
> {
> int ret;
> @@ -109,28 +116,96 @@ static int __init early_fsl_a008585_cfg(char *buf)
> if (ret)
> return ret;
>
> - fsl_a008585_enable = val;
> + if (val)
> + arch_timer_uses_erratum = FSL_A008585;
> +
I don't think you need this indirection. You should be able to set the
erratum_workaround pointer, and test that only to enable the OOL access.
> return 0;
> }
> early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
>
> -u32 __fsl_a008585_read_cntp_tval_el0(void)
> +u32 fsl_a008585_read_cntp_tval_el0(void)
> {
> return __fsl_a008585_read_reg(cntp_tval_el0);
> }
>
> -u32 __fsl_a008585_read_cntv_tval_el0(void)
> +u32 fsl_a008585_read_cntv_tval_el0(void)
> {
> return __fsl_a008585_read_reg(cntv_tval_el0);
> }
>
> -u64 __fsl_a008585_read_cntvct_el0(void)
> +u64 fsl_a008585_read_cntvct_el0(void)
> {
> return __fsl_a008585_read_reg(cntvct_el0);
> }
> -EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
> +EXPORT_SYMBOL(fsl_a008585_read_cntvct_el0);
Since you're now going to through a pointer indirection
(erratum_workaround), why do you need this export? Why aren't all these
function static? How does it work with modules that need to access
cntvct_el0 (hint: it probably doesn't...)?
> +#else
> +u32 fsl_a008585_read_cntp_tval_el0(void)
> +{
> + return 0;
> +}
> +
> +u32 fsl_a008585_read_cntv_tval_el0(void)
> +{
> + return 0;
> +}
> +
> +u64 fsl_a008585_read_cntvct_el0(void)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(fsl_a008585_read_cntvct_el0);
I don't think we need any of this.
> #endif /* CONFIG_FSL_ERRATUM_A008585 */
>
> +#ifdef CONFIG_HISILICON_ERRATUM_161X01
> +static int __init early_hisi_161x01_cfg(char *buf)
> +{
> + int ret;
> + bool val;
> +
> + ret = strtobool(buf, &val);
> + if (ret)
> + return ret;
> +
> + if (val)
> + arch_timer_uses_erratum = HISILICON_161X01;
> +
> + return 0;
> +}
> +early_param("clocksource.arm_arch_timer.hisilicon-161x01", early_hisi_161x01_cfg);
> +
> +u32 hisi_161x01_read_cntp_tval_el0(void)
> +{
> + return __hisi_161x01_read_reg(cntp_tval_el0);
> +}
> +
> +u32 hisi_161x01_read_cntv_tval_el0(void)
> +{
> + return __hisi_161x01_read_reg(cntv_tval_el0);
> +}
> +
> +u64 hisi_161x01_read_cntvct_el0(void)
> +{
> + return __hisi_161x01_read_reg(cntvct_el0);
> +}
> +EXPORT_SYMBOL(hisi_161x01_read_cntvct_el0);
Same issue.
> +#else
> +u32 hisi_161x01_read_cntp_tval_el0(void)
> +{
> + return 0;
> +}
> +
> +u32 hisi_161x01_read_cntv_tval_el0(void)
> +{
> + return 0;
> +}
> +
> +u64 hisi_161x01_read_cntvct_el0(void)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(hisi_161x01_read_cntvct_el0);
> +#endif
> +
> static __always_inline
> void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
> struct clock_event_device *clk)
> @@ -280,8 +355,8 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
> arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
> }
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> -static __always_inline void fsl_a008585_set_next_event(const int access,
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> +static __always_inline void erratum_set_next_event(const int access,
> unsigned long evt, struct clock_event_device *clk)
> {
> unsigned long ctrl;
> @@ -299,20 +374,35 @@ static __always_inline void fsl_a008585_set_next_event(const int access,
> arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
> }
>
> -static int fsl_a008585_set_next_event_virt(unsigned long evt,
> +static int erratum_set_next_event_virt(unsigned long evt,
> struct clock_event_device *clk)
> {
> - fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
> + erratum_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
> return 0;
> }
>
> -static int fsl_a008585_set_next_event_phys(unsigned long evt,
> +static int erratum_set_next_event_phys(unsigned long evt,
> struct clock_event_device *clk)
> {
> - fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
> + erratum_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
> return 0;
> }
> -#endif /* CONFIG_FSL_ERRATUM_A008585 */
> +#endif /* CONFIG_FSL_ERRATUM_A008585 || CONFIG_HISILICON_ERRATUM_161X01 */
> +
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> +static struct arch_timer_erratum_workaround arch_timer_erratum[] = {
> +{
> + .erratum = FSL_A008585,
> + .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> + .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> +},{
> + .erratum = HISILICON_161X01,
> + .read_cntp_tval_el0 = hisi_161x01_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = hisi_161x01_read_cntv_tval_el0,
> + .read_cntvct_el0 = hisi_161x01_read_cntvct_el0,
> +} };
Since the two erratum are allowed to be selected independently, you
shouldn't lump them together here.
> +#endif
>
> static int arch_timer_set_next_event_virt(unsigned long evt,
> struct clock_event_device *clk)
> @@ -342,16 +432,16 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
> return 0;
> }
>
> -static void fsl_a008585_set_sne(struct clock_event_device *clk)
> +static void erratum_set_sne(struct clock_event_device *clk)
> {
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> return;
>
> if (arch_timer_uses_ppi == VIRT_PPI)
> - clk->set_next_event = fsl_a008585_set_next_event_virt;
> + clk->set_next_event = erratum_set_next_event_virt;
> else
> - clk->set_next_event = fsl_a008585_set_next_event_phys;
> + clk->set_next_event = erratum_set_next_event_phys;
> #endif
> }
>
> @@ -384,7 +474,7 @@ static void __arch_timer_setup(unsigned type,
> BUG();
> }
>
> - fsl_a008585_set_sne(clk);
> + erratum_set_sne(clk);
> } else {
> clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
> clk->name = "arch_mem_timer";
> @@ -890,12 +980,21 @@ static int __init arch_timer_of_init(struct device_node *np)
>
> arch_timer_c3stop = !of_property_read_bool(np, "always-on");
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> - if (fsl_a008585_enable < 0)
> - fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
> - if (fsl_a008585_enable) {
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
> + if (!arch_timer_uses_erratum) {
> + if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) &&
> + of_property_read_bool(np, "fsl,erratum-a008585"))
> + arch_timer_uses_erratum = FSL_A008585;
> + else if (IS_ENABLED(CONFIG_HISI_ERRATUM_161X01) &&
> + of_property_read_bool(np, "hisilicon,erratum-161x01"))
> + arch_timer_uses_erratum = HISILICON_161X01;
> + }
> +
> + if (arch_timer_uses_erratum) {
> + erratum_workaround = &arch_timer_erratum[arch_timer_uses_erratum - 1];
> + pr_info("Enabling workaround for %s\n", arch_timer_uses_erratum == FSL_A008585 ?
> + "FSL erratum A-008585" : "HISILICON ERRATUM 161x01");
> static_branch_enable(&arch_timer_read_ool_enabled);
> - pr_info("Enabling workaround for FSL erratum A-008585\n");
Get rid of arch_timer_uses_erratum, of the erratum identifier in the
structure, and put a static string in there. That should do everything
you need.
> }
> #endif
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol
From: Peter Griffin @ 2016-10-24 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-4-git-send-email-patrice.chotard@st.com>
Hi Patrice,
On Fri, 21 Oct 2016, patrice.chotard at st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> Driver code has been already removed, see
> http://www.spinics.net/lists/devicetree/msg143322.html
> Remove the multi_v7_defconfig part
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Cc: <rui.zhang@intel.com>
> Cc: <edubezval@gmail.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 15b2f99..45e252b 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
> CONFIG_ARMADA_THERMAL=y
> CONFIG_DAVINCI_WATCHDOG=m
> CONFIG_EXYNOS_THERMAL=m
> -CONFIG_ST_THERMAL_MEMMAP=y
Are you sure you want to remove this?
This Kconfig symbol is still used for the stih407 family
thermal parts in drivers/thermal/st/st_thermal_memmap.c?
My patch only removed the stih415/6 parts from the driver.
regards,
Peter.
^ permalink raw reply
* [PATCH 3/3] arm64: arch timer: Add timer erratum property for Hip05-d02 and Hip06-d03
From: Marc Zyngier @ 2016-10-24 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bf391642-82f7-2a3e-3118-1a8384a133e5@huawei.com>
Please write a proper commit message, no matter how trivial the patch is.
Thanks,
M.
On 23/10/16 04:21, Ding Tianhong wrote:
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> index bf322ed..9d18875 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> @@ -281,6 +281,7 @@
> <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
> <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
> <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> + hisilicon,erratum-161x01;
> };
>
> pmu {
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index 5927bc4..c38c658 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -260,6 +260,7 @@
> <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
> <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
> <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> + hisilicon,erratum-161x01;
> };
>
> pmu {
>
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Wolfram Sang @ 2016-10-24 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024100938.GI14477@dell>
> > > Even though axp20x-i2c seems to be the only "DT only" i2c client,
> > > would it make sense to add DT-based module autoloading to the i2c
> > > core?
> >
> > If it is not too invasive, then yes that would be a sensible addition IMHO.
>
> If I understand you correctly, I already have a patch-set on the ML
> that does this.
Incomplete, though. But we will see if Kieran finds time somewhen...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/f6b74cf4/attachment.sig>
^ permalink raw reply
* Question about arm64 earlycon
From: Marc Zyngier @ 2016-10-24 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4966376.bRx4fgSjbT@wuerfel>
On 24/10/16 11:06, Arnd Bergmann wrote:
> On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
>> Hi Catalin, Marc, Mark, Arnd,
>>
>> I am testing with 3.12 kernel with earlyprintk enabled and I see some
>> garbage characters in the console log right before the message
>> indicating that the real console device is initialized:
>>
>> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
>> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
>> console [ttyS0] enabled, bootconsole disabled
Well, you get two independent, unsynchronized bits of code writing to
the same peripheral. Things are bound to go badly. Unless you're trying
to debug things, do not use earlyprintk in production.
>>
>> I looked through early_prink.c file and printk.c file and it looks
>> like there is case that some early boot code can touch the UART
>> hardware via ealy console driver while the 'real' console driver is
>> setting up the same UART port? Please let me know if I missed some
>> important piece of code that can prevent this.
>
> I don't think we every supported earlyprintk on arm64, and
> earlycon support may have been added later.
We did support some form of earlyprintk for a while (though not in the
same way as 32bit ARM does), until Rob introduced earlycon.
> If you can't use a modern kernel, try backporting all the
> relevant earlycon changes.
Agreed. That's the most sensible course of action.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] kernel: irq: fix build failure
From: Lee Jones @ 2016-10-24 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1610211006370.4797@nanos>
On Fri, 21 Oct 2016, Thomas Gleixner wrote:
> On Fri, 21 Oct 2016, Stephen Rothwell wrote:
> > On Thu, 20 Oct 2016 14:55:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> > > I know. This is under discussion with the driver folks as we are not going
> > > to blindly export stuff just because someone slapped a irq_set_parent()
> > > into the code w/o knowing why.
> >
> > Do we have any idea if a resolution is close. This was first reported
> > in linux-next in September 14/15. :-(
>
> Grr. Yes. As much as I hate it, I'll go and export it for now. Should be
> able to get it into rc2.
Did this get in? I still have people complaining about it.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Lee Jones @ 2016-10-24 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024101659.GA1440@katana>
On Mon, 24 Oct 2016, Wolfram Sang wrote:
>
> > > > Even though axp20x-i2c seems to be the only "DT only" i2c client,
> > > > would it make sense to add DT-based module autoloading to the i2c
> > > > core?
> > >
> > > If it is not too invasive, then yes that would be a sensible addition IMHO.
> >
> > If I understand you correctly, I already have a patch-set on the ML
> > that does this.
>
> Incomplete, though. But we will see if Kieran finds time somewhen...
I was under the impression it was all but ready.
What are you waiting on?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Wolfram Sang @ 2016-10-24 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024103428.GA8574@dell>
> I was under the impression it was all but ready.
Then, I would have applied it.
> What are you waiting on?
Lee, I don't want to explain it *again*. Please re-read Kieran's last
attempt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/241ed28c/attachment.sig>
^ permalink raw reply
* [PATCH v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Tiffany Lin @ 2016-10-24 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024070542.65e11e37@vento.lan>
Hi Mauro,
On Mon, 2016-10-24 at 07:05 -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 24 Oct 2016 11:22:08 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > Hi Mauro,
> >
> > On Fri, 2016-10-21 at 11:01 -0200, Mauro Carvalho Chehab wrote:
> > > Em Fri, 2 Sep 2016 20:19:54 +0800
> > > Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
> > >
> > > > Add v4l2 layer decoder driver for MT8173
> > > >
> > > > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
> > >
> > > > +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> > > > +{
> > > > + int ret = 0;
> > > > +
> > > > + switch (fourcc) {
> > > > + case V4L2_PIX_FMT_H264:
> > > > + case V4L2_PIX_FMT_VP8:
> > > > + default:
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Did you ever test this driver? The above code will *always* return
> > > -EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!
> > >
> > > I suspect that what you wanted to do, instead, is:
> > >
> > > switch (fourcc) {
> > > case V4L2_PIX_FMT_H264:
> > > case V4L2_PIX_FMT_VP8:
> > > break;
> > > default:
> > > return -EINVAL;
> > >
> >
> > The original idea here is that vp8 and h264 are added in later patches.
> > If get this patch without later patches, it should return -EINVAL.
>
> I noticed your idea, but next time, don't add dead code like that.
> Reviewers check patch by patch at the order they're present at the
> patch series.
>
> So, don't add something broken by purpose, assuming that it would
> be fixed later.
>
Got it.
> >
> >
> > > Btw, this patch series has also several issues that were pointed by
> > > checkpatch. Please *always* run checkpatch when submitting your work.
> > >
> > > You should take a look at the Kernel documentation about how to
> > > submit patches, at:
> > > https://mchehab.fedorapeople.org/kernel_docs/process/index.html
> > >
> > > PS.: this time, I fixed the checkpatch issues for you. So, let me know
> > > if the patch below is OK, and I'll merge it at media upstream,
> > > assuming that the other patches in this series are ok.
> > >
> >
> > I did run checkpatch, but I don't know why these issues missed.
> > probably I run checkpatch for all files not for patches.
> > I will take a look at the documentation and keep this in mind for future
> > upstream.
> > Appreciated for your help.
>
> Checkpatch should be run patch by patch, as we expect that all patches
> will follow the coding style and will compile fine, without introducing
> warnings.
>
> I do compile the Kernel for every single patch I merge.
>
Got it. I will follow this.
best regards,
Tiffany
> Regards,
> Mauro
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PRM: initialize en_uart4_mask and grpsel_uart4_mask
From: Colin King @ 2016-10-24 11:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
In the case where has_uart4 is false, en_uart4_mask and grpsel_uart4_mask
are not initialized and so any garbage value is being logically or'd into
the write of PM_WKEN and OMAP3430_PM_MPUGRPSEL. Fix this by initializing
these masks to zero.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/arm/mach-omap2/prm3xxx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index 62680aa..718981b 100644
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@ -319,6 +319,9 @@ void __init omap3_prm_init_pm(bool has_uart4, bool has_iva)
if (has_uart4) {
en_uart4_mask = OMAP3630_EN_UART4_MASK;
grpsel_uart4_mask = OMAP3630_GRPSEL_UART4_MASK;
+ } else {
+ en_uart4_mask = 0;
+ grpsel_uart4_mask = 0;
}
/* Enable wakeups in PER */
--
2.9.3
^ permalink raw reply related
* [PATCH] iommu: arm-smmu-v2: Enable 16 bit ASID
From: Robin Murphy @ 2016-10-24 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477112524-13023-1-git-send-email-gakula@caviumnetworks.com>
Hi Geetha,
On 22/10/16 06:02, Geetha sowjanya wrote:
> Support up to 16 bit ASID. This patch enables
> 16 bit ASID when supported.
Why? "Because we can" is not a compelling rationale. I assume this is
actually related to the globally-unique ASID workaround for the TLB
sharing erratum, but if so that should be called out explicitly -
describe the problem being fixed.
> Signed-off-by: Geetha sowjanya <gakula@cavium.com>
> Acked-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
> ---
> drivers/iommu/arm-smmu.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..9740846 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -258,6 +258,9 @@ enum arm_smmu_s2cr_privcfg {
> #define TTBCR2_SEP_SHIFT 15
> #define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
>
> +#define TTBCR2_AS_SHIFT 4
> +#define TTBCR2_AS_ENABLE (1 << TTBCR2_AS_SHIFT)
> +
The style here for single-bit fields is simply:
#define TTBCR2_AS (1 << 4)
> #define TTBRn_ASID_SHIFT 48
>
> #define FSR_MULTI (1 << 31)
> @@ -773,6 +776,9 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> reg = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
> reg2 = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
> reg2 |= TTBCR2_SEP_UPSTREAM;
> + /* Enable 16 bit ASID if 16 bit VMID is supported */
> + if (smmu->features & ARM_SMMU_FEAT_VMID16)
This should be a check for AArch64 context format - VMID16 has nothing
to do with it. 16-bit ASID support for stage 1 AArch64 contexts is
already implied by SMMUv2 (TCR2.AS is not optional).
Robin.
> + reg |= TTBCR2_AS_ENABLE;
> }
> if (smmu->version > ARM_SMMU_V1)
> writel_relaxed(reg2, cb_base + ARM_SMMU_CB_TTBCR2);
>
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: okaya at codeaurora.org @ 2016-10-24 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VettN=-S+iqKQbqixRe2BM=AiS26VGM+8yLophbkc+Z8g@mail.gmail.com>
On 2016-10-24 03:30, Andy Shevchenko wrote:
> On Mon, Oct 24, 2016 at 5:55 AM, Sinan Kaya <okaya@codeaurora.org>
> wrote:
>> On 10/21/2016 12:11 PM, Andy Shevchenko wrote:
>>>> +static void hidma_free_msis(struct hidma_dev *dmadev)
>>>> > +{
>>>> > +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
>>> Perhaps one #ifdef and two definitions of functions?
>>
>> I don't think it will make a difference. I'll have to move
>> #ifdef around the caller of hidma_free_msis instead which
>> I think is uglier.
>>
>> The hidma_write_msi_msg function gets called only when
>> CONFIG_GENERIC_MSI_IRQ_DOMAIN is defined. If I don't put
>> this around the function definition, I get unused function
>> warning from the compiler. This is the reason why preprocessor
>> definition is outside of the function definition.
>
> I am talking about something like below:
>
> #ifdef UGLY_DEFINE
> myfunc_a()
> {
> }
>
> myfunc_b()
> {
> }
> #else
> static inline myfunc_a() {}
> static inline myfunc_b() {}
> #endif
>
>
> There is another way as well, namely use of IS_ENABLED(), IS_BUILTIN()
> macros (I don't remember how exactly second one is spelt).
This was my initial approach. I was asked to remove the stub functions.
So, I did it.
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Joerg Roedel @ 2016-10-24 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150916.0d274e9f@lwn.net>
On Fri, Oct 21, 2016 at 03:09:16PM -0600, Jonathan Corbet wrote:
> On Mon, 17 Oct 2016 16:26:23 +0100
> Punit Agrawal <punit.agrawal@arm.com> wrote:
>
> > The dma mapping api howto gives the impression that using the
> > dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> > to check all the components in the path from the device to memory for
> > addressing restrictions. In systems with address translations between
> > the device and memory (e.g., when using IOMMU), this implies that a
> > successful call to set set dma mask has checked the addressing
> > constraints of the intermediaries as well.
This is basically true when you have DMA controllers in the path from
device to memory. But it is not true for IOMMUs, because IOMMU drivers
are consumers of the dma-masks, they don't really restrict them. An
IOMMU driver knows the limitations of IOMMU hardware and counts that in
when allocating an address for a dma-buffer.
So long story short: Any IOMMU restrictions in address space size don't
need to be represented in the dma-mask for a device.
Joerg
^ permalink raw reply
* Question about arm64 earlycon
From: Mark Rutland @ 2016-10-24 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f1eeb4a-925a-9fac-d442-fbee503deb0a@arm.com>
On Mon, Oct 24, 2016 at 11:17:36AM +0100, Marc Zyngier wrote:
> On 24/10/16 11:06, Arnd Bergmann wrote:
> > On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
> >> Hi Catalin, Marc, Mark, Arnd,
> >>
> >> I am testing with 3.12 kernel with earlyprintk enabled and I see some
> >> garbage characters in the console log right before the message
> >> indicating that the real console device is initialized:
What exactly are you passing on the command line?
> >> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
> >> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
> >> console [ttyS0] enabled, bootconsole disabled
Was the UART already configured by FW? Had the firmware output anything
at this point?
Did the firmware's UART rate match that of the kernel? If not, the issue
might just be that the rate doesn't match; earlycon/earlyprintk won't
configure that, while the real console will.
Or perhaps we race with some clock configuration...
> >> I looked through early_prink.c file and printk.c file and it looks
> >> like there is case that some early boot code can touch the UART
> >> hardware via ealy console driver while the 'real' console driver is
> >> setting up the same UART port? Please let me know if I missed some
> >> important piece of code that can prevent this.
> >
> > I don't think we every supported earlyprintk on arm64, and
> > earlycon support may have been added later.
>
> We did support some form of earlyprintk for a while (though not in the
> same way as 32bit ARM does), until Rob introduced earlycon.
Our earlyprintk up until that point was effectively a less general
earlycon (coming up at a similar time). In fact, in v3.12 we were
already using earlycon structures in arch/arm64/kernel/early_printk.c.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Mark Rutland @ 2016-10-24 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962ea92f-870b-e1d0-5bb7-1a6d66c35122@huawei.com>
On Sun, Oct 23, 2016 at 11:21:10AM +0800, Ding Tianhong wrote:
> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
> + QorIQ erratum 161201, which says that reading the counter is
> + unreliable unless the small range of value is returned by back-to-back reads.
> + This also affects writes to the tval register, due to the implicit
> + counter read.
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard? Please
use the *exact* erratum number, even if that means we have to list
several.
Is "161x01" an *erratum* number, or the *part* number of affected
devices?
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/4] mtk_mdp_vpu: fix build with COMPILE_TEST for 32 bits
From: Minghsiu Tsai @ 2016-10-24 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd14afdb178cf490e257368bc899c7a0c690d140.1477058332.git.mchehab@s-opensource.com>
Hi Mauro,
This issue has been fixed by the patch below and merged in media tree,
and also signed by you.
Is it duplicate?
commit 37bf7e34ecc817ce6b8278588aeb22aab5635e1c
Author: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Date: Mon Sep 19 03:34:42 2016 -0300
[media] media: mtk-mdp: fix build warning in arch x86
This patch fix build warning in arch x86
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> When building on i386 in 32 bits, several new warnings appear:
>
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_handle_init_ack':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_ipi_handler':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_send_ap_ipi':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
>
> That's because the driver assumes that it will be built only on
> 64 bits. As we don't want extra warnings when building with 32
> bits, we need to double-cast.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> index fb07bf3dbd8b..b38d29e99f7a 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> @@ -25,7 +25,7 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu)
>
> static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
> {
> - struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> + struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
>
> /* mapping VPU address to kernel virtual address */
> vpu->vsi = (struct mdp_process_vsi *)
> @@ -37,7 +37,7 @@ static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv)
> {
> unsigned int msg_id = *(unsigned int *)data;
> struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
> - struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> + struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
> struct mtk_mdp_ctx *ctx;
>
> vpu->failure = msg->status;
> @@ -108,7 +108,7 @@ static int mtk_mdp_vpu_send_ap_ipi(struct mtk_mdp_vpu *vpu, uint32_t msg_id)
> msg.msg_id = msg_id;
> msg.ipi_id = IPI_MDP;
> msg.vpu_inst_addr = vpu->inst_addr;
> - msg.ap_inst = (uint64_t)vpu;
> + msg.ap_inst = (uint64_t)(long)vpu;
> err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
> if (!err && vpu->failure)
> err = -EINVAL;
> @@ -126,7 +126,7 @@ int mtk_mdp_vpu_init(struct mtk_mdp_vpu *vpu)
>
> msg.msg_id = AP_MDP_INIT;
> msg.ipi_id = IPI_MDP;
> - msg.ap_inst = (uint64_t)vpu;
> + msg.ap_inst = (uint64_t)(long)vpu;
> err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
> if (!err && vpu->failure)
> err = -EINVAL;
^ permalink raw reply
* [PATCH 4/4] mtk-mdp: fix compilation warnings if !DEBUG
From: Minghsiu Tsai @ 2016-10-24 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a24855fda4d91a58f119c2d70177017e06fc6f0.1477058332.git.mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> The mtk_mdp_dbg() is empty if !DEBUG. This causes the following
> warnings:
>
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function ?mtk_mdp_try_fmt_mplane?:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:231:52: warning: suggest braces around empty body in an ?if? statement [-Wempty-body]
> org_w, org_h, pix_mp->width, pix_mp->height);
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function ?mtk_mdp_m2m_start_streaming?:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:414:21: warning: suggest braces around empty body in an ?if? statement [-Wempty-body]
> ctx->id, ret);
> ^
>
> With could actually make the code to do something wrong. So,
> add an empty block to make it be parsed ok.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> index 2e979f97d1df..848569d4ab90 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> @@ -250,7 +250,7 @@ extern int mtk_mdp_dbg_level;
>
> #else
>
> -#define mtk_mdp_dbg(level, fmt, args...)
> +#define mtk_mdp_dbg(level, fmt, args...) {}
>
Acked-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> #define mtk_mdp_err(fmt, args...)
> #define mtk_mdp_dbg_enter()
> #define mtk_mdp_dbg_leave()
^ permalink raw reply
* [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Robin Murphy @ 2016-10-24 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477112061-12868-1-git-send-email-gakula@caviumnetworks.com>
[+Thomas, Jason, Marc]
On 22/10/16 05:54, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrupt controller before older PCI-inbound memory stores
> are committed.
> Doing a sync on SMMU will make sure all prior transactions are
> completed.
>
> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
> ---
> arch/arm64/Kconfig | 11 +++++++++++
> drivers/iommu/arm-smmu.c | 38 ++++++++++++++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-common.h | 1 +
> drivers/irqchip/irq-gic-v3-its.c | 22 ++++++++++++++++++++++
> kernel/irq/chip.c | 4 ++++
The irqchip maintainers should absolutely be CC'ed on this. Please use
get_maintainer.pl to check.
> 5 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 30398db..57f5c9b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -474,6 +474,17 @@ config CAVIUM_ERRATUM_27456
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_28168
> + bool "Cavium erratum 28168: Make sure ITS and SMMU TLB are in sync"
> + default y
> + help
> + Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + controller are delivered to the interrupt controller before older
> + PCI-inbound memory stores are committed. Doing a sync on SMMU
> + will make sure all prior transactions are completed.
Ouch! Is there definitely no other possible workaround, like overriding
transaction attributes, disabling hit-under-miss handling, or somesuch?
Does it have to be a global sync, or is syncing the relevant context
bank sufficient? (I have some half-finished patches to split up the TLB
maintenance ops, including finer-grained syncs wherever possible, which
I can resurrect).
> +
> + If unsure, say Y.
> +
> endmenu
>
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9740846..20a61c6 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -378,6 +378,7 @@ struct arm_smmu_device {
> unsigned int *irqs;
>
> u32 cavium_id_base; /* Specific to Cavium */
> + spinlock_t tlb_lock;
> };
>
> enum arm_smmu_context_fmt {
> @@ -576,9 +577,39 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
> static void arm_smmu_tlb_sync(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> + struct arm_smmu_device *smmu = smmu_domain->smmu;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
So *every* unmap operation on any SMMU ever now has to poll some slow
hardware for up to a second with IRQs disabled unconditionally? I don't
think that's acceptable for the general case.
> __arm_smmu_tlb_sync(smmu_domain->smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> }
>
> +/*
> + * Cavium ThunderX erratum 28168
> + *
> + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + * controller are delivered to the interrupt controller before older
> + * PCI-inbound memory stores are committed. Doing a sync on SMMU
> + * will make sure all prior transactions are completed.
> + *
> + */
> +void cavium_smmu_tlb_sync(struct device *dev)
> +{
> + struct arm_smmu_device *smmu;
> + struct arm_smmu_master_cfg *cfg;
> + unsigned long flags;
> +
> + smmu = find_smmu_for_device(dev);
Won't compile - that function no longer exists.
> + if (!smmu)
> + return;
> +
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
> + __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> +}
> +EXPORT_SYMBOL(cavium_smmu_tlb_sync);
> +
> static void arm_smmu_tlb_inv_context(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> @@ -586,6 +617,7 @@ static void arm_smmu_tlb_inv_context(void *cookie)
> struct arm_smmu_device *smmu = smmu_domain->smmu;
> bool stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
> void __iomem *base;
> + unsigned long flags;
>
> if (stage1) {
> base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> @@ -597,7 +629,9 @@ static void arm_smmu_tlb_inv_context(void *cookie)
> base + ARM_SMMU_GR0_TLBIVMID);
> }
>
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
> __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> }
>
> static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> @@ -1562,6 +1596,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
> void __iomem *cb_base;
> int i;
> + unsigned long flags;
> u32 reg, major;
>
> /* clear global FSR */
> @@ -1633,7 +1668,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> reg |= sCR0_VMID16EN;
>
> /* Push the button */
> + spin_lock_irqsave(&smmu->tlb_lock, flags)
> __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
After the fourth identical wrapping of the same function call, does it
not start to seem a better idea to implement a workaround *inside*
__arm_smmu_tlb_sync()?
> writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
> }
>
> @@ -2001,6 +2038,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> + spin_lock_init(&smmu->tlb_lock);
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index 205e5fd..0228ba0 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -38,4 +38,5 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>
> void gic_set_kvm_info(const struct gic_kvm_info *info);
>
> +void cavium_smmu_tlb_sync(void *iommu);
> #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 003495d..88e9958 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -112,6 +112,7 @@ struct its_device {
> struct its_node *its;
> struct event_lpi_map event_map;
> void *itt;
> + struct device *dev;
> u32 nr_ites;
> u32 device_id;
> };
> @@ -664,10 +665,29 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
> iommu_dma_map_msi_msg(d->irq, msg);
> }
>
> +/**
> + * Due to erratum in ThunderX,
> + * we need to make sure SMMU is in sync with ITS translations.
> + **/
> +static void its_ack_irq(struct irq_data *d)
> +{
> + struct its_device *its_dev = irq_data_get_irq_chip_data(d);
> + struct pci_dev *pdev;
> +
> + if (!dev_is_pci(its_dev->dev))
> + return;
> +
> + pdev = to_pci_dev(its_dev->dev);
> + if (pdev->vendor != 0x177d)
> + cavium_smmu_tlb_sync(its_dev->dev);
I'm pretty sure that makes any kernel built without CONFIG_ARM_SMMU fail
to link.
Robin.
> +
> +}
> +
> static struct irq_chip its_irq_chip = {
> .name = "ITS",
> .irq_mask = its_mask_irq,
> .irq_unmask = its_unmask_irq,
> + .irq_ack = its_ack_irq,
> .irq_eoi = irq_chip_eoi_parent,
> .irq_set_affinity = its_set_affinity,
> .irq_compose_msi_msg = its_irq_compose_msi_msg,
> @@ -1422,6 +1442,8 @@ static int its_msi_prepare(struct irq_domain *domain, struct device *dev,
> if (!its_dev)
> return -ENOMEM;
>
> + its_dev->dev = dev;
> +
> pr_debug("ITT %d entries, %d bits\n", nvec, ilog2(nvec));
> out:
> info->scratchpad[0].ptr = its_dev;
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index be3c34e..6add8da 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -585,6 +585,10 @@ void handle_fasteoi_irq(struct irq_desc *desc)
> goto out;
> }
>
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> + if (chip->irq_ack)
> + chip->irq_ack(&desc->irq_data);
> +#endif
> kstat_incr_irqs_this_cpu(desc);
> if (desc->istate & IRQS_ONESHOT)
> mask_irq(desc);
>
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Mark Rutland @ 2016-10-24 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cbf196b83cd9d175634e7056744dc649ae87f63.1477253239.git.joe@perches.com>
On Sun, Oct 23, 2016 at 01:40:49PM -0700, Joe Perches wrote:
> commit db4b0710fae9 ("arm64: fix show_regs fallout from KERN_CONT changes")
> corrected the KERN_CONT fallout from commit 4bcc595ccd80
> ("printk: reinstate KERN_CONT for printing continuation lines"), but
> the code still has unnecessary KERN_CONT uses. Remove them.
Why are these unnecessary KERN_CONTs a larger problem than duplicating
the format string for a third time? Having to duplicate it at all was
annoying enough.
Overall, to avoid messing with the KERN_CONT mess it'd be nicer to
format this all into a buffer (with the format string only existing the
once) and subsequently print it with one printk call.
> Miscellanea:
>
> o Remove unnecessary trailing blank from the output too.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/arm64/kernel/process.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 01753cd7d3f0..2278e7197a8e 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -190,18 +190,16 @@ void __show_regs(struct pt_regs *regs)
>
> i = top_reg;
>
> - while (i >= 0) {
> - printk("x%-2d: %016llx ", i, regs->regs[i]);
> + if (i >= 0 && !(i % 2)) {
This is difficult to read. Given we know that in either case i >= 0, and
to retain the style of existing code, this would be better as:
if (i % 2 == 0) {
> + printk("x%-2d: %016llx\n", i, regs->regs[i]);
> i--;
> -
> - if (i % 2 == 0) {
> - pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
> - i--;
> - }
> -
> - pr_cont("\n");
> }
> - printk("\n");
This should be retained. It's meant to be there *in addition* to the
newline on the final reg line.
> + while (i > 0) {
> + printk("x%-2d: %016llx x%-2d: %016llx\n",
> + i, regs->regs[i],
> + i - 1, regs->regs[i - 1]);
> + i -= 2;
> + }
> }
Thanks,
Mark.
^ 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