[PATCH v4 36/79] include/uapi/asm-generic/signal.h: use __kernel_size_t instead of size_t
Fixes userspace compiler error:
error: unknown type name ‘size_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/asm-generic/signal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/asm-generic/signal.h
b/include/uapi/asm-generic/signal.h
index 9df61f1..0a7c415 100644
--- a/include/uapi/asm-generic/signal.h
+++ b/include/uapi/asm-generic/signal.h
@@ -111,7 +111,7 @@ struct sigaction {
typedef struct sigaltstack {
void __user *ss_sp;
int ss_flags;
- size_t ss_size;
+ __kernel_size_t ss_size;
} stack_t;
#endif /* __ASSEMBLY__ */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h
Fixes userspace compilation error:
drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/drm_mode.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 359107a..0ed8d9d 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -508,14 +508,14 @@ struct drm_mode_crtc_page_flip {
/* create a dumb scanout buffer */
struct drm_mode_create_dumb {
- uint32_t height;
- uint32_t width;
- uint32_t bpp;
- uint32_t flags;
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
/* handle, pitch, size will be returned */
- uint32_t handle;
- uint32_t pitch;
- uint64_t size;
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
};
/* set up for mmap of a dumb scanout buffer */
@@ -532,7 +532,7 @@ struct drm_mode_map_dumb {
};
struct drm_mode_destroy_dumb {
- uint32_t handle;
+ __u32 handle;
};
/* page-flip flags are valid, plus: */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 22/79] cld.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h
Fixes userspace compilation errors like:
linux/nfsd/cld.h:40:2: error: unknown type name ‘uint16_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/linux/nfsd/cld.h | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/nfsd/cld.h b/include/uapi/linux/nfsd/cld.h
index f14a9ab..d9f2306 100644
--- a/include/uapi/linux/nfsd/cld.h
+++ b/include/uapi/linux/nfsd/cld.h
@@ -22,6 +22,8 @@
#ifndef _NFSD_CLD_H
#define _NFSD_CLD_H
+#include
+
/* latest upcall version available */
#define CLD_UPCALL_VERSION 1
@@ -37,18 +39,18 @@ enum cld_command {
/* representation of long-form NFSv4 client ID */
struct cld_name {
- uint16_tcn_len; /* length of cm_id */
+ __u16 cn_len; /* length of cm_id */
unsigned char cn_id[NFS4_OPAQUE_LIMIT]; /* client-provided */
} __attribute__((packed));
/* message struct for communication with userspace */
struct cld_msg {
- uint8_t cm_vers;/* upcall version */
- uint8_t cm_cmd; /* upcall command */
- int16_t cm_status; /* return code */
- uint32_tcm_xid; /* transaction id */
+ __u8cm_vers;/* upcall version */
+ __u8cm_cmd; /* upcall command */
+ __s16 cm_status; /* return code */
+ __u32 cm_xid; /* transaction id */
union {
- int64_t cm_gracetime; /* grace period start time */
+ __s64 cm_gracetime; /* grace period start time */
struct cld_name cm_name;
} __attribute__((packed)) cm_u;
} __attribute__((packed));
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 02/79] scripts/headers_compile_test.sh: compile test script for exported headers
Users of kernel header files would be happier if they did not contain kernel specific parts and would contain #include statements for all other header files that they depend on, and in general would compile. For each header file exported to userspace, this script creates a simple .c file which just includes the header file. Then it tries to compile it together with minimal header files from GCC and libc, and reports results. Default libc and GCC header file locations are parsed from compiler configuration. Kernel headers depend on GCC headers so their path is included in the test compiler command line. Some gcc and kernel headers depend on libc headers which are made available by copying from the compiler default location to a temporary location and removing possibly existing kernel headers from this directory. This is a bit of a hack but seems to work in multiple environments. Tested natively on: Debian unstable, i586-linux-gnu and gcc 4.9.2 Raspbian Wheezy, arm-linux-gnueabihf and gcc 4.6.3 Ubuntu 12.04 LTS, x86_64-linux-gnu and gcc 4.6.3 Tested cross compilation using standard CROSS_COMPILE=/path/to/gcc with: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 4.9.2 20140904 (prerelease) Execute the script in the directory where kernel header files are installed. For example: $ make headers_install $ cd usr/include $ ../../scripts/headers_compile_test.sh Example statistics from 3.18.4 kernel: 130 files failed the compile test. 609 files passed the compile test. Example error types from 3.18.4 kernel: $ ../../scripts/headers_compile_test.sh 2>&1 | \ grep error: | sed -e 's/.*error://g' | sort | uniq -c | sort -rn 352 unknown type name ‘uint32_t’ 134 unknown type name ‘uint64_t’ 103 unknown type name ‘size_t’ 43 unknown type name ‘__kernel_ulong_t’ 38 unknown type name ‘uint8_t’ 24 unknown type name ‘int32_t’ 22 field ‘addr’ has incomplete type 18 field ‘tstamp’ has incomplete type 16 unknown type name ‘__kernel_time_t’ 16 field ‘in’ has incomplete type 16 field ‘in6’ has incomplete type 14 unknown type name ‘__be16’ 13 ‘IFNAMSIZ’ undeclared here (not in a function) 12 unknown type name ‘uint16_t’ 9 field ‘ifru_netmask’ has incomplete type 9 field ‘ifru_hwaddr’ has incomplete type 9 field ‘ifru_dstaddr’ has incomplete type 9 field ‘ifru_broadaddr’ has incomplete type 9 field ‘ifru_addr’ has incomplete type 8 unknown type name ‘__kernel_pid_t’ 7 unknown type name ‘u_short’ 7 unknown type name ‘pid_t’ 6 invalid application of ‘sizeof’ to incomplete type ‘struct timespec’ 6 field ‘src’ has incomplete type 6 field ‘audio_tstamp’ has incomplete type 6 array type has incomplete element type 5 unknown type name ‘__kernel_long_t’ 5 requested alignment is not an integer constant 5 field ‘smsk’ has incomplete type 4 unknown type name ‘__kernel_uid32_t’ 4 unknown type name ‘__kernel_gid32_t’ 4 ‘ETH_ALEN’ undeclared here (not in a function) 3 unknown type name ‘int64_t’ 3 unknown type name ‘caddr_t’ 3 ‘IPSET_ERR_TYPE_SPECIFIC’ undeclared here (not in a function) 3 field ‘trigger_tstamp’ has incomplete type 3 field ‘src_addr’ has incomplete type 3 field ‘sin_addr’ has incomplete type 3 field ‘laddr’ has incomplete type 3 field ‘id’ has incomplete type 3 field ‘dmsk’ has incomplete type 3 field ‘bssid’ has incomplete type 3 expected specifier-qualifier-list before ‘uint64_t’ 2 unknown type name ‘u_long’ 2 unknown type name ‘stack_t’ 2 unknown type name ‘sigset_t’ 2 unknown type name ‘sa_family_t’ 2 unknown type name ‘__kernel_mode_t’ 2 unknown type name ‘__kernel_key_t’ 2 unknown type name ‘elf_gregset_t’ 2 unknown type name ‘bool’ 2 ‘uint64_t’ undeclared here (not in a function) 2 ‘true’ undeclared (first use in this function) 2 ‘NAME_MAX’ undeclared here (not in a function) 2 ‘__kernel_mode_t’ undeclared here (not in a function) 2 invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’ 2 field ‘uc_mcontext’ has incomplete type 2 field ‘tmsk’ has incomplete type 2 field ‘tgt’ has incomplete type 2 field ‘shm_perm’ has incomplete type 2 field ‘sem_perm’ has incomplete type 2 field ‘raddr’ has incomplete type 2 field ‘msg_perm’ has incomplete type 2 field ‘grp’ has incomplete type 2 field ‘dst’ has incomplete type 2 field ‘dst_addr’ has incomplete type 2 field ‘arp_pa’ has incomplete type 2 field ‘arp_netmask’ has incomplete type 2 field ‘arp_ha’ has incomplete type 2 ‘false’ undeclared (first use in this function) 1 xen/interface/xen.h: No such file or directory 1
[PATCH v4 03/79] drm.h: use __kernel_size_t instead of size_t
Fall back to size_t for non Linux platforms.
Fixes userspace compilation error:
drm/drm.h:132:2: error: unknown type name ‘size_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/drm.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..b4e92eb 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -54,6 +54,7 @@ typedef int32_t __s32;
typedef uint32_t __u32;
typedef int64_t __s64;
typedef uint64_t __u64;
+typedef size_t __kernel_size_t;
typedef unsigned long drm_handle_t;
#endif
@@ -129,11 +130,11 @@ struct drm_version {
int version_major;/**< Major version */
int version_minor;/**< Minor version */
int version_patchlevel; /**< Patch level */
- size_t name_len; /**< Length of name buffer */
+ __kernel_size_t name_len; /**< Length of name buffer */
char __user *name;/**< Name of driver */
- size_t date_len; /**< Length of date buffer */
+ __kernel_size_t date_len; /**< Length of date buffer */
char __user *date;/**< User-space buffer to hold date */
- size_t desc_len; /**< Length of desc buffer */
+ __kernel_size_t desc_len; /**< Length of desc buffer */
char __user *desc;/**< User-space buffer to hold desc */
};
@@ -143,7 +144,7 @@ struct drm_version {
* \sa drmGetBusid() and drmSetBusId().
*/
struct drm_unique {
- size_t unique_len;/**< Length of unique */
+ __kernel_size_t unique_len; /**< Length of unique */
char __user *unique; /**< Unique name for driver instantiation */
};
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 01/79] headers_install.sh: enhance error handling
Exit with error if using undefined variables or if any sub command fails with error return value. unidef needs special handling since but this can be done without the trap. Enables exaniming intermediate files if some commands failed. Signed-off-by: Mikko Rapeli --- scripts/headers_install.sh | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index fdebd66..fe22807 100755 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -1,4 +1,6 @@ #!/bin/sh +set -e +set -u if [ $# -lt 2 ] then @@ -26,7 +28,6 @@ shift # Iterate through files listed on command line FILE= -trap 'rm -f "$OUTDIR/$FILE" "$OUTDIR/$FILE.sed"' EXIT for i in "$@" do FILE="$(basename "$i")" @@ -37,10 +38,13 @@ do -e 's/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g' \ -e 's/(^|[ \t(])(inline|asm|volatile)([ \t(]|$)/\1__\2__\3/g' \ -e 's@#(ifndef|define|endif[ \t]*/[*])[ \t]*_UAPI@#\1 @' \ - "$SRCDIR/$i" > "$OUTDIR/$FILE.sed" || exit 1 + "$SRCDIR/$i" > "$OUTDIR/$FILE.sed" || \ + ( rm -f "$OUTDIR/$FILE.sed" ; exit 1 ) scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ "$OUTDIR/$FILE.sed" \ - > "$OUTDIR/$FILE" - [ $? -gt 1 ] && exit 1 + > "$OUTDIR/$FILE" || \ + ( if [ $? -gt 1 ]; then \ + rm -f "$OUTDIR/$FILE" "$OUTDIR/$FILE.sed" ; \ + exit 1 ; \ + fi ) rm -f "$OUTDIR/$FILE.sed" done -trap - EXIT -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Wed, Oct 14, 2015 at 06:57:33PM -0700, Christopher Hall wrote: > >>+#define SHADOW_HISTORY_DEPTH 7 > > > >And that number is 7 because? > > Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1 > ms (1 ms is the minimum jiffy length). Array size 4 would not be enough > history for the DSP which requires 4 ms of history, in the worst case. Just as I suspected, the magic number 7 is based on the needs of one particular user. What about the next user who comes along needing 10 milliseconds? That will not do. Any new interface should be generic enough to support a wide range of users. So I think this approach is all wrong. Here is an idea for you to consider. Instead of mucking with the TK, let the user code (possibly in-kernel) sample ART/sys pairs and interpolate the ART/dev time stamps. That way, the user can choose the range and resolution that he needs. > The audio driver is structured in such a way that it's simpler to provide a > value rather than a callback. Can you please provide a link to the audio driver that uses this new interface? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/79] Userspace compile test and fixes for exported uapi header files
v4: tried to fix v03 review findings tried to fix all hack patches v3: https://lkml.org/lkml/2015/5/30/96 tried to fix all v2 review findings tried to guess how to fix a few more issue with a few hacks, 0 files fail and 760 files pass the compile test on 32bit x86 v2: https://lkml.org/lkml/2015/2/16/521 added cross compiler support with CROSS_COMPILE, detecting libc and GCC headers from compiler, more header file fixes v1: https://lkml.org/lkml/2014/8/21/665 Users of kernel header files would be happier if they did not contain kernel specific parts and would contain #include statements for all other header files that they depend on, and in general would compile. This patch set introduces a compile test for headers exported to userspace and then fixes many of the userspace header compilation failures. Changes are also available in headers_test_v04 branch at github: https://github.com/mcfrisk/linux/tree/headers_test_v04 Here's how to run the userspace compile tests: $ make headers_install && cd usr/include && \ ../../scripts/headers_compile_test.sh Additionally tested an allyesconfig compilation on i686, x86_64 and ARMEL. For x86 and ARMEL all header file compile errors in userspace are fixed with this series and Ingo Molnars x86/headers branch changes from git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git . Remaining task is to fix all other archs. If these changes are merged, it becomes possible to run abi-compliance-checker tool https://lvc.github.io/abi-compliance-checker/ to detect API and ABI breakages from the uapi headers. Once all archs have completely compiling uapi headers, I would add this test to 'make headers_check' build target to prevent regressions. Mikko Rapeli (79): headers_install.sh: enhance error handling scripts/headers_compile_test.sh: compile test script for exported headers drm.h: use __kernel_size_t instead of size_t drm_mode.h: use __u32 and __u64 from linux/types.h exynos_drm.h: use __u64 from linux/types.h nouveau_drm.h: use __u32 and __u64 from linux/types.h radeon_drm.h: use __u32 and __u64 from linux/types.h r128_drm.h: include drm/drm.h via_drm.h: don't include non-existing via_drmclient.h via_drm.h: move struct via_file_private definition to drivers/gpu/drm/via/via_drv.h savage_drm.h: include include/uapi/drm/sis_drm.h: move sis_file_private to drivers/gpu/drm/sis/sis_drv.h drm/i810_drm.h: include drm/drm.h include/uapi/drm/vmwgfx_drm.h: use __s32, __u32 and __u64 from linux/types.h include/uapi/drm/qxl_drm.h: use __s32, __u32 and __u64 from linux/types.h include/uapi/linux/agpgart.h: include stdlib.h in userspace include/uapi/sound/emu10k1.h: added EMU10K1 version of DECLARE_BITMAP macro dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h hsi_char.h: use __u32 from linux/types.h include/uapi/linux/hsi/cs-protocol.h: include linux/time.h ebtables.h: use __u64 from linux/types.h cld.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h sctp.h: use __u8 and __u32 from linux/types.h scsi_bsg_fc.h: use __u8, __u32 and __u64 from linux/types.h scsi_netlink.h: use __u8, __u16 and __u64 from linux/types.h scsi_netlink_fc.h: use __u16, __u32 and __u64 from linux/types.h hdspm.h: use __u8, __u32 and __u64 from linux/types.h instead of stdint.h gntalloc.h: use __u16, __u32 and __u64 from linux/types.h gntdev.h: use __u32 and __u64 from linux/types.h include/uapi/linux/sysctl.h: use __kernel_size_t instead of size_t include/uapi/asm-generic/ipcbuf.h: include linux/posix_types.h include/uapi/asm-generic/msgbuf.h: include asm/ipcbuf.h include/uapi/asm-generic/shmbuf.h: include fixes asm-generic/sembuf.h: include asm/posix_types.h and asm/ipcbuf.h include/uapi/asm-generic/signal.h: use __kernel_size_t instead of size_t include/uapi/linux/socket.h: include sys/socket.h in userspace include/uapi/linux/rds.h: include linux/socket.h and linux/types.h include/uapi/linux/if_pppox.h: include linux/if.h include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h include/uapi/linux/ipv6_route.h: include linux/in6.h include/uapi/linux/ipv6_route.h: include linux/in6.h include/uapi/linux/if_pppol2tp.h: include linux/in.h and linux/in6.h include/uapi/linux/if_pppox.h: include linux/in.h and linux/in6.h linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h include/uapi/linux/packet_diag.h: include linux/netdevice.h include/uapi/linux/llc.h: include linux/if.h include/uapi/linux/mqueue.h: include linux/types.h include/uapi/linux/mroute.h: include linux/in.h include/uapi/linux/dlm_netlink.h: include linux/dlmconstants.h include/uapi/linux/ip6_tunnel.h: include linux/if.h and linux/in6.h include/uapi/netfilter/*.h: fix include files for compilation include/uapi/linux/errqueue.h: include linux/time.h
[PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory
Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer
dereference in order to avoid access to potentially freed memory.
Use 'of_get_next_parent()' to simplify the while() loop and avoid the
need of a temp variable.
Signed-off-by: Christophe JAILLET
---
v2: Use of_property_read_u32 instead of of_get_property+pointer dereference
*** Untested ***
---
arch/powerpc/sysdev/mpc5xxx_clocks.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c
b/arch/powerpc/sysdev/mpc5xxx_clocks.c
index f4f0301..92fbcf8 100644
--- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
+++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
@@ -13,21 +13,17 @@
unsigned long mpc5xxx_get_bus_frequency(struct device_node *node)
{
- struct device_node *np;
- const unsigned int *p_bus_freq = NULL;
+ u32 bus_freq = 0;
of_node_get(node);
while (node) {
- p_bus_freq = of_get_property(node, "bus-frequency", NULL);
- if (p_bus_freq)
+ if (!of_property_read_u32(node, "bus-frequency", _freq))
break;
- np = of_get_parent(node);
- of_node_put(node);
- node = np;
+ node = of_get_next_parent(node);
}
of_node_put(node);
- return p_bus_freq ? *p_bus_freq : 0;
+ return bus_freq;
}
EXPORT_SYMBOL(mpc5xxx_get_bus_frequency);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h
Am 14.10.2015 um 16:16 schrieb Nathan Lynch :
> On 10/14/2015 07:47 AM, H. Nikolaus Schaller wrote:
>>> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
>>> index aedec81..27a9a0b 100644
>>> --- a/arch/arm/vdso/vdsomunge.c
>>> +++ b/arch/arm/vdso/vdsomunge.c
>>> @@ -45,7 +45,18 @@
>>> * it does.
>>> */
>>>
>>> -#include
>>> +#define swab16(x) \
>>> + ((unsigned short)( \
>>> + (((unsigned short)(x) & (unsigned short)0x00ffU) << 8) | \
>>> + (((unsigned short)(x) & (unsigned short)0xff00U) >> 8) ))
>>> +
>>> +#define swab32(x) \
>>> + ((unsigned int)( \
>>> + (((unsigned int)(x) & (unsigned int)0x00ffUL) << 24) | \
>>> + (((unsigned int)(x) & (unsigned int)0xff00UL) << 8) | \
>>> + (((unsigned int)(x) & (unsigned int)0x00ffUL) >> 8) | \
>>> + (((unsigned int)(x) & (unsigned int)0xff00UL) >> 24) ))
>>> +
>>> #include
>>> #include
>>> #include
>>> @@ -104,17 +115,17 @@ static void cleanup(void)
>>>
>>> static Elf32_Word read_elf_word(Elf32_Word word, bool swap)
>>> {
>>> - return swap ? bswap_32(word) : word;
>>> + return swap ? swab32(word) : word;
>>> }
>>>
>>> static Elf32_Half read_elf_half(Elf32_Half half, bool swap)
>>> {
>>> - return swap ? bswap_16(half) : half;
>>> + return swap ? swab16(half) : half;
>>> }
>>>
>>> static void write_elf_word(Elf32_Word val, Elf32_Word *dst, bool swap)
>>> {
>>> - *dst = swap ? bswap_32(val) : val;
>>> + *dst = swap ? swab32(val) : val;
>>> }
>> ping.
>
> Sorry for the delay.
>
> This is okay but I'd prefer the swab macros to be below the #include
> lines,
Ok.
> and it would be easier for me to deal with a patch that isn't
> whitespace-damaged.
You mean:
ERROR: space prohibited before that close parenthesis ')'
#46: FILE: arch/arm/vdso/vdsomunge.c:64:
+ (((unsigned short)(x) & (unsigned short)0xff00U) >> 8) ))
ERROR: space prohibited before that close parenthesis ')'
#53: FILE: arch/arm/vdso/vdsomunge.c:71:
+ (((unsigned int)(x) & (unsigned int)0xff00UL) >> 24) ))
Well, I had copied that verbatim from arch/mips/boot/elf2ecoff.c and
thought that it is better readable, but it is easy to fix.
V3 is coming.
BR and thanks,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] ARM: fix vdsomunge not to depend on glibc specific byteswap.h
If the host toolchain is not glibc based then the arm kernel build
fails with
HOSTCC arch/arm/vdso/vdsomunge
arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or
directory
Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF
cross-compiler.
Reason: byteswap.h is a glibc only header.
Solution: replace by private byte-swapping macros (taken from
arch/mips/boot/elf2ecoff.c)
Tested to compile on Mac OS X 10.9.5 host.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/vdso/vdsomunge.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
index aedec81..513f9eb 100644
--- a/arch/arm/vdso/vdsomunge.c
+++ b/arch/arm/vdso/vdsomunge.c
@@ -45,7 +45,6 @@
* it does.
*/
-#include
#include
#include
#include
@@ -59,6 +58,18 @@
#include
#include
+#define swab16(x) \
+ ((unsigned short)( \
+ (((unsigned short)(x) & (unsigned short)0x00ffU) << 8) | \
+ (((unsigned short)(x) & (unsigned short)0xff00U) >> 8)))
+
+#define swab32(x) \
+ ((unsigned int)( \
+ (((unsigned int)(x) & (unsigned int)0x00ffUL) << 24) | \
+ (((unsigned int)(x) & (unsigned int)0xff00UL) << 8) | \
+ (((unsigned int)(x) & (unsigned int)0x00ffUL) >> 8) | \
+ (((unsigned int)(x) & (unsigned int)0xff00UL) >> 24)))
+
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define HOST_ORDER ELFDATA2LSB
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
@@ -104,17 +115,17 @@ static void cleanup(void)
static Elf32_Word read_elf_word(Elf32_Word word, bool swap)
{
- return swap ? bswap_32(word) : word;
+ return swap ? swab32(word) : word;
}
static Elf32_Half read_elf_half(Elf32_Half half, bool swap)
{
- return swap ? bswap_16(half) : half;
+ return swap ? swab16(half) : half;
}
static void write_elf_word(Elf32_Word val, Elf32_Word *dst, bool swap)
{
- *dst = swap ? bswap_32(val) : val;
+ *dst = swap ? swab32(val) : val;
}
int main(int argc, char **argv)
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
On 10/14/2015 08:53 PM, James Bottomley wrote: > On Wed, 2015-10-14 at 11:34 -0700, Lee Duncan wrote: >> On 10/14/2015 06:55 AM, James Bottomley wrote: >>> On Wed, 2015-10-07 at 16:51 -0700, Lee Duncan wrote: Update the SCSI hosts module to use the ida_simple*() routines to manage its host_no index instead of an ATOMIC integer. This means that the SCSI host number will now be reclaimable. >>> >>> OK, but why would we want to do this? We do it for sd because our minor >>> space for the device nodes is very constrained, so packing is essential. >>> For HBAs, there's no device space density to worry about, they're >>> largely statically allocated at boot time and not reusing the numbers >>> allows easy extraction of hotplug items for the logs (quite useful for >>> USB) because each separate hotplug has a separate and monotonically >>> increasing host number. >>> >>> James >>> >> >> Good question, James. Apologies for not making the need clear. >> >> The iSCSI subsystem uses a host structure for discovery, then throws it >> away. So each time it does discovery it gets a new host structure. With >> the current approach, that number is ever increasing. It's only a matter >> of time until some user with a hundreds of disks and perhaps thousands >> of LUNs, that likes to do periodic discovery (think super-computers) >> will run out of host numbers. Or, worse yet, get a negative number >> number (because the value is signed right now). >> >> And this use case is a real one right now, by the way. > > Um, so even if you do discovery continuously, say one every second, it > still will take 68 years before we wrap the sign. > >> As you can see from the patch, it's a small amount of code to ensure >> that the host number management is handled more cleanly. > > Well, I'm a bit worried about the loss of a monotonically increasing > host number from the debugging perspective. Right now, if you look at > any log, hostX always refers to one and only one incarnation throughout > the system lifetime for any given value of X. With your patch, the > lowest host number gets continually reused ... probably for every hot > plug event. If the USB and other hotplug system people don't mind this, > I suppose I can live with it, but I'd like to hear their view before > making this change. > Typically host numbers are not a real issue; whenever I need to debug something more often than not I need to figure out informations about the scsi device. And not once in my entire career I had any needs to rely on the SCSI host number. Plus the SCSI host number is the only thing in the stack which _does_ increase; everything else like bus/target/LUN numbers are stable and won't change much, irrespective of the number of rescans or unloads. Which always irritated me. So I'm definitely in favour of reusing the SCSI host numbers. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.com +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv
2015-10-12 16:31 GMT+08:00 Andy Shevchenko :
> On Mon, 2015-10-12 at 15:41 +0800, Xiang Wang wrote:
>> Hi, Andy
>> Thanks for your comments.
>>
>> [Andy] Don't see a relationship between PCI driver and this ACPI
>> stuff.
>> Although this is a pci driver, we may enumerate the i2c devices from
>> DSDT table while i2c controllers are enumerated via PCI. In this
>> scenario, in DSDT, there are descriptions of i2c devices as well as
>> i2c controllers. The ACPI node of i2c controllers are bond to i2c PCI
>> devices via pci-acpi glue.
>> So if we want to determine the i2c devices' settings (e.g. bus
>> speed),
>> we should leverage ACPI.
>>
>> Above is also the reason why the ACPI stuff is put in
>> i2c-designware-core: i2c_dw_acpi_setup_speed can be used by both plat
>> and pci driver. Thanks
>
> Wait, first of all let's divide parameters to two groups: a) to be
> applied to host driver, and b) to be applied to slave devices.
>
> The drivers/i2c/busses/i2c-designware* is about host driver parameters.
>
> Thus, PCI driver comes with hardcoded values since it's enumerated via
> PCI, and platform driver utilizes ACPI values.
>
> For slave devices everything is done in i2c-core.c.
>
> So, what exactly you are trying to enhance?
Agree on your analysis. The bus speed mode is a "host controller"
parameter. We can hardcode it in PCI driver.
However,
1. "bus speed mode" is a bit different from other parameters. Actually
it can be determined by the speed setting of "i2c devices" in ACPI
(I2CSerialBus). E.g. If i2c device uses 3MHz, we use High-speed mode
for this i2c bus.
2. If we hardcode speed setting in pci driver, we lose the
flexibility. A high-speed device may be connected to this i2c bus on
this board, but may be connected to another i2c bus on another board
design.
In this patch, we enumerate the i2c device in ACPI table to determine
the frequency setting. Then we set corresponding speed mode for this
i2c controller. The ACPI stuff is common for pci and plat driver. If
board design changes, we only change BIOS.
In conclusion, we have 2 solutions to set the i2c controller speed
mode (pci driver):
1) use hardcode value in pci driver
2) use frequency setting of "i2c device" in ACPI table (more flexible,
but looks a bit strange)
Do you have any preference/suggestions for above solutions? Thanks
>
>>
>> 2015-10-09 17:31 GMT+08:00 Andy Shevchenko <
>> andriy.shevche...@linux.intel.com>:
>> > On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
>> > > From: Xiang Wang
>> > >
>> > > 1. Support setting hs_hcnt and hs_lcnt
>> > > 2. Get bus speed mode from ACPI companion of the
>> > > i2c controller.
>> > >
>> > > Signed-off-by: Xiang Wang
>> > > ---
>> > > drivers/i2c/busses/i2c-designware-pcidrv.c | 7 +++
>> > > 1 file changed, 7 insertions(+)
>> > >
>> > > diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
>> > > b/drivers/i2c/busses/i2c-designware-pcidrv.c
>> > > index 6643d2d..0f4c0c4 100644
>> > > --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
>> > > +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
>> > > @@ -54,8 +54,10 @@ enum dw_pci_ctl_id_t {
>> > > struct dw_scl_sda_cfg {
>> > > u32 ss_hcnt;
>> > > u32 fs_hcnt;
>> > > + u32 hs_hcnt;
>> > > u32 ss_lcnt;
>> > > u32 fs_lcnt;
>> > > + u32 hs_lcnt;
>> > > u32 sda_hold;
>> > > };
>> > >
>> > > @@ -237,8 +239,10 @@ static int i2c_dw_pci_probe(struct pci_dev
>> > > *pdev,
>> > > cfg = controller->scl_sda_cfg;
>> > > dev->ss_hcnt = cfg->ss_hcnt;
>> > > dev->fs_hcnt = cfg->fs_hcnt;
>> > > + dev->hs_hcnt = cfg->hs_hcnt;
>> > > dev->ss_lcnt = cfg->ss_lcnt;
>> > > dev->fs_lcnt = cfg->fs_lcnt;
>> > > + dev->hs_lcnt = cfg->hs_lcnt;
>> > > dev->sda_hold_time = cfg->sda_hold;
>> > > }
>> > >
>> > > @@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev
>> > > *pdev,
>> > >
>> > > dev->tx_fifo_depth = controller->tx_fifo_depth;
>> > > dev->rx_fifo_depth = controller->rx_fifo_depth;
>> > > +
>> > > + i2c_dw_acpi_setup_speed(>dev, dev);
>> >
>> > Don't see a relationship between PCI driver and this ACPI stuff.
>> >
>> > > +
>> > > r = i2c_dw_init(dev);
>> > > if (r)
>> > > return r;
>> >
>> > --
>> > Andy Shevchenko
>> > Intel Finland Oy
>>
>>
>>
>
> --
> Andy Shevchenko
> Intel Finland Oy
--
Regards,
Xiang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/7] Smack: Handle labels consistently in untrusted mounts
On 10/13/2015 10:04 AM, Seth Forshee wrote:
> The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
> differently in untrusted mounts. This is confusing and
> potentically problematic. Change this to handle them all the same
> way that SMACK64 is currently handled; that is, read the label
> from disk and check it at use time. For SMACK64 and SMACK64MMAP
> access is denied if the label does not match smk_root. To be
> consistent with suid, a SMACK64EXEC label which does not match
> smk_root will still allow execution of the file but will not run
> with the label supplied in the xattr.
>
> Signed-off-by: Seth Forshee
Aside from the one comment below (which I can be talked out of)
this looks fine.
> ---
> security/smack/smack_lsm.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 621200f86b56..bee0b2652bf4 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
> struct inode *inode = file_inode(bprm->file);
> struct task_smack *bsp = bprm->cred->security;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int rc;
>
> if (bprm->cred_prepared)
> @@ -900,6 +901,10 @@ static int smack_bprm_set_creds(struct linux_binprm
> *bprm)
> if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
> return 0;
>
> + sbsp = inode->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED && isp->smk_task !=
> sbsp->smk_root)
Call me old fashioned, but how about
if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) && isp->smk_task !=
sbsp->smk_root)
naked '&'s give me the willies.
> + return 0;
> +
> if (bprm->unsafe & (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
> struct task_struct *tracer;
> rc = 0;
> @@ -1703,6 +1708,7 @@ static int smack_mmap_file(struct file *file,
> struct task_smack *tsp;
> struct smack_known *okp;
> struct inode_smack *isp;
> + struct superblock_smack *sbsp;
> int may;
> int mmay;
> int tmay;
> @@ -1714,6 +1720,10 @@ static int smack_mmap_file(struct file *file,
> isp = file_inode(file)->i_security;
> if (isp->smk_mmap == NULL)
> return 0;
> + sbsp = file_inode(file)->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED &&
> + isp->smk_mmap != sbsp->smk_root)
> + return -EACCES;
> mkp = isp->smk_mmap;
>
> tsp = current_security();
> @@ -3492,16 +3502,14 @@ static void smack_d_instantiate(struct dentry
> *opt_dentry, struct inode *inode)
> if (rc >= 0)
> transflag = SMK_INODE_TRANSMUTE;
> }
> - if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) {
> - /*
> - * Don't let the exec or mmap label be "*" or "@".
> - */
> - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> - if (IS_ERR(skp) || skp == _known_star ||
> - skp == _known_web)
> - skp = NULL;
> - isp->smk_task = skp;
> - }
> + /*
> + * Don't let the exec or mmap label be "*" or "@".
> + */
> + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> + if (IS_ERR(skp) || skp == _known_star ||
> + skp == _known_web)
> + skp = NULL;
> + isp->smk_task = skp;
>
> skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp);
> if (IS_ERR(skp) || skp == _known_star ||
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
On Wed, Oct 14, 2015 at 07:34:03PM -0700, Christopher Hall wrote: > I hope this is helpful. Thanks. So the DSP does not produce or consume system time stamps. Fine. Still I fail to understand why you need the system time. Thomas seems to say that there are *other* applications that will want to transform device time into system time, but why does your audio application use the system time, when the audio-to-ptp time is directly available, without any man in the middle? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/19] KVM: PPC: e500: fix handling local_sid_lookup result
On Thu, Sep 24, 2015 at 04:00:23PM +0200, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 > > Signed-off-by: Andrzej Hajda Thanks, applied to my kvm-ppc-next branch. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/31] perf tools: Add prologue for BPF programs for fetching arguments
On Wed, Oct 14, 2015 at 12:41:27PM +, Wang Nan wrote:
> From: He Kuang
>
> This patch generates prologue for a BPF program which fetch arguments
> for it. With this patch, the program can have arguments as follow:
>
> SEC("lock_page=__lock_page page->flags")
> int lock_page(struct pt_regs *ctx, int err, unsigned long flags)
> {
>return 1;
> }
>
> This patch passes at most 3 arguments from r3, r4 and r5. r1 is still
> the ctx pointer. r2 is used to indicate the successfulness of
> dereferencing.
>
> This patch uses r6 to hold ctx (struct pt_regs) and r7 to hold stack
> pointer for result. Result of each arguments first store on stack:
>
> low address
> BPF_REG_FP - 24 ARG3
> BPF_REG_FP - 16 ARG2
> BPF_REG_FP - 8 ARG1
> BPF_REG_FP
> high address
>
> Then loaded into r3, r4 and r5.
>
> The output prologue for offn(...off2(off1(reg should be:
>
> r6 <- r1 // save ctx into a callee saved register
> r7 <- fp
> r7 <- r7 - stack_offset // pointer to result slot
> /* load r3 with the offset in pt_regs of 'reg' */
> (r7) <- r3 // make slot valid
> r3 <- r3 + off1 // prepare to read unsafe pointer
> r2 <- 8
> r1 <- r7 // result put onto stack
> call probe_read // read unsafe pointer
> jnei r0, 0, err // error checking
> r3 <- (r7) // read result
> r3 <- r3 + off2 // prepare to read unsafe pointer
> r2 <- 8
> r1 <- r7
> call probe_read
> jnei r0, 0, err
> ...
> /* load r2, r3, r4 from stack */
> goto success
> err:
> r2 <- 1
> /* load r3, r4, r5 with 0 */
> goto usercode
> success:
> r2 <- 0
> usercode:
> r1 <- r6 // restore ctx
> // original user code
>
> If all of arguments reside in register (dereferencing is not
> required), gen_prologue_fastpath() will be used to create
> fast prologue:
>
> r3 <- (r1 + offset of reg1)
> r4 <- (r1 + offset of reg2)
> r5 <- (r1 + offset of reg3)
> r2 <- 0
>
> P.S.
>
> eBPF calling convention is defined as:
>
> * r0 - return value from in-kernel function, and exit value
> for eBPF program
> * r1 - r5 - arguments from eBPF program to in-kernel function
> * r6 - r9 - callee saved registers that in-kernel function will
> preserve
> * r10 - read-only frame pointer to access stack
>
> Signed-off-by: He Kuang
> Signed-off-by: Wang Nan
> Cc: Alexei Starovoitov
> Cc: Brendan Gregg
> Cc: Daniel Borkmann
> Cc: David Ahern
> Cc: He Kuang
> Cc: Jiri Olsa
> Cc: Kaixu Xia
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Cc: Zefan Li
> Cc: pi3or...@163.com
> Cc: Arnaldo Carvalho de Melo
> Link: http://lkml.kernel.org/n/ebpf-6yw9eg0ej3l4jnqhinngk...@git.kernel.org
> ---
[SNIP]
> +int bpf__gen_prologue(struct probe_trace_arg *args, int nargs,
> + struct bpf_insn *new_prog, size_t *new_cnt,
> + size_t cnt_space)
> +{
> + struct bpf_insn *success_code = NULL;
> + struct bpf_insn *error_code = NULL;
> + struct bpf_insn *user_code = NULL;
> + struct bpf_insn_pos pos;
> + bool fastpath = true;
> + int i;
> +
> + if (!new_prog || !new_cnt)
> + return -EINVAL;
> +
> + pos.begin = new_prog;
> + pos.end = new_prog + cnt_space;
> + pos.pos = new_prog;
> +
> + if (!nargs) {
> + ins(BPF_ALU64_IMM(BPF_MOV, BPF_PROLOGUE_FETCH_RESULT_REG, 0),
> + );
> +
> + if (check_pos())
> + goto errout;
> +
> + *new_cnt = pos_get_cnt();
> + return 0;
> + }
> +
> + if (nargs > BPF_PROLOGUE_MAX_ARGS)
> + nargs = BPF_PROLOGUE_MAX_ARGS;
Wouldn't it be better to inform user if it ignored some arguments?
Thanks,
Namhyung
> + if (cnt_space > BPF_MAXINSNS)
> + cnt_space = BPF_MAXINSNS;
> +
> + /* First pass: validation */
> + for (i = 0; i < nargs; i++) {
> + struct probe_trace_arg_ref *ref = args[i].ref;
> +
> + if (args[i].value[0] == '@') {
> + /* TODO: fetch global variable */
> + pr_err("bpf: prologue: global %s%+ld not support\n",
> + args[i].value, ref ? ref->offset : 0);
> + return -ENOTSUP;
> + }
> +
> + while (ref) {
> + /* fastpath is true if all args has ref == NULL */
> + fastpath = false;
> +
> + /*
> + * Instruction encodes immediate value using
> + * s32, ref->offset is long. On systems which
> + * can't fill long in s32, refuse to process if
> + * ref->offset too large (or small).
> + */
>
Re: v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
On Mon, Oct 12, 2015 at 10:02:06AM +0300, Jani Nikula wrote: > On Sat, 10 Oct 2015, Darren Hart wrote: > > The Debian 3.16.0 kernel does not emit the error, but I have not attempted a > > bisection. > > > > The warning was added by: > > 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) > > 2014-06-18 (1 year, 4 months ago), Oscar Mateo > > But we don't start hitting the warning right away with that commit, do > we? There's a bug about this with a bisected bad commit [1], please > let's track this there. I did a google search and didn't find any relevant hits for this error. So I reported it here. I should ahve searched the bug list also. I'll do that next time. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
[snip]
> >
> > I'm afraid more than that, the above litmus also shows that
> >
> > CPU 0 CPU 1
> > - -
> >
> > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > r3 = xchg_release(, 1); smp_mb();
> > r3 = READ_ONCE(x);
> >
> > (0:r3 == 0 && 1:r3 == 0 && a == 2) is not prohibitted
> >
> > in the implementation of this patchset, which should be disallowed by
> > the semantics of RELEASE, right?
>
> Not necessarily. If you had the read first on CPU 1, and you had a
> similar problem, I would be more worried.
>
Sometimes I think maybe we should say that a single unpaired ACQUIRE or
RELEASE doesn't have any order guarantee because of the above case.
But seems that's not a normal or even existing case, my bad ;-(
> > And even:
> >
> > CPU 0 CPU 1
> > - -
> >
> > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > smp_store_release(, 1); smp_mb();
> > r3 = READ_ONCE(x);
> >
> > (1:r3 == 0 && a == 2) is not prohibitted
> >
> > shows by:
> >
> > PPC weird-lwsync
> > ""
> > {
> > 0:r1=1; 0:r2=x; 0:r3=3; 0:r12=a;
> > 1:r1=2; 1:r2=x; 1:r3=3; 1:r12=a;
> > }
> > P0 | P1 ;
> > stw r1,0(r2) | stw r1,0(r12) ;
> > lwsync | sync ;
> > stw r1,0(r12) | lwz r3,0(r2) ;
> > exists
> > (a=2 /\ 1:r3=0)
> >
> > Please find something I'm (or the tool is) missing, maybe we can't use
> > (a == 2) as a indication that STORE on CPU 1 happens after STORE on CPU
> > 0?
>
> Again, if you were pairing the smp_store_release() with an smp_load_acquire()
> or even a READ_ONCE() followed by a barrier, I would be quite concerned.
> I am not at all worried about the above two litmus tests.
>
Understood, thank you for think through that ;-)
> > And there is really something I find strange, see below.
> >
> > > >
> > > > So the scenario that would fail would be this one, right?
> > > >
> > > > a = x = 0
> > > >
> > > > CPU0CPU1
> > > >
> > > > r3 = load_locked ();
> > > > a = 2;
> > > > sync();
> > > > r3 = x;
> > > > x = 1;
> > > > lwsync();
> > > > if (!store_cond(, 1))
> > > > goto again
> > > >
> > > >
> > > > Where we hoist the load way up because lwsync allows this.
> > >
> > > That scenario would end up with a==1 rather than a==2.
> > >
> > > > I always thought this would fail because CPU1's store to @a would fail
> > > > the store_cond() on CPU0 and we'd do the 'again' thing, re-issuing the
> > > > load and now seeing the new value (2).
> > >
> > > The stwcx. failure was one thing that prevented a number of other
> > > misordering cases. The problem is that we have to let go of the notion
> > > of an implicit global clock.
> > >
> > > To that end, the herd tool can make a diagram of what it thought
> > > happened, and I have attached it. I used this diagram to try and force
> > > this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC,
> > > and succeeded. Here is the sequence of events:
> > >
> > > o Commit P0's write. The model offers to propagate this write
> > > to the coherence point and to P1, but don't do so yet.
> > >
> > > o Commit P1's write. Similar offers, but don't take them up yet.
> > >
> > > o Commit P0's lwsync.
> > >
> > > o Execute P0's lwarx, which reads a=0. Then commit it.
> > >
> > > o Commit P0's stwcx. as successful. This stores a=1.
> > >
> > > o Commit P0's branch (not taken).
> >
> > So at this point, P0's write to 'a' has propagated to P1, right? But
> > P0's write to 'x' hasn't, even there is a lwsync between them, right?
> > Doesn't the lwsync prevent this from happening?
>
> No, because lwsync is quite a bit weaker than sync aside from just
> the store-load ordering.
>
Understood, I've tried the ppcmem, much clear now ;-)
> > If at this point P0's write to 'a' hasn't propagated then when?
>
> Later. At the very end of the test, in this case. ;-)
>
Hmm.. I tried exactly this sequence in ppcmem, seems propagation of P0's
write to 'a' is never an option...
> Why not try creating a longer litmus test that requires P0's write to
> "a" to propagate to P1 before both processes complete?
>
I will try to write one, but to be clear, you mean we still observe
0:r3 == 0 && a == 2 && 1:r3 == 0
at the end, right? Because I understand that if P1's write to 'a'
doesn't override P0's, P0's write to 'a' will propagate.
Regards,
Boqun
signature.asc
Re: [PATCH v2 0/5] intel_scu_ipc: bug fixes and amendments
On Mon, Oct 12, 2015 at 02:19:43PM +0300, Andy Shevchenko wrote: > There are couple of bugfixes (patches 1 & 5) and amendments to the driver. > > Patch series has been tested on Intel Medfield and Intel Edison (Merrifield) > boards. > > Changes v2: > - improve patch 4 commit message (suggested by Darren) > - leave only fix of a potential bug in patch 5 Thank you Andy, queued to testing. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: Introduce kernelcore=reliable option
Xeon E7 v3 based systems supports Address Range Mirroring
and UEFI BIOS complied with UEFI spec 2.5 can notify which
ranges are reliable (mirrored) via EFI memory map.
Now Linux kernel utilize its information and allocates
boot time memory from reliable region.
My requirement is:
- allocate kernel memory from reliable region
- allocate user memory from non-reliable region
In order to meet my requirement, ZONE_MOVABLE is useful.
By arranging non-reliable range into ZONE_MOVABLE,
reliable memory is only used for kernel allocations.
This patch extends existing "kernelcore" option and
introduces kernelcore=reliable option. By specifying
"reliable" instead of specifying the amount of memory,
non-reliable region will be arranged into ZONE_MOVABLE.
Earlier discussion is at:
https://lkml.org/lkml/2015/10/9/24
For example, suppose 2-nodes system with the following
memory range:
node 0 [mem 0x1000-0x00109fff]
node 1 [mem 0x0010a000-0x00209fff]
and the following ranges are marked as reliable (*):
[0x-0x0001]
[0x0001-0x00018000]
[0x0010a000-0x00112000]
If you specify kernelcore=reliable, Movable zones are
arranged like the following:
Movable zone start for each node
Node 0: 0x00018000
Node 1: 0x00112000
(*) I specified the following instead of using UEFI BIOS
complied with UEFI spec 2.5,
efi_fake_mem=4G@0:0x1,2G@0x10a000:0x1,2G@4G:0x1
efi_fake_mem is found at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
tags/efi-next
Signed-off-by: Taku Izumi
---
Documentation/kernel-parameters.txt | 9 -
mm/page_alloc.c | 26 ++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cd5312f..b2c8c13 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1663,7 +1663,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
keepinitrd [HW,ARM]
- kernelcore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter
+ kernelcore= Format: nn[KMG] | "reliable"
+ [KNL,X86,IA-64,PPC] This parameter
specifies the amount of memory usable by the kernel
for non-movable allocations. The requested amount is
spread evenly throughout all nodes in the system. The
@@ -1679,6 +1680,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
use the HighMem zone if it exists, and the Normal
zone if it does not.
+ Instead of specifying the amount of memory (nn[KMS]),
+ you can specify "reliable" option. In case "reliable"
+ option is specified, reliable memory is used for
+ non-movable allocations and remaining memory is used
+ for Movable pages.
+
kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port.
Format: [,poll interval]
The controller # is the number of the ehci usb debug
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index beda417..d0b3ac9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -221,6 +221,7 @@ static unsigned long __meminitdata
arch_zone_highest_possible_pfn[MAX_NR_ZONES];
static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+static bool reliable_kernelcore __initdata;
/* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -5618,6 +5619,25 @@ static void __init find_zone_movable_pfns_for_nodes(void)
}
/*
+* If kernelcore=reliable is specified, ignore movablecore option
+*/
+ if (reliable_kernelcore) {
+ for_each_memblock(memory, r) {
+ if (memblock_is_mirror(r))
+ continue;
+
+ nid = r->nid;
+
+ usable_startpfn = PFN_DOWN(r->base);
+ zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
+ min(usable_startpfn, zone_movable_pfn[nid]) :
+ usable_startpfn;
+ }
+
+ goto out2;
+ }
+
+ /*
* If movablecore=nn[KMG] was specified, calculate what size of
* kernelcore that corresponds so that memory usable for
* any allocation type is evenly spread. If both kernelcore
@@ -5873,6 +5893,12 @@ static int __init cmdline_parse_core(char *p, unsigned
long *core)
*/
static int __init cmdline_parse_kernelcore(char *p)
{
+ /* parse
Re: [PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Hello Tony,
Am 15.10.2015 um 00:20 schrieb Tony Lindgren:
* Tony Lindgren [151014 10:56]:
* Heiko Schocher [151012 22:58]:
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.
Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?
Actually I think we may have a regression somwhere. If you look
at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
this should all be handled by drivers/misc/sram.c nowadays.
So for most SoCs, we should completely skip the plat-omap/sram.c
code.
Yes, correct. So it should be enough for changing the DT, thanks.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [trivial] treewide: Fix typo in printk
This patch fix multiple spelling typos found in
various part of kernel.
Signed-off-by: Masanari Iida
---
drivers/firmware/efi/libstub/fdt.c | 2 +-
drivers/infiniband/hw/cxgb4/cm.c | 2 +-
drivers/md/raid0.c | 4 ++--
drivers/media/common/saa7146/saa7146_video.c | 2 +-
drivers/media/dvb-frontends/m88ds3103.c| 2 +-
drivers/media/dvb-frontends/si2165.c | 4 ++--
drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c| 2 +-
drivers/soc/ti/knav_dma.c | 2 +-
sound/drivers/pcm-indirect2.c | 2 +-
sound/usb/6fire/firmware.c | 2 +-
11 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/efi/libstub/fdt.c
b/drivers/firmware/efi/libstub/fdt.c
index b62e2f5..cf7b7d4 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -253,7 +253,7 @@ efi_status_t
allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
sys_table->boottime->free_pool(memory_map);
new_fdt_size += EFI_PAGE_SIZE;
} else {
- pr_efi_err(sys_table, "Unable to constuct new device
tree.\n");
+ pr_efi_err(sys_table, "Unable to construct new device
tree.\n");
goto fail_free_mmap;
}
}
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index debc39d..9a389a0 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -449,7 +449,7 @@ static void act_open_req_arp_failure(void *handle, struct
sk_buff *skb)
{
struct c4iw_ep *ep = handle;
- printk(KERN_ERR MOD "ARP failure duing connect\n");
+ printk(KERN_ERR MOD "ARP failure during connect\n");
kfree_skb(skb);
connect_reply_upcall(ep, -EHOSTUNREACH);
state_set(>com, DEAD);
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index f8e5db0..2ea12c6 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -549,13 +549,13 @@ static void *raid0_takeover_raid10(struct mddev *mddev)
* - all mirrors must be already degraded
*/
if (mddev->layout != ((1 << 8) + 2)) {
- printk(KERN_ERR "md/raid0:%s:: Raid0 cannot takover layout:
0x%x\n",
+ printk(KERN_ERR "md/raid0:%s:: Raid0 cannot takeover layout:
0x%x\n",
mdname(mddev),
mddev->layout);
return ERR_PTR(-EINVAL);
}
if (mddev->raid_disks & 1) {
- printk(KERN_ERR "md/raid0:%s: Raid0 cannot takover Raid10 with
odd disk number.\n",
+ printk(KERN_ERR "md/raid0:%s: Raid0 cannot takeover Raid10 with
odd disk number.\n",
mdname(mddev));
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/media/common/saa7146/saa7146_video.c
b/drivers/media/common/saa7146/saa7146_video.c
index 3077949..079f520 100644
--- a/drivers/media/common/saa7146/saa7146_video.c
+++ b/drivers/media/common/saa7146/saa7146_video.c
@@ -502,7 +502,7 @@ static int vidioc_s_fbuf(struct file *file, void *fh, const
struct v4l2_framebuf
/* check if overlay is running */
if (IS_OVERLAY_ACTIVE(fh) != 0) {
if (vv->video_fh != fh) {
- DEB_D("refusing to change framebuffer informations
while overlay is active in another open\n");
+ DEB_D("refusing to change framebuffer information while
overlay is active in another open\n");
return -EBUSY;
}
}
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index ff31e7a..508bb07 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -664,7 +664,7 @@ static int m88ds3103_init(struct dvb_frontend *fe)
/* request the firmware, this will block and timeout */
ret = request_firmware(, fw_file, >dev);
if (ret) {
- dev_err(>dev, "firmare file '%s' not found\n", fw_file);
+ dev_err(>dev, "firmware file '%s' not found\n",
fw_file);
goto err;
}
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index 7c2..1fcd925 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -511,7 +511,7 @@ static int si2165_upload_firmware(struct si2165_state
*state)
, block_count);
if (ret < 0) {
dev_err(>i2c->dev,
- "%s: firmare could not be uploaded\n",
+ "%s: firmware could not be uploaded\n",
KBUILD_MODNAME);
goto error;
[PATCH net-next] net: hisilicon: fixes a bug when using ethtool -S
From: lipeng
this patch fixes a bug in hns driver. when we want to get statistic info
by using ethtool -S, it shows us there are 3 wrong counters info. because
the strings related to the registers are wrong. it needs to modify the
strings which give us wrong info.
Signed-off-by: lipeng
Signed-off-by: yankejian
Signed-off-by: Yisen Zhuang
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index dab5ecf..802d554 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -51,9 +51,9 @@ static const struct mac_stats_string g_xgmac_stats_string[] =
{
{"xgmac_rx_bad_pkt_from_dsaf", MAC_STATS_FIELD_OFF(rx_bad_from_sw)},
{"xgmac_tx_bad_pkt_64tomax", MAC_STATS_FIELD_OFF(tx_bad_pkts)},
- {"xgmac_rx_not_well_pkt", MAC_STATS_FIELD_OFF(rx_fragment_err)},
- {"xgmac_rx_good_well_pkt", MAC_STATS_FIELD_OFF(rx_undersize)},
- {"xgmac_rx_total_pkt", MAC_STATS_FIELD_OFF(rx_under_min)},
+ {"xgmac_rx_bad_pkts_minto64", MAC_STATS_FIELD_OFF(rx_fragment_err)},
+ {"xgmac_rx_good_pkts_minto64", MAC_STATS_FIELD_OFF(rx_undersize)},
+ {"xgmac_rx_total_pkts_minto64", MAC_STATS_FIELD_OFF(rx_under_min)},
{"xgmac_rx_pkt_64", MAC_STATS_FIELD_OFF(rx_64bytes)},
{"xgmac_rx_pkt_65to127", MAC_STATS_FIELD_OFF(rx_65to127)},
{"xgmac_rx_pkt_128to255", MAC_STATS_FIELD_OFF(rx_128to255)},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] watchdog: Add sysctl knob hardlockup_panic
Hi Don, [auto build test ERROR on next-20151013 -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Don-Zickus/watchdog-Add-sysctl-knob-hardlockup_panic/20151015-104506 config: sparc64-defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc64 All errors (new ones prefixed by >>): >> kernel/built-in.o:(.data+0x24b8): undefined reference to `hardlockup_panic' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack
Jungseok,
On 10/14/2015 09:55 PM, Jungseok Lee wrote:
On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
On 10/09/2015 11:24 PM, James Morse wrote:
Hi Jungseok,
On 07/10/15 16:28, Jungseok Lee wrote:
Currently, a call trace drops a process stack walk when a separate IRQ
stack is used. It makes a call trace information much less useful when
a system gets paniked in interrupt context.
panicked
This patch addresses the issue with the following schemes:
- Store aborted stack frame data
- Decide whether another stack walk is needed or not via current sp
- Loosen the frame pointer upper bound condition
It may be worth merging this patch with its predecessor - anyone trying to
bisect a problem could land between these two patches, and spend time
debugging the truncated call traces.
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index 6ea82e8..e5904a1 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -2,13 +2,25 @@
#define __ASM_IRQ_H
#include
+#include
#include
struct irq_stack {
void *stack;
+ struct stackframe frame;
};
+DECLARE_PER_CPU(struct irq_stack, irq_stacks);
Good idea, storing this in the per-cpu data makes it immune to stack
corruption.
Is this the only reason that you have a dummy stack frame in per-cpu data?
By placing this frame in an interrupt stack, I think, we will be able to
eliminate
changes in dump_stace(). and
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 407991b..5124649 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -43,7 +43,27 @@ int notrace unwind_frame(struct stackframe *frame)
low = frame->sp;
high = ALIGN(low, THREAD_SIZE);
- if (fp < low || fp > high - 0x18 || fp & 0xf)
+ /*
+* A frame pointer would reach an upper bound if a prologue of the
+* first function of call trace looks as follows:
+*
+* stp x29, x30, [sp,#-16]!
+* mov x29, sp
+*
+* Thus, the upper bound is (top of stack - 0x20) with consideration
The terms 'top' and 'bottom' of the stack are confusing, your 'top' appears
to be the highest address, which is used first, making it the bottom of the
stack.
I would try to use the terms low/est and high/est, in keeping with the
variable names in use here.
+* of a 16-byte empty space in THREAD_START_SP.
+*
+* The value, 0x20, however, does not cover all cases as interrupts
+* are handled using a separate stack. That is, a call trace can start
+* from elx_irq exception vectors. The symbols could not be promoted
+* to candidates for a stack trace under the restriction, 0x20.
+*
+* The scenario is handled without complexity as 1) considering
+* (bottom of stack + THREAD_START_SP) as a dummy frame pointer, the
+* content of which is 0, and 2) allowing the case, which changes
+* the value to 0x10 from 0x20.
Where has 0x20 come from? The old value was 0x18.
My understanding is the highest part of the stack looks like this:
high[ off-stack ]
high - 0x08 [ left free by THREAD_START_SP ]
high - 0x10 [ left free by THREAD_START_SP ]
high - 0x18 [#1 x30 ]
high - 0x20 [#1 x29 ]
So the condition 'fp > high - 0x18' prevents returning either 'left free'
address, or off-stack-value as a frame. Changing it to 'fp > high - 0x10'
allows the first half of that reserved area to be a valid stack frame.
This change is breaking perf using incantations [0] and [1]:
Before, with just patch 1/2:
---__do_softirq
|
|--92.95%-- __handle_domain_irq
| __irqentry_text_start
| el1_irq
|
After, with both patches:
---__do_softirq
|
|--83.83%-- __handle_domain_irq
| __irqentry_text_start
| el1_irq
| |
| |--99.39%-- 0x48040d0c
| --0.61%-- [...]
|
This also shows that walk_stackframe() doesn't walk through a process stack.
Now I'm trying the following hack on top of Jungseok's patch.
(It doesn't traverse from an irq stack to an process stack yet. I need modify
unwind_frame().)
I've got a difference between perf and dump_backtrace() as reviewing perf call
chain operation. Perf relies on walk_stackframe(), but dump_backtrace() does
not.
That is, a symbol is printed out *before* unwind_frame() call in case of perf.
By contrast, dump_backtrace() records a symbol *after* unwind_frame(). I think
perf behavior is correct since frame.pc is retrieved from a valid stack frame.
So, the following diff is a prerequisite.
Re: [PATCH v6 01/10] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit
On Thu, Oct 15, 2015 at 09:35:12AM +0800, Shawn Lin wrote: > From: Boojin Kim > Please fix the subsystem name in this series. Its dmaengine:... Git log should tell you the acceptable style for a subsystem -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver
On Wed, Oct 14, 2015 at 05:41:26PM +0200, M'boumba Cedric Madianga wrote: > 2015-10-14 17:28 GMT+02:00 Daniel Thompson : > > On 14/10/15 16:26, M'boumba Cedric Madianga wrote: > >> > >> 2015-10-14 16:24 GMT+02:00 Daniel Thompson : > >>> > >>> > >>> Hmnnn... > >>> > >>> The dmaengine framework will WARN_ONCE() if an dmaengine is removed > >>> whilst > >>> it is active and also works hard to ensure dmaengine modules are not > >>> removed > >>> whilst there are active drivers using the framework. > >>> > >>> How do we get into this function whilst there is still an active DMA > >>> channels? > >> > >> > >> For example, when a user try "rmmod stm32-dma" in uart console. > >> It will enter in stm32_dma_remove while there is potentially still active > >> DMA. > > > > > > Check dmaengine.c for yourself but I think in this case the dmaengine > > framework will hold references to the module and prevent the remove from > > taking place. > > Yes I did it. > As far I understand, the dmaengine framework will print a warning > message but doesn't stop removing operation if there are some active > clients. we hold a ref, so removal wont work, see dma_chan_get() -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_caps interface
On Thu, Oct 15, 2015 at 09:36:38AM +0800, Shawn Lin wrote:
> +int snd_dmaengine_pcm_get_caps(struct device *dev, struct dma_slave_caps
> *caps)
> +{
> + struct snd_soc_platform *platform;
> + struct dmaengine_pcm *pcm;
> + int ret = -ENODEV;
> +
> + platform = snd_soc_lookup_platform(dev);
> + if (!platform)
> + return ret;
> +
> + pcm = soc_platform_to_pcm(platform);
> +
> + if (pcm->chan)
> + ret = dma_get_slave_caps(pcm->chan[0], caps);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_get_caps);
I don't see the need of this wrapper if you are not going to use this inside
common code.. Why not read this in driver, anyway you setting taht up in
next patch
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Hello Tony,
Am 14.10.2015 um 19:49 schrieb Tony Lindgren:
* Heiko Schocher [151012 22:58]:
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.
Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?
I need it for an upcoming boards support, so 4.4 is fine for me,
thanks!
bye,
Heiko
Regards,
Tony
Signed-off-by: Heiko Schocher
Signed-off-by: Ayoub Zaki
---
arch/arm/mach-omap2/sram.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@
#define GP_DEVICE 0x300
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE 0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA 0x4030
+#define AM33XX_SRAM_PUB_PA (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE 0xfc00 /* 63K */
+
#define ROUND_DOWN(value,boundary)((value) & (~((boundary)-1)))
static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+ } else if (soc_is_am33xx()) {
+ omap_sram_start = AM33XX_SRAM_PUB_PA;
+ omap_sram_size = AM33XX_SRAM_PUB_SIZE;
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
--
2.1.0
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation
On Wed, Oct 14, 2015 at 06:02:18PM +0300, Peter Ujfalusi wrote:
> On 10/14/2015 05:41 PM, Vinod Koul wrote:
> > On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> >> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor
> >> *edma_prep_dma_memcpy(
> >>struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> >>size_t len, unsigned long tx_flags)
> >> {
> >> - int ret;
> >> + int ret, nslots;
> >>struct edma_desc *edesc;
> >>struct device *dev = chan->device->dev;
> >>struct edma_chan *echan = to_edma_chan(chan);
> >> - unsigned int width;
> >> + unsigned int width, pset_len;
> >>
> >>if (unlikely(!echan || !len))
> >>return NULL;
> >>
> >> - edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> >> + if (len < SZ_64K) {
> >> + /*
> >> + * Transfer size less than 64K can be handled with one paRAM
> >> + * slot. ACNT = length
> >> + */
> >> + width = len;
> >> + pset_len = len;
> >> + nslots = 1;
> >> + } else {
> >> + /*
> >> + * Transfer size bigger than 64K will be handled with maximum of
> >> + * two paRAM slots.
> >> + * slot1: ACNT = 32767, length1: (length / 32767)
> >> + * slot2: the remaining amount of data.
> >> + */
> >> + width = SZ_32K - 1;
> >> + pset_len = rounddown(len, width);
> >> + /* One slot is enough for lengths multiple of (SZ_32K -1) */
> >
> > Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> > slot and 12K in second slot ?
>
> Not exactly. If the size is less than 64K it can be done with one 'burst' but
> if it is bigger we need to have two sets of transfer:
> 1. 32K blocks
> 2. the remaining data
>
> so in case of 140K:
> 4 x 32K followed by 12K
Okay this part wasn't very clear to me, can you please add some comment
explaining this bit
>
> >
> > Is there a limit on 'blocks' of 64K we can do here?
>
> 32767 32K blocks is the limit.
>
> The 64K burst is only possible if the whole transfer is less less than 64K.
> With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
> we need to use the BCNT counter and for that to work the the distance between
> the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
> this is the reason why we have 32K 'blocks' to transfer first followed by the
> remaining.
Okay IIUC, we have option to single burst if its less that 64K using one
slot, otherwise split to 32K chunk with 2 slots, or would it be N in that
case
Really need more documentation here :)
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: don't test shrinker_enabled in zs_shrinker_count()
On (10/15/15 11:29), Minchan Kim wrote:
[..]
> I'm in favor of removing shrinker disable feature with this patch(
> although we didn't implement it yet) because if there is some problem
> of compaction, we should reveal and fix it without hiding with the
> feature.
>
sure.
> One thing I want is if we decide it, let's remove all things
> about shrinker_enabled(ie, variable).
> If we might need it later, we could introduce it easily.
well, do we really want to make the shrinker a vital part of zsmalloc?
it's not that we will tighten the dependency between zsmalloc and
shrinker, we will introduce it instead. in a sense that, at the moment,
zsmalloc is, let's say, ignorant to shrinker registration errors
(shrinker registration implementation is internal to shrinker), because
there is no direct impact on zsmalloc functionality -- zsmalloc will not
be able to release some pages (there are if-s here: first, zsmalloc
shrinker callback may even not be called; second, zsmalloc may not be
albe to migrate objects and release objects).
no really strong opinion against, but at the same time zsmalloc will
have another point of failure (again, zsmalloc should not be aware of
shrinker registration implementation and why it may fail).
so... I can prepare a new patch later today.
-ss
>
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > mm/zsmalloc.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 7ad5e54..8ba247d 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1822,9 +1822,6 @@ static unsigned long zs_shrinker_count(struct
> > shrinker *shrinker,
> > struct zs_pool *pool = container_of(shrinker, struct zs_pool,
> > shrinker);
> >
> > - if (!pool->shrinker_enabled)
> > - return 0;
> > -
> > for (i = zs_size_classes - 1; i >= 0; i--) {
> > class = pool->size_class[i];
> > if (!class)
> > --
> > 2.6.1.134.g4b1fd35
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the slave-dma tree
Hi Vinod, On Thu, 15 Oct 2015 03:35:42 + "Koul, Vinod" wrote: > > So should I ask Linus to apply this fix once merge window opens or you will > send > this, how do we go about fixing this one :) > > Or should I merge the above commit from asm-generic tree? Up to you. Though you should only merge fro mthe asm-generic tree if the maintainer guarantees it will not be rebased. You could just wait and tell Linus that this fixup is needed when the two trees are merged. It really need to go into the merge commit to avoid bisection problems. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: at91/pm: move enter sleep code to a procedure
To make the code more legible and to prepare for the ULP1 support in the future, move the Master clock, PLLA, MOR handling code and the sleep code to a separate procedure. Signed-off-by: Wenyou Yang --- arch/arm/mach-at91/pm_suspend.S | 132 --- 1 file changed, 68 insertions(+), 64 deletions(-) diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S index 0d95f48..825347b 100644 --- a/arch/arm/mach-at91/pm_suspend.S +++ b/arch/arm/mach-at91/pm_suspend.S @@ -105,77 +105,19 @@ ENTRY(at91_pm_suspend_in_sram) ldr r0, .pm_mode tst r0, #AT91_PM_SLOW_CLOCK - beq skip_disable_main_clock + beq standby_mode - ldr pmc, .pmc_base - - /* Save Master clock setting */ - ldr tmp1, [pmc, #AT91_PMC_MCKR] - str tmp1, .saved_mckr +ulp0_mode: + bl at91_pm_ulp0_mode + b pm_exit - /* -* Set the Master clock source to slow clock -*/ - bic tmp1, tmp1, #AT91_PMC_CSS - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy - - /* Save PLLA setting and disable it */ - ldr tmp1, [pmc, #AT91_CKGR_PLLAR] - str tmp1, .saved_pllar - - mov tmp1, #AT91_PMC_PLLCOUNT - orr tmp1, tmp1, #(1 << 29) /* bit 29 always set */ - str tmp1, [pmc, #AT91_CKGR_PLLAR] - - /* Turn off the main oscillator */ - ldr tmp1, [pmc, #AT91_CKGR_MOR] - bic tmp1, tmp1, #AT91_PMC_MOSCEN - orr tmp1, tmp1, #AT91_PMC_KEY - str tmp1, [pmc, #AT91_CKGR_MOR] - -skip_disable_main_clock: +standby_mode: ldr pmc, .pmc_base /* Wait for interrupt */ at91_cpu_idle - ldr r0, .pm_mode - tst r0, #AT91_PM_SLOW_CLOCK - beq skip_enable_main_clock - - ldr pmc, .pmc_base - - /* Turn on the main oscillator */ - ldr tmp1, [pmc, #AT91_CKGR_MOR] - orr tmp1, tmp1, #AT91_PMC_MOSCEN - orr tmp1, tmp1, #AT91_PMC_KEY - str tmp1, [pmc, #AT91_CKGR_MOR] - - wait_moscrdy - - /* Restore PLLA setting */ - ldr tmp1, .saved_pllar - str tmp1, [pmc, #AT91_CKGR_PLLAR] - - tst tmp1, #(AT91_PMC_MUL & 0xff) - bne 3f - tst tmp1, #(AT91_PMC_MUL & ~0xff) - beq 4f -3: - wait_pllalock -4: - - /* -* Restore master clock setting -*/ - ldr tmp1, .saved_mckr - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy - -skip_enable_main_clock: +pm_exit: /* Exit the self-refresh mode */ mov r0, #SRAMC_SELF_FRESH_EXIT bl at91_sramc_self_refresh @@ -309,6 +251,68 @@ exit_sramc_sf: mov pc, lr ENDPROC(at91_sramc_self_refresh) +/* + * void at91_pm_ulp0_mode(void) + */ +ENTRY(at91_pm_ulp0_mode) + ldr pmc, .pmc_base + + /* Save PMC_MCKR config */ + ldr tmp1, [pmc, #AT91_PMC_MCKR] + str tmp1, .saved_mckr + + /* Switch master clock source to slow clock */ + bic tmp1, tmp1, #AT91_PMC_CSS + str tmp1, [pmc, #AT91_PMC_MCKR] + + wait_mckrdy + + /* Save PLLA config, then and disable PLLA */ + ldr tmp1, [pmc, #AT91_CKGR_PLLAR] + str tmp1, .saved_pllar + + mov tmp1, #AT91_PMC_PLLCOUNT + orr tmp1, tmp1, #(1 << 29) + str tmp1, [pmc, #AT91_CKGR_PLLAR] + + /* Turn off the main oscillator */ + ldr tmp1, [pmc, #AT91_CKGR_MOR] + bic tmp1, tmp1, #AT91_PMC_MOSCEN + orr tmp1, tmp1, #AT91_PMC_KEY + str tmp1, [pmc, #AT91_CKGR_MOR] + + /* Wait for interrupt */ + at91_cpu_idle + + /* Turn on the main oscillator */ + ldr tmp1, [pmc, #AT91_CKGR_MOR] + orr tmp1, tmp1, #AT91_PMC_MOSCEN + orr tmp1, tmp1, #AT91_PMC_KEY + str tmp1, [pmc, #AT91_CKGR_MOR] + + wait_moscrdy + + /* Restore PLLA config */ + ldr tmp1, .saved_pllar + str tmp1, [pmc, #AT91_CKGR_PLLAR] + + tst tmp1, #(AT91_PMC_MUL & 0xff) + bne 1f + tst tmp1, #(AT91_PMC_MUL & ~0xff) + beq 2f +1: + wait_pllalock +2: + + /* Restore PMC_MCKR config */ + ldr tmp1, .saved_mckr + str tmp1, [pmc, #AT91_PMC_MCKR] + + wait_mckrdy + + mov pc, lr +ENDPROC(at91_pm_ulp0_mode) + .pmc_base: .word 0 .sramc_base: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ARM: at91/pm: add ULP1 support
This patch series is to add the ultra Low-power mode 1(ULP1) mode support. The ULP1 mode is introduced by SAMA5D2. In ULP1 mode, the system can achieve the lowest power consumption, and it can be woken up more quickly, about 30uS. Wenyou Yang (2): ARM: at91/pm: move enter sleep code to a procedure ARM: at91/pm: add ultra Low-power mode 1(ULP1) support arch/arm/mach-at91/pm.c | 29 + arch/arm/mach-at91/pm.h |7 ++ arch/arm/mach-at91/pm_suspend.S | 239 +-- include/linux/clk/at91_pmc.h| 36 ++ 4 files changed, 249 insertions(+), 62 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[4]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> Donald, Shane, > Thanks for reporting this. Sure! Thanks for looking into it. > You have similar hardware: > > Shane: > > smpboot: CPU0: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (fam: 06, > model: 0f, stepping: 06) > > Donald: > > CPU : Intel Core 2 CPU 6600 @ 2.4GHz > > I think I can get ahold of a core2 6xxx box tomorrow. Maybe the mobo/bios? We both have the same Asus P5B as well. Donald said he has the deluxe version while I have the plain version. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: at91/pm: add ultra Low-power mode 1(ULP1) support
The Ultra Low-power mode 1(ULP1) is introduced by SAMA5D2.
In the ULP1 mode, all the clocks are shut off, inclusive the embedded
12MHz RC oscillator, so as to achieve the lowest power consumption
with the system in retention mode and able to resume on the wake up
events. As soon as the wake up event is asserted, the embedded 12MHz
RC oscillator restarts automatically.
The number of wake up sources for the ULP1 mode is limited, the wake
up sources should be configured via the PMC_FSMR and PMC_FSPR
registers.
In this patch, the following wake up sources are enabled,
- WKUP0 pin
- WKUP1 pin to WKUP8 pin (shared with PIOBU0 to PIOBU7)
- RTC alarm
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/pm.c | 29 ++
arch/arm/mach-at91/pm.h |7 +++
arch/arm/mach-at91/pm_suspend.S | 111 +++
include/linux/clk/at91_pmc.h| 36 +
4 files changed, 183 insertions(+)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 80e277c..49443d9 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -35,6 +35,11 @@
#include "generic.h"
#include "pm.h"
+#define ULP0_MODE 0x00
+#define ULP1_MODE 0x11
+
+#define SAMA5D2_PMC_VERSION0x20540
+
/*
* FIXME: this is needed to communicate between the pinctrl driver and
* the PM implementation in the machine. Possibly part of the PM
@@ -64,6 +69,23 @@ static int at91_pm_valid_state(suspend_state_t state)
}
}
+static void at91_config_ulp1_wkup_source(void)
+{
+ if (at91_pmc_read(AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION) {
+ at91_pmc_write(AT91_PMC_FSMR, AT91_PMC_RTCAL |
+ AT91_PMC_FSTT9 |
+ AT91_PMC_FSTT8 |
+ AT91_PMC_FSTT7 |
+ AT91_PMC_FSTT6 |
+ AT91_PMC_FSTT5 |
+ AT91_PMC_FSTT4 |
+ AT91_PMC_FSTT3 |
+ AT91_PMC_FSTT2 |
+ AT91_PMC_FSTT0);
+
+ at91_pmc_write(AT91_PMC_FSPR, 0);
+ }
+}
static suspend_state_t target_state;
@@ -73,6 +95,9 @@ static suspend_state_t target_state;
static int at91_pm_begin(suspend_state_t state)
{
target_state = state;
+
+ at91_config_ulp1_wkup_source();
+
return 0;
}
@@ -140,6 +165,10 @@ static void at91_pm_suspend(suspend_state_t state)
pm_data |= (state == PM_SUSPEND_MEM) ?
AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
+ pm_data |= ((state == PM_SUSPEND_MEM) &&
+ (at91_pmc_read(AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)) ?
+ AT91_PM_ULP(AT91_PM_ULP1_MODE) : 0;
+
flush_cache_all();
outer_disable();
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 3fcf881..2e76745 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -39,4 +39,11 @@ extern void __iomem *at91_ramc_base[];
#defineAT91_PM_SLOW_CLOCK 0x01
+#define AT91_PM_ULP_OFFSET 5
+#define AT91_PM_ULP_MASK 0x03
+#define AT91_PM_ULP(x) (((x) & AT91_PM_ULP_MASK) << AT91_PM_ULP_OFFSET)
+
+#define AT91_PM_ULP0_MODE 0x00
+#define AT91_PM_ULP1_MODE 0x01
+
#endif
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 825347b..543c430 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -41,6 +41,15 @@ tmp2 .reqr5
.endm
/*
+ * Wait for main oscillator selection is done
+ */
+ .macro wait_moscsels
+1: ldr tmp1, [pmc, #AT91_PMC_SR]
+ tst tmp1, #AT91_PMC_MOSCSELS
+ beq 1b
+ .endm
+
+/*
* Wait until PLLA has locked.
*/
.macro wait_pllalock
@@ -99,6 +108,10 @@ ENTRY(at91_pm_suspend_in_sram)
and r0, r0, #AT91_PM_MODE_MASK
str r0, .pm_mode
+ lsr r0, r3, #AT91_PM_ULP_OFFSET
+ and r0, r0, #AT91_PM_ULP_MASK
+ str r0, .ulp_mode
+
/* Active the self-refresh mode */
mov r0, #SRAMC_SELF_FRESH_ACTIVE
bl at91_sramc_self_refresh
@@ -107,6 +120,14 @@ ENTRY(at91_pm_suspend_in_sram)
tst r0, #AT91_PM_SLOW_CLOCK
beq standby_mode
+ ldr r0, .ulp_mode
+ tst r0, #AT91_PM_ULP1_MODE
+ beq ulp0_mode
+
+ulp1_mode:
+ bl at91_pm_ulp1_mode
+ b pm_exit
+
ulp0_mode:
bl at91_pm_ulp0_mode
b pm_exit
@@ -313,6 +334,94 @@ ENTRY(at91_pm_ulp0_mode)
mov pc, lr
ENDPROC(at91_pm_ulp0_mode)
+/*
+ * void at91_pm_ulp1_mode(void)
+ *
+ */
+ENTRY(at91_pm_ulp1_mode)
+ ldr pmc, .pmc_base
+
+ /* Save PMC_MCKR config */
+ ldr tmp1,
Re: linux-next: build failure after merge of the mfd tree
Hi Stephen, [auto build test ERROR on next-20151013 -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Stephen-Rothwell/linux-next-build-failure-after-merge-of-the-mfd-tree/20151015-102814 config: i386-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/mfd/intel-lpss.c:28:41: fatal error: linux/io-64-nonatomic-lo-hi.h: >> No such file or directory compilation terminated. vim +28 drivers/mfd/intel-lpss.c 22 #include 23 #include 24 #include 25 #include 26 #include 27 #include > 28 #include 29 30 #include "intel-lpss.h" 31 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: linux-next: build failure after merge of the slave-dma tree
On Thu, 2015-10-15 at 11:51 +1100, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/dma/idma64.h:19:47: fatal error: asm-generic/io-64-nonatomic-lo-hi.h:
> No
> such file or directory
> #include
>^
>
> Caused by commit
>
> 97c37accd38f ("dmaengine: idma64: use lo_hi_readq() / lo_hi_writeq()")
>
> interacting with commit
>
> f626fe17485b ("move io-64-nonatomic*.h out of asm-generic")
>
> from the asm-generic tree.
>
> I have applied the folling merge fix patch and can carry it as necessary.
Thanks Stephen, This looks fine to me.
So should I ask Linus to apply this fix once merge window opens or you will send
this, how do we go about fixing this one :)
Or should I merge the above commit from asm-generic tree?
--
~Vinod
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Thu, Oct 15, 2015 at 11:11:01AM +0800, Boqun Feng wrote: > Hi Paul, > > On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote: > > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote: > [snip] > > > To that end, the herd tool can make a diagram of what it thought > > > happened, and I have attached it. I used this diagram to try and force > > > this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC, > > > and succeeded. Here is the sequence of events: > > > > > > o Commit P0's write. The model offers to propagate this write > > > to the coherence point and to P1, but don't do so yet. > > > > > > o Commit P1's write. Similar offers, but don't take them up yet. > > > > > > o Commit P0's lwsync. > > > > > > o Execute P0's lwarx, which reads a=0. Then commit it. > > > > > > o Commit P0's stwcx. as successful. This stores a=1. > > > > > > o Commit P0's branch (not taken). > > > > > > > So at this point, P0's write to 'a' has propagated to P1, right? But > > P0's write to 'x' hasn't, even there is a lwsync between them, right? > > Doesn't the lwsync prevent this from happening? > > > > If at this point P0's write to 'a' hasn't propagated then when? > > Hmm.. I played around ppcmem, and figured out what happens to > propagation of P0's write to 'a': > > At this point, or some point after store 'a' to 1 and before sync on > P1 finish, writes to 'a' reachs a coherence point which 'a' is 2, so > P0's write to 'a' "fails" and will not propagate. > > I probably misunderstood the word "propagate", which actually means an > already coherent write gets seen by another CPU, right? It is quite possible for a given write to take a position in the coherence order that guarantees that no one will see it, as is the case here. But yes, all readers will see an order of values for a given memory location that is consistent with the coherence order. > So my question should be: > > As lwsync can order P0's write to 'a' happens after P0's write to 'x', > why P0's write to 'x' isn't seen by P1 after P1's write to 'a' overrides > P0's? There is no global clock for PPC's memory model. > But ppcmem gave me the answer ;-) lwsync won't wait under P0's write to > 'x' gets propagated, and if P0's write to 'a' "wins" in write coherence, > lwsync will guarantee propagation of 'x' happens before that of 'a', but > if P0's write to 'a' "fails", there will be no propagation of 'a' from > P0. So that lwsync can't do anything here. I believe that this is consistent, but the corners can get tricky. Thanx, Paul > Regards, > Boqun > > > > > > o Commit P0's final register-to-register move. > > > > > > o Commit P1's sync instruction. > > > > > > o There is now nothing that can happen in either processor. > > > P0 is done, and P1 is waiting for its sync. Therefore, > > > propagate P1's a=2 write to the coherence point and to > > > the other thread. > > > > > > o There is still nothing that can happen in either processor. > > > So pick the barrier propagate, then the acknowledge sync. > > > > > > o P1 can now execute its read from x. Because P0's write to > > > x is still waiting to propagate to P1, this still reads > > > x=0. Execute and commit, and we now have both r3 registers > > > equal to zero and the final value a=2. > > > > > > o Clean up by propagating the write to x everywhere, and > > > propagating the lwsync. > > > > > > And the "exists" clause really does trigger: 0:r3=0; 1:r3=0; [a]=2; > > > > > > I am still not 100% confident of my litmus test. It is quite possible > > > that I lost something in translation, but that is looking less likely. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] block: flush queued bios when the process blocks
On Sat, Oct 10, 2015 at 3:52 AM, Mike Snitzer wrote: > On Thu, Oct 08 2015 at 11:08am -0400, > Mike Snitzer wrote: > >> On Thu, Oct 08 2015 at 11:04am -0400, >> Mikulas Patocka wrote: >> >> > >> > >> > On Tue, 6 Oct 2015, Mike Snitzer wrote: >> > >> > > To give others context for why I'm caring about this issue again, this >> > > recent BZ against 4.3-rc served as a reminder that we _need_ a fix: >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1267650 >> > > >> > > FYI, I cleaned up the plug-based approach a bit further, here is the >> > > incremental patch: >> > > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip=f73d001ec692125308accbb5ca26f892f949c1b6 >> > > >> > > And here is a new version of the overall combined patch (sharing now >> > > before I transition to looking at alternatives, though my gut is the use >> > > of a plug in generic_make_request really wouldn't hurt us.. famous last >> > > words): >> > > >> > > block/bio.c| 82 >> > > +- >> > > block/blk-core.c | 21 - >> > > drivers/md/dm-bufio.c | 2 +- >> > > drivers/md/raid1.c | 6 ++-- >> > > drivers/md/raid10.c| 6 ++-- >> > > include/linux/blkdev.h | 11 +-- >> > > include/linux/sched.h | 4 --- >> > > 7 files changed, 51 insertions(+), 81 deletions(-) >> > > >> ... >> > > diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c >> > > index 2dd3308..c2bff16 100644 >> > > --- a/drivers/md/dm-bufio.c >> > > +++ b/drivers/md/dm-bufio.c >> > > @@ -168,7 +168,7 @@ static inline int dm_bufio_cache_index(struct >> > > dm_bufio_client *c) >> > > #define DM_BUFIO_CACHE(c) >> > > (dm_bufio_caches[dm_bufio_cache_index(c)]) >> > > #define DM_BUFIO_CACHE_NAME(c) >> > > (dm_bufio_cache_names[dm_bufio_cache_index(c)]) >> > > >> > > -#define dm_bufio_in_request()(!!current->bio_list) >> > > +#define dm_bufio_in_request()(current->plug && >> > > !!current->plug->bio_list) >> > >> > This condition is repeated several times throughout the whole patch - so >> > maybe you should make it a function in block device header file. >> >> Yeah, I thought of that too but forgot to come back to it. Will do, >> thanks. >> >> FYI, I found another bug in my last patch and fixed it up. I'll get >> some refactoring done (including your suggestion), actually _test_ the >> code (e.g. verify all of lvm testsuite passes) and then send out v3. > > Turns out that this change: > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip=2639638c77768a86216be456c2764e32a2bcd841 > > needed to be reverted with: > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip=ad3ccd760da7c05b90775372f9b39dc2964086fe > > Because nested plugs caused generic_make_request()'s onstack bio_list to > go out of scope (blk_finish_plug() wouldn't actually flush the list > within generic_make_request because XFS already added an outermost > plug). Looks you should have defined bio_list in plug as 'struct bio_list bio_list' instead of one pointer. > > But even after fixing that I then hit issues with these changes now > resulting in imperfect 'in_generic_make_request' accounting that happens > lazily once the outermost plug completes blk_finish_plug. manifested as > dm-bufio.c:dm_bufio_prefetch's BUG_ON(dm_bufio_in_request()); hitting. Looks this problem should be related with above 'bio_list' definition too. > > Basically using the blk-core's onstack plugging isn't workable for > fixing this deadlock and we're back to having to seriously consider > this (with its additional hook in the scheduler): > > Mike > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, 1/2] scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target
On Wed, 2015-10-14 at 09:54 -0700, Olof Johansson wrote: > On Tue, Oct 13, 2015 at 4:43 PM, Michael Ellerman wrote: > > On Tue, 2015-10-13 at 14:02 -0700, Olof Johansson wrote: > >> On Fri, Oct 2, 2015 at 12:47 AM, Michael Ellerman > >> wrote: > >> > On Wed, 2015-23-09 at 05:40:34 UTC, Michael Ellerman wrote: > >> >> Arch Makefiles can set KBUILD_DEFCONFIG to tell kbuild the name of the > >> >> defconfig that should be built by default. > >> >> > >> >> However currently there is an assumption that KBUILD_DEFCONFIG points to > >> >> a file at arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG). > >> >> > >> >> We would like to use a target, using merge_config, as our defconfig, so > >> >> adapt the logic in scripts/kconfig/Makefile to allow that. > >> >> > >> >> To minimise the chance of breaking anything, we first check if > >> >> KBUILD_DEFCONFIG is a file, and if so we do the old logic. If it's not a > >> >> file, then we call the top-level Makefile with KBUILD_DEFCONFIG as the > >> >> target. > >> >> > >> >> Signed-off-by: Michael Ellerman > >> >> Acked-by: Michal Marek > >> > > >> > Applied to powerpc next. > >> > > >> > https://git.kernel.org/powerpc/c/d2036f30cfe1daa19e63ce75 > >> > >> This breaks arm64 defconfig for me: > >> > >> mkdir obj-tmp > >> make -f Makefile O=obj-tmp ARCH=arm64 defconfig > >> ... watch loop of: > >> *** Default configuration is based on target 'defconfig' > >> GEN ./Makefile > > > > Crap, sorry. I knew I shouldn't have touched that code! > > > > Does this fix it for you? > > Yes, it does, however: > > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > > index b2b9c87..3043d6b 100644 > > --- a/scripts/kconfig/Makefile > > +++ b/scripts/kconfig/Makefile > > @@ -96,7 +96,7 @@ savedefconfig: $(obj)/conf > > defconfig: $(obj)/conf > > ifeq ($(KBUILD_DEFCONFIG),) > > $< $(silent) --defconfig $(Kconfig) > > -else ifneq ($(wildcard arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) > > +else ifneq ($(wildcard > > $(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) > > @$(kecho) "*** Default configuration is based on > > '$(KBUILD_DEFCONFIG)'" > > $(Q)$< $(silent) > > --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig) > > Do you need a $(srctree) prefix here too? I'm not entirely sure what I > would do to reproduce a run that goes down this path so I can't > confirm. That is the path you're going down, now that it's fixed. That's the path where KBUILD_DEFCONFIG is a real file, ie. the old behaviour. I'm not sure why it doesn't have a $(srctree) there, but it's never had one. It looks like it eventually boils down to zconf_fopen() which looks for the file in both . and $(srctree). So I think we could add a $(srctree) there, it would be more obvious and not rely on the zconf_fopen() behaviour, but I'd rather leave it as is and let Michal do that as a cleanup later. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16.y-ckt 053/133] ARM: orion5x: fix legacy orion5x IRQ numbers
On Wed, 2015-09-30 at 10:50 +0100, Luis Henriques wrote: > 3.16.7-ckt18 -stable review patch. If anyone has any objections, please let > me know. > > -- > > From: Benjamin Cama > > commit 5be9fc23cdb42e1d383ecc8eae8a8ff70a752708 upstream. > > Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x. [...] But I don't think this was needed for 3.16-ckt, was it? Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, reading IRC for the first time signature.asc Description: This is a digitally signed message part
Re: [PATCH] selftests: memfd_test: Revised STACK_SIZE to make it 16-byte aligned
Hello Shuah, Can this patch be allowed to merge into next realse? Thanks, Chunyan On Thu, Oct 1, 2015 at 3:33 PM, Chunyan Zhang wrote: > There is a mandate of 16-byte aligned stack on AArch64 [1], so the > STACK_SIZE here should also be 16-byte aligned, otherwise we would > get an error when calling clone(). > > [1] http://lxr.free-electrons.com/source/arch/arm64/kernel/process.c#L265 > > Signed-off-by: Chunyan Zhang > --- > tools/testing/selftests/memfd/memfd_test.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/memfd/memfd_test.c > b/tools/testing/selftests/memfd/memfd_test.c > index 0b9eafb..aa5d3eb 100644 > --- a/tools/testing/selftests/memfd/memfd_test.c > +++ b/tools/testing/selftests/memfd/memfd_test.c > @@ -18,7 +18,7 @@ > #include > > #define MFD_DEF_SIZE 8192 > -#define STACK_SIZE 65535 > +#define STACK_SIZE 65536 > > static int sys_memfd_create(const char *name, > unsigned int flags) > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1
Hi Yiwei,
[auto build test ERROR on rockchip/for-next -- if it's inappropriate base,
please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Shawn-Lin/Fix-broken-DMAFLUSHP-on-Rockchips-platform/20151015-094613
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
sound/soc/rockchip/rockchip_i2s.c:467:13: sparse: undefined identifier
'snd_dmaengine_pcm_get_caps'
sound/soc/rockchip/rockchip_i2s.c:468:29: sparse: expected structure or union
sound/soc/rockchip/rockchip_i2s.c: In function 'rockchip_i2s_probe':
>> sound/soc/rockchip/rockchip_i2s.c:467:6: error: implicit declaration of
>> function 'snd_dmaengine_pcm_get_caps' [-Werror=implicit-function-declaration]
if (snd_dmaengine_pcm_get_caps(>dev, _caps) == 0) {
^
>> sound/soc/rockchip/rockchip_i2s.c:468:15: error: request for member
>> 'max_burst' in something not a structure or union
if (dma_caps.max_burst > 4) {
^
cc1: some warnings being treated as errors
vim +/snd_dmaengine_pcm_get_caps +467 sound/soc/rockchip/rockchip_i2s.c
461 i2s->playback_dma_data.addr = res->start + I2S_TXDR;
462 i2s->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
463
464 i2s->capture_dma_data.addr = res->start + I2S_RXDR;
465 i2s->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
466
> 467 if (snd_dmaengine_pcm_get_caps(>dev, _caps) == 0) {
> 468 if (dma_caps.max_burst > 4) {
469 i2s->playback_dma_data.maxburst = 4;
470 i2s->capture_dma_data.maxburst = 4;
471 } else {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs
+CCing kishon Vijay,
On 10/14/2015 06:25 PM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/Kconfig | 12 +
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufs-exynos-hw.c | 131
drivers/scsi/ufs/ufs-exynos-hw.h | 43 ++
drivers/scsi/ufs/ufs-exynos.c| 1317 ++
drivers/scsi/ufs/ufs-exynos.h| 247 +++
drivers/scsi/ufs/ufshci.h| 26 +-
drivers/scsi/ufs/unipro.h| 47 ++
8 files changed, 1823 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
create mode 100644 drivers/scsi/ufs/ufs-exynos.c
create mode 100644 drivers/scsi/ufs/ufs-exynos.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f4530744e0a..bc602be94458 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
Select this if you have UFS controller on QCOM chipset.
If unsure, say N.
+
+config SCSI_UFS_EXYNOS
+ bool "EXYNOS specific hooks to UFS controller platform driver"
+ depends on SCSI_UFSHCD_PLATFORM && ARCH_EXYNOS || COMPILE_TEST
+ select PHY_EXYNOS_UFS
+ help
+ This selects the EXYNOS specific additions to UFSHCD platform driver.
+ UFS host on EXYNOS includes HCI and UNIPRO layer, and associates with
+ UFS-PHY driver.
+
+ Select this if you have UFS host controller on EXYNOS chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcce7a23..2accf1e628b3 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,5 +1,6 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o ufs-exynos-hw.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c b/drivers/scsi/ufs/ufs-exynos-hw.c
new file mode 100644
index ..be6c61541a8f
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.c
@@ -0,0 +1,131 @@
+/*
+ * UFS Host Controller driver for Exynos specific extensions
+ *
+ * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "ufshcd.h"
+#include "unipro.h"
+
+#include "ufs-exynos.h"
+#include "ufs-exynos-hw.h"
+
+static int exynos7_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs)
+{
+ struct clk *child, *parent;
+
+ child = devm_clk_get(dev, "ref_clk");
+ if (IS_ERR(child)) {
+ dev_err(dev, "failed to get ref_clk clock\n");
+ return -EINVAL;
+ }
+
+ parent = devm_clk_get(dev, "ref_clk_parent");
+ if (IS_ERR(parent)) {
+ dev_err(dev, "failed to get ref_clk_parent clock\n");
+ return -EINVAL;
+ }
+ return clk_set_parent(child, parent);
+}
+
+static int exynos7_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ u32 val = ufs->drv_data->uic_attr->pa_dbg_option_suite;
+ int i;
+
+ exynos_ufs_enable_ov_tm(hba);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x297, i), 0x17);
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x362, i), 0xff);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x363, i), 0x00);
+ }
+ exynos_ufs_disable_ov_tm(hba);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba,
+ UIC_ARG_MIB_SEL(TX_HIBERN8_CONTROL, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_TXPHY_CFGUPDT), 0x1);
+ udelay(1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val | (1 << 12));
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_RESET_PHY), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_LINE_RESET), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_LINE_RESET_REQ), 0x1);
+ udelay(1600);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val);
+
+ return 0;
+}
+
+static int exynos7_ufs_post_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ int i;
+
+
Re: [PATCH net-next 0/4] net: dsa: mv88e6xxx: fix hardware bridging
On 10/14/2015 07:52 PM, Andrew Lunn wrote: On Wed, Oct 14, 2015 at 09:28:55PM -0400, Vivien Didelot wrote: On Oct. Thursday 15 (42) 12:46 AM, Andrew Lunn wrote: On Sun, Oct 11, 2015 at 06:08:34PM -0400, Vivien Didelot wrote: DSA and its drivers currently hook the NETDEV_CHANGEUPPER net_device event in order to configure the VLAN map of every port. This VLAN map is a feature of these switch chips to hardcode and restrict which output ports a given input port can egress frames to. A Linux bridge is a simple untagged VLAN propagated by the bridge code itself. With a proper 802.1Q support, a driver does not need this hook anymore, and will simply program the related VLAN object. This patchset improves the hardware bridging code in the mv88e6xxx driver with a strict 802.1Q mode. Hi Vivien I just tested this as part of net-next/master, and found a problem If i do: ip link set lan0 up ip addr add 192.168.10.2/24 dev lan0 It will not ping. Looking in sys/kernel/debug/dsa0/stats i see broadcast packets, probably ARP, being received at the port. But they are not being forwarded out the CPU port. If however i do brctl addbr br0 brctl addif br0 lan0 ip addr add 192.168.10.2/24 dev br0 ip link set br0 up i can ping. So it looks like we are too restrictive by default. You should be able to use interfaces as they are, without a bridge. Correct, if the ports are not in a VLAN by default, they cannot talk. Hi Vivien This is a regression. Ports of the switch should work like normal Linux interfaces. And up until now, they did. This patchset changed that. As Florian pointed out, these interfaces are separated from each other. So you need something like a bridge per port by default, which then gets removed and replaced when a port is added to a Linux bridge. We also need to take care of VLANs. When the port is not a member of a linux bridge, i expect all VLAN tagged frames to be received, as well as untagged frames. This is normal Linux behaviour. But i never got around to testing this with DSA. There was a reason for the original code. I had wondered how it is now supposed to work. Guess this exchange explains it. Looking forward to see how it is going to be fixed, and too bad I don't have time to be more involved. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
Hi Paul, On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote: > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote: [snip] > > To that end, the herd tool can make a diagram of what it thought > > happened, and I have attached it. I used this diagram to try and force > > this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC, > > and succeeded. Here is the sequence of events: > > > > o Commit P0's write. The model offers to propagate this write > > to the coherence point and to P1, but don't do so yet. > > > > o Commit P1's write. Similar offers, but don't take them up yet. > > > > o Commit P0's lwsync. > > > > o Execute P0's lwarx, which reads a=0. Then commit it. > > > > o Commit P0's stwcx. as successful. This stores a=1. > > > > o Commit P0's branch (not taken). > > > > So at this point, P0's write to 'a' has propagated to P1, right? But > P0's write to 'x' hasn't, even there is a lwsync between them, right? > Doesn't the lwsync prevent this from happening? > > If at this point P0's write to 'a' hasn't propagated then when? > Hmm.. I played around ppcmem, and figured out what happens to propagation of P0's write to 'a': At this point, or some point after store 'a' to 1 and before sync on P1 finish, writes to 'a' reachs a coherence point which 'a' is 2, so P0's write to 'a' "fails" and will not propagate. I probably misunderstood the word "propagate", which actually means an already coherent write gets seen by another CPU, right? So my question should be: As lwsync can order P0's write to 'a' happens after P0's write to 'x', why P0's write to 'x' isn't seen by P1 after P1's write to 'a' overrides P0's? But ppcmem gave me the answer ;-) lwsync won't wait under P0's write to 'x' gets propagated, and if P0's write to 'a' "wins" in write coherence, lwsync will guarantee propagation of 'x' happens before that of 'a', but if P0's write to 'a' "fails", there will be no propagation of 'a' from P0. So that lwsync can't do anything here. Regards, Boqun > > > o Commit P0's final register-to-register move. > > > > o Commit P1's sync instruction. > > > > o There is now nothing that can happen in either processor. > > P0 is done, and P1 is waiting for its sync. Therefore, > > propagate P1's a=2 write to the coherence point and to > > the other thread. > > > > o There is still nothing that can happen in either processor. > > So pick the barrier propagate, then the acknowledge sync. > > > > o P1 can now execute its read from x. Because P0's write to > > x is still waiting to propagate to P1, this still reads > > x=0. Execute and commit, and we now have both r3 registers > > equal to zero and the final value a=2. > > > > o Clean up by propagating the write to x everywhere, and > > propagating the lwsync. > > > > And the "exists" clause really does trigger: 0:r3=0; 1:r3=0; [a]=2; > > > > I am still not 100% confident of my litmus test. It is quite possible > > that I lost something in translation, but that is looking less likely. > > signature.asc Description: PGP signature
Re: [alsa-devel] [PATCH v6 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_caps interface
Hi Shawn,
[auto build test WARNING on rockchip/for-next -- if it's inappropriate base,
please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Shawn-Lin/Fix-broken-DMAFLUSHP-on-Rockchips-platform/20151015-094613
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
>> sound/soc/soc-generic-dmaengine-pcm.c:475: warning: No description found for
>> parameter 'caps'
vim +/caps +475 sound/soc/soc-generic-dmaengine-pcm.c
459 return;
460
461 pcm = soc_platform_to_pcm(platform);
462
463 snd_soc_remove_platform(platform);
464 dmaengine_pcm_release_chan(pcm);
465 kfree(pcm);
466 }
467 EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_unregister);
468
469
470 /**
471 * snd_dmaengine_pcm_get_caps - Get slave dma caps based PCM device
472 * @dev: Parent device the PCM was register with
473 */
474 int snd_dmaengine_pcm_get_caps(struct device *dev, struct
dma_slave_caps *caps)
> 475 {
476 struct snd_soc_platform *platform;
477 struct dmaengine_pcm *pcm;
478 int ret = -ENODEV;
479
480 platform = snd_soc_lookup_platform(dev);
481 if (!platform)
482 return ret;
483
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Thu, Oct 15, 2015 at 09:22:26AM +0800, Boqun Feng wrote:
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > > > Suppose we have something like the following, where "a" and "x" are
> > > > > both
> > > > > initially zero:
> > > > >
> > > > > CPU 0 CPU 1
> > > > > - -
> > > > >
> > > > > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > > > > r3 = xchg(, 1); smp_mb();
> > > > > r3 = READ_ONCE(x);
> > > > >
> > > > > If xchg() is fully ordered, we should never observe both CPUs'
> > > > > r3 values being zero, correct?
> > > > >
> > > > > And wouldn't this be represented by the following litmus test?
> > > > >
> > > > > PPC SB+lwsync-RMW2-lwsync+st-sync-leading
> > > > > ""
> > > > > {
> > > > > 0:r1=1; 0:r2=x; 0:r3=3; 0:r10=0 ; 0:r11=0; 0:r12=a;
> > > > > 1:r1=2; 1:r2=x; 1:r3=3; 1:r10=0 ; 1:r11=0; 1:r12=a;
> > > > > }
> > > > >P0 | P1 ;
> > > > >stw r1,0(r2) | stw r1,0(r12) ;
> > > > >lwsync | sync ;
> > > > >lwarx r11,r10,r12 | lwz r3,0(r2) ;
> > > > >stwcx. r1,r10,r12 | ;
> > > > >bne Fail0 | ;
> > > > >mr r3,r11 | ;
> > > > >Fail0: | ;
> > > > > exists
> > > > > (0:r3=0 /\ a=2 /\ 1:r3=0)
> > > > >
> > > > > I left off P0's trailing sync because there is nothing for it to order
> > > > > against in this particular litmus test. I tried adding it and
> > > > > verified
> > > > > that it has no effect.
> > > > >
> > > > > Am I missing something here? If not, it seems to me that you need
> > > > > the leading lwsync to instead be a sync.
> >
> > I'm afraid more than that, the above litmus also shows that
>
> I mean there will be more things we need to fix, perhaps even smp_wmb()
> need to be sync then..
That should not be necessary. For smp_wmb(), lwsync should be just fine.
Thanx, Paul
> Regards,
> Boqun
>
> > CPU 0 CPU 1
> > - -
> >
> > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > r3 = xchg_release(, 1); smp_mb();
> > r3 = READ_ONCE(x);
> >
> > (0:r3 == 0 && 1:r3 == 0 && a == 2) is not prohibitted
> >
> > in the implementation of this patchset, which should be disallowed by
> > the semantics of RELEASE, right?
> >
> > And even:
> >
> > CPU 0 CPU 1
> > - -
> >
> > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > smp_store_release(, 1); smp_mb();
> > r3 = READ_ONCE(x);
> >
> > (1:r3 == 0 && a == 2) is not prohibitted
> >
> > shows by:
> >
> > PPC weird-lwsync
> > ""
> > {
> > 0:r1=1; 0:r2=x; 0:r3=3; 0:r12=a;
> > 1:r1=2; 1:r2=x; 1:r3=3; 1:r12=a;
> > }
> > P0 | P1 ;
> > stw r1,0(r2) | stw r1,0(r12) ;
> > lwsync | sync ;
> > stw r1,0(r12) | lwz r3,0(r2) ;
> > exists
> > (a=2 /\ 1:r3=0)
> >
> >
> > Please find something I'm (or the tool is) missing, maybe we can't use
> > (a == 2) as a indication that STORE on CPU 1 happens after STORE on CPU
> > 0?
> >
> > And there is really something I find strange, see below.
> >
> > > >
> > > > So the scenario that would fail would be this one, right?
> > > >
> > > > a = x = 0
> > > >
> > > > CPU0CPU1
> > > >
> > > > r3 = load_locked ();
> > > > a = 2;
> > > > sync();
> > > > r3 = x;
> > > > x = 1;
> > > > lwsync();
> > > > if (!store_cond(, 1))
> > > > goto again
> > > >
> > > >
> > > > Where we hoist the load way up because lwsync allows this.
> > >
> > > That scenario would end up with a==1 rather than a==2.
> > >
> > > > I always thought this would fail because CPU1's store to @a would fail
> > > > the store_cond() on CPU0 and we'd do the 'again' thing, re-issuing the
> > > > load and now seeing the new value (2).
> > >
> > > The stwcx. failure was one thing that prevented a number of other
> > > misordering cases. The problem is that we have to let go of the notion
> > > of an implicit global clock.
> > >
> > > To that end, the herd tool can make a diagram of what it thought
> > > happened, and I have
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > > Suppose we have something like the following, where "a" and "x" are both
> > > > initially zero:
> > > >
> > > > CPU 0 CPU 1
> > > > - -
> > > >
> > > > WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> > > > r3 = xchg(, 1); smp_mb();
> > > > r3 = READ_ONCE(x);
> > > >
> > > > If xchg() is fully ordered, we should never observe both CPUs'
> > > > r3 values being zero, correct?
> > > >
> > > > And wouldn't this be represented by the following litmus test?
> > > >
> > > > PPC SB+lwsync-RMW2-lwsync+st-sync-leading
> > > > ""
> > > > {
> > > > 0:r1=1; 0:r2=x; 0:r3=3; 0:r10=0 ; 0:r11=0; 0:r12=a;
> > > > 1:r1=2; 1:r2=x; 1:r3=3; 1:r10=0 ; 1:r11=0; 1:r12=a;
> > > > }
> > > > P0 | P1 ;
> > > > stw r1,0(r2) | stw r1,0(r12) ;
> > > > lwsync | sync ;
> > > > lwarx r11,r10,r12 | lwz r3,0(r2) ;
> > > > stwcx. r1,r10,r12 | ;
> > > > bne Fail0 | ;
> > > > mr r3,r11 | ;
> > > > Fail0: | ;
> > > > exists
> > > > (0:r3=0 /\ a=2 /\ 1:r3=0)
> > > >
> > > > I left off P0's trailing sync because there is nothing for it to order
> > > > against in this particular litmus test. I tried adding it and verified
> > > > that it has no effect.
> > > >
> > > > Am I missing something here? If not, it seems to me that you need
> > > > the leading lwsync to instead be a sync.
>
> I'm afraid more than that, the above litmus also shows that
>
> CPU 0 CPU 1
> - -
>
> WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> r3 = xchg_release(, 1); smp_mb();
> r3 = READ_ONCE(x);
>
> (0:r3 == 0 && 1:r3 == 0 && a == 2) is not prohibitted
>
> in the implementation of this patchset, which should be disallowed by
> the semantics of RELEASE, right?
Not necessarily. If you had the read first on CPU 1, and you had a
similar problem, I would be more worried.
> And even:
>
> CPU 0 CPU 1
> - -
>
> WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
> smp_store_release(, 1); smp_mb();
> r3 = READ_ONCE(x);
>
> (1:r3 == 0 && a == 2) is not prohibitted
>
> shows by:
>
> PPC weird-lwsync
> ""
> {
> 0:r1=1; 0:r2=x; 0:r3=3; 0:r12=a;
> 1:r1=2; 1:r2=x; 1:r3=3; 1:r12=a;
> }
>P0 | P1 ;
>stw r1,0(r2) | stw r1,0(r12) ;
>lwsync | sync ;
>stw r1,0(r12) | lwz r3,0(r2) ;
> exists
> (a=2 /\ 1:r3=0)
>
> Please find something I'm (or the tool is) missing, maybe we can't use
> (a == 2) as a indication that STORE on CPU 1 happens after STORE on CPU
> 0?
Again, if you were pairing the smp_store_release() with an smp_load_acquire()
or even a READ_ONCE() followed by a barrier, I would be quite concerned.
I am not at all worried about the above two litmus tests.
> And there is really something I find strange, see below.
>
> > >
> > > So the scenario that would fail would be this one, right?
> > >
> > > a = x = 0
> > >
> > > CPU0CPU1
> > >
> > > r3 = load_locked ();
> > > a = 2;
> > > sync();
> > > r3 = x;
> > > x = 1;
> > > lwsync();
> > > if (!store_cond(, 1))
> > > goto again
> > >
> > >
> > > Where we hoist the load way up because lwsync allows this.
> >
> > That scenario would end up with a==1 rather than a==2.
> >
> > > I always thought this would fail because CPU1's store to @a would fail
> > > the store_cond() on CPU0 and we'd do the 'again' thing, re-issuing the
> > > load and now seeing the new value (2).
> >
> > The stwcx. failure was one thing that prevented a number of other
> > misordering cases. The problem is that we have to let go of the notion
> > of an implicit global clock.
> >
> > To that end, the herd tool can make a diagram of what it thought
> > happened, and I have attached it. I used this diagram to try and force
> > this scenario at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#PPC,
> > and succeeded. Here is the sequence of events:
> >
> > o Commit P0's write. The model offers to propagate this
linux-next: manual merge of the tip tree with the arm64 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
Documentation/arm/uefi.txt
between commit:
d4dddfdbbc75 ("arm64/efi: remove /chosen/linux, uefi-stub-kern-ver DT
property")
from the arm64 tree and commit:
c9494dc81875 ("arm64: Use core efi=debug instead of uefi_debug command line
parameter")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/arm/uefi.txt
index 7f1bed8872f3,7b3fdfe0f7ba..
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@@ -58,5 -58,5 +58,3 @@@ linux,uefi-mmap-desc-size | 32-bit | Si
linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format.
-
- For verbose debug messages, specify 'uefi_debug' on the kernel command line.
-linux,uefi-stub-kern-ver | string | Copy of linux_banner from build.
-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] scsi: kconfig: When possible, compile drivers with COMPILE_TEST
Hi Luis,
[auto build test WARNING on scsi/for-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Luis-de-Bethencourt/scsi-kconfig-When-possible-compile-drivers-with-COMPILE_TEST/20151015-073819
config: sh-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh
All warnings (new ones prefixed by >>):
drivers/scsi/pas16.c: In function 'NCR5380_pread':
>> drivers/scsi/pas16.c:500:18: warning: unused variable 'i' [-Wunused-variable]
>> drivers/scsi/pas16.c:498:29: warning: unused variable 'reg'
>> [-Wunused-variable]
>> drivers/scsi/pas16.c:497:30: warning: unused variable 'd' [-Wunused-variable]
drivers/scsi/pas16.c: In function 'NCR5380_pwrite':
drivers/scsi/pas16.c:537:18: warning: unused variable 'i' [-Wunused-variable]
drivers/scsi/pas16.c:536:29: warning: unused variable 'reg'
[-Wunused-variable]
>> drivers/scsi/pas16.c:535:29: warning: unused variable 's' [-Wunused-variable]
vim +/i +500 drivers/scsi/pas16.c
^1da177e Linus Torvalds 2005-04-16 491 * Returns : 0 on success, non zero on
a failure such as a watchdog
^1da177e Linus Torvalds 2005-04-16 492 * timeout.
^1da177e Linus Torvalds 2005-04-16 493 */
^1da177e Linus Torvalds 2005-04-16 494
^1da177e Linus Torvalds 2005-04-16 495 static inline int NCR5380_pread
(struct Scsi_Host *instance, unsigned char *dst,
^1da177e Linus Torvalds 2005-04-16 496 int len) {
^1da177e Linus Torvalds 2005-04-16 @497 register unsigned char *d = dst;
^1da177e Linus Torvalds 2005-04-16 @498 register unsigned short reg =
(unsigned short) (instance->io_port +
^1da177e Linus Torvalds 2005-04-16 499 P_DATA_REG_OFFSET);
^1da177e Linus Torvalds 2005-04-16 @500 register int i = len;
^1da177e Linus Torvalds 2005-04-16 501 int ii = 0;
a9c2dc43 Finn Thain 2014-11-12 502 struct NCR5380_hostdata *hostdata
= shost_priv(instance);
^1da177e Linus Torvalds 2005-04-16 503
^1da177e Linus Torvalds 2005-04-16 504 while ( !(inb(instance->io_port +
P_STATUS_REG_OFFSET) & P_ST_RDY) )
^1da177e Linus Torvalds 2005-04-16 505 ++ii;
^1da177e Linus Torvalds 2005-04-16 506
^1da177e Linus Torvalds 2005-04-16 507 insb( reg, d, i );
^1da177e Linus Torvalds 2005-04-16 508
^1da177e Linus Torvalds 2005-04-16 509 if ( inb(instance->io_port +
P_TIMEOUT_STATUS_REG_OFFSET) & P_TS_TIM) {
^1da177e Linus Torvalds 2005-04-16 510 outb( P_TS_CT,
instance->io_port + P_TIMEOUT_STATUS_REG_OFFSET);
^1da177e Linus Torvalds 2005-04-16 511 printk("scsi%d : watchdog timer
fired in NCR5380_pread()\n",
^1da177e Linus Torvalds 2005-04-16 512 instance->host_no);
^1da177e Linus Torvalds 2005-04-16 513 return -1;
^1da177e Linus Torvalds 2005-04-16 514 }
a9c2dc43 Finn Thain 2014-11-12 515 if (ii > hostdata->spin_max_r)
a9c2dc43 Finn Thain 2014-11-12 516 hostdata->spin_max_r = ii;
^1da177e Linus Torvalds 2005-04-16 517 return 0;
^1da177e Linus Torvalds 2005-04-16 518 }
^1da177e Linus Torvalds 2005-04-16 519
^1da177e Linus Torvalds 2005-04-16 520 /*
^1da177e Linus Torvalds 2005-04-16 521 * Function : int NCR5380_pwrite
(struct Scsi_Host *instance,
^1da177e Linus Torvalds 2005-04-16 522 * unsigned char *src, int len)
^1da177e Linus Torvalds 2005-04-16 523 *
^1da177e Linus Torvalds 2005-04-16 524 * Purpose : Fast 5380 pseudo-dma
write function, transfers len bytes from
^1da177e Linus Torvalds 2005-04-16 525 * src
^1da177e Linus Torvalds 2005-04-16 526 *
^1da177e Linus Torvalds 2005-04-16 527 * Inputs : src = source, len = length
in bytes
^1da177e Linus Torvalds 2005-04-16 528 *
^1da177e Linus Torvalds 2005-04-16 529 * Returns : 0 on success, non zero on
a failure such as a watchdog
^1da177e Linus Torvalds 2005-04-16 530 * timeout.
^1da177e Linus Torvalds 2005-04-16 531 */
^1da177e Linus Torvalds 2005-04-16 532
^1da177e Linus Torvalds 2005-04-16 533 static inline int NCR5380_pwrite
(struct Scsi_Host *instance, unsigned char *src,
^1da177e Linus Torvalds 2005-04-16 534 int len) {
^1da177e Linus Torvalds 2005-04-16 @535 register unsigned char *s = src;
^1da177e Linus Torvalds 2005-04-16 536 register unsigned short reg =
(instance->io_port + P_DATA_REG_OFFSET);
^1da177e Linus Torvalds 2005-04-16 537 register int i = len;
^1da177e Linus Torvalds 2005-04-16 538 int ii = 0;
:: The code at line 500 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
Re: linux-next: build failure after merge of the dwmw2-iommu tree
Hi David,
On Mon, 12 Oct 2015 18:32:57 +1100 Stephen Rothwell
wrote:
>
> After merging the dwmw2-iommu tree, today's linux-next build (i386
> defconfig) failed like this:
>
> In file included from drivers/gpu/drm/i915/i915_drv.h:50:0,
> from drivers/gpu/drm/i915/i915_drv.c:34:
> include/linux/intel-iommu.h:477:22: error: field 'notifier' has incomplete
> type
> struct mmu_notifier notifier;
> ^
>
> Caused by commit
>
> a7002bccff99 ("iommu/vt-d: Add intel_svm_{un,}bind_mm() functions")
>
> I have added the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 12 Oct 2015 17:51:50 +1100
> Subject: [PATCH] iommu/vt-d: fix for "Add intel_svm_{un,}bind_mm() functions"
>
> Signed-off-by: Stephen Rothwell
> ---
> include/linux/intel-iommu.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index aa7e02d623c9..39a382cbbbd4 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -474,7 +474,9 @@ extern int intel_svm_finish_prq(struct intel_iommu
> *iommu);
>
> struct intel_svm {
> struct kref kref;
> +#ifdef CONFIG_MMU_NOTIFIER
> struct mmu_notifier notifier;
> +#endif
> struct mm_struct *mm;
> struct intel_iommu *iommu;
> struct device *dev;
> --
> 2.5.3
Ping?
Of course my patch did not apply today since the kref has now vanished
in a rebase ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()
> > X-Signed-Off-By: Rainer Weikusat > Hi, So the patches I've posted and yours both use the idea of a relaying the remote peer wakeup via callbacks that are internal to the net/unix, such that we avoid exposing the remote peer wakeup to the external poll()/select()/epoll(). They differ in when and how those callbacks are registered/unregistered. So I think your approach here will generally keep the peer wait wakeup queue to its absolute minimum, by removing from that queue when we set POLLOUT, however it requires taking the peer waitqueue lock on every poll() call. So I think there are tradeoffs here vs. what I've posted. So for example, if there are a lot of writers against one 'server' socket, there is going to be a lot of lock contention with your approach here. So I think the performance is going to depend on the workload that is tested. I don't have a specific workload that I am trying to solve here, but since you introduced the waiting on the remote peer queue, perhaps you can post numbers comparing the patches that have been posted for the workload that this was developed for? I will send you the latest version of what I have privately - so as not to overly spam the list. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 0/4] net: dsa: mv88e6xxx: fix hardware bridging
On Wed, Oct 14, 2015 at 09:28:55PM -0400, Vivien Didelot wrote: > On Oct. Thursday 15 (42) 12:46 AM, Andrew Lunn wrote: > > On Sun, Oct 11, 2015 at 06:08:34PM -0400, Vivien Didelot wrote: > > > DSA and its drivers currently hook the NETDEV_CHANGEUPPER net_device > > > event in > > > order to configure the VLAN map of every port. > > > > > > This VLAN map is a feature of these switch chips to hardcode and restrict > > > which > > > output ports a given input port can egress frames to. > > > > > > A Linux bridge is a simple untagged VLAN propagated by the bridge code > > > itself. > > > With a proper 802.1Q support, a driver does not need this hook anymore, > > > and > > > will simply program the related VLAN object. > > > > > > This patchset improves the hardware bridging code in the mv88e6xxx driver > > > with > > > a strict 802.1Q mode. > > > > Hi Vivien > > > > I just tested this as part of net-next/master, and found a problem > > > > If i do: > > > > ip link set lan0 up > > ip addr add 192.168.10.2/24 dev lan0 > > > > It will not ping. Looking in sys/kernel/debug/dsa0/stats i see > > broadcast packets, probably ARP, being received at the port. > > But they are not being forwarded out the CPU port. > > > > If however i do > > > > brctl addbr br0 > > brctl addif br0 lan0 > > ip addr add 192.168.10.2/24 dev br0 > > ip link set br0 up > > > > i can ping. > > > > So it looks like we are too restrictive by default. You should be able > > to use interfaces as they are, without a bridge. > > Correct, if the ports are not in a VLAN by default, they cannot talk. Hi Vivien This is a regression. Ports of the switch should work like normal Linux interfaces. And up until now, they did. This patchset changed that. As Florian pointed out, these interfaces are separated from each other. So you need something like a bridge per port by default, which then gets removed and replaced when a port is added to a Linux bridge. We also need to take care of VLANs. When the port is not a member of a linux bridge, i expect all VLAN tagged frames to be received, as well as untagged frames. This is normal Linux behaviour. But i never got around to testing this with DSA. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re[2]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> > > Did you try reverting the "x86/smpboot: Remove > APIC.wait_for_init_deassert > > > and atomic init_deasserted" patch? > > > > Yes, please let me know if reverting that patch helps you too. > > How? Please send a patch or git cmd(s).I have the > git/stable/linux-stable.git on my PC. Thanks. git log calls it this: commit 656bba306827a44ed73b3f93f75bb3147de17fae Author: Len Brown Date: Sun Aug 16 11:45:48 2015 -0400 x86/smpboot: Remove APIC.wait_for_init_deassert and atomic init_deasserted So you want to simply do this: $ git revert 656bba306827a44ed73b3f93f75bb3147de17fae build and test. cheers, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping
On Tue, 13 Oct 2015 06:59:26 -0700, Richard Cochran
wrote:
On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote:
+struct ptp_sys_offset_precise {
+ unsigned int rsv[4];/* Reserved for future use. */
+ struct ptp_clock_time dev;
+ struct ptp_clock_time sys;
+};
+
Please put the reserved field at the bottom. Also, since we reading
the raw monotonic time under the hood, we might as well return it in
Good idea.
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 8/8] zram: enable contextless compression alg in zram
On Thu, Oct 15, 2015 at 11:05:49AM +0900, Sergey Senozhatsky wrote:
> On (10/14/15 16:38), Joonsoo Kim wrote:
> [..]
> > @@ -352,6 +352,7 @@ static ssize_t comp_algorithm_show(struct device *dev,
> > size_t sz;
> > struct zram *zram = dev_to_zram(dev);
> >
> > + deprecated_attr_warn("comp_algorithm");
> > down_read(>init_lock);
> > sz = zcomp_available_show(zram->compressor, buf);
> > up_read(>init_lock);
>
> oh, one more thing.
>
> deprecated_attr_warn() should come with
> `Documentation/ABI/obsolete/sysfs-block-zram' update.
> something like:
>
> diff --git a/Documentation/ABI/obsolete/sysfs-block-zram
> b/Documentation/ABI/obsolete/sysfs-block-zram
> index 720ea92..ad5b59d 100644
> --- a/Documentation/ABI/obsolete/sysfs-block-zram
> +++ b/Documentation/ABI/obsolete/sysfs-block-zram
> @@ -117,3 +117,14 @@ Description:
> Downgraded to write-only node: so it's possible to set new
> value only; its current value is stored in zram/mm_stat
> node.
> +
> +What: /sys/block/zram/comp_algorithm
> +Date: XXX
> +Contact: XXX
> +Description:
> + The comp_algorithm file is read/write and provides information
> + on available, currently selected compression algorithm (read
> + operation) and lets one to change the compression algorithm
> + (write operation).
> + Downgraded to write-only node: use `/proc/crypto' to get the
> + list of supported compression algorithms.
>
>
> ---
>
>
> And I guess Cc `Jonathan Corbet ' (doc maintainer) and
> 'linux-...@vger.kernel.org' will be the right thing to do here.
Okay. I will do it in next spin.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mmc: mediatek: Add tune support
On Wed, 2015-10-14 at 12:05 +0200, Ulf Hansson wrote:
> On 13 October 2015 at 11:37, Chaotian Jing wrote:
> > Add CMD19/CMD21 support for EMMC/SD/SDIO tuning
> > Add HS400 mode support
> >
> > Signed-off-by: Chaotian Jing
> > ---
> > drivers/mmc/host/mtk-sd.c | 359
> > ++
> > 1 file changed, 332 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index b2e89d3..f12a50a 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -64,6 +65,7 @@
> > #define SDC_RESP20x48
> > #define SDC_RESP30x4c
> > #define SDC_BLK_NUM 0x50
> > +#define EMMC_IOCON 0x7c
> > #define SDC_ACMD_RESP0x80
> > #define MSDC_DMA_SA 0x90
> > #define MSDC_DMA_CTRL0x98
> > @@ -71,6 +73,8 @@
> > #define MSDC_PATCH_BIT 0xb0
> > #define MSDC_PATCH_BIT1 0xb4
> > #define MSDC_PAD_TUNE0xec
> > +#define PAD_DS_TUNE 0x188
> > +#define EMMC50_CFG0 0x208
> >
> >
> > /*--*/
> > /* Register Mask
> > */
> > @@ -87,6 +91,7 @@
> > #define MSDC_CFG_CKSTB (0x1 << 7) /* R */
> > #define MSDC_CFG_CKDIV (0xff << 8)/* RW */
> > #define MSDC_CFG_CKMOD (0x3 << 16)/* RW */
> > +#define MSDC_CFG_HS400_CK_MODE (0x1 << 18)/* RW */
> >
> > /* MSDC_IOCON mask */
> > #define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
> > @@ -204,6 +209,17 @@
> > #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29) /* RW */
> > #define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
> >
> > +#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
> > +#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16) /* RW */
> > +
> > +#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
> > +#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
> > +#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
> > +
> > +#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
> > +#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3) /* RW */
> > +#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4) /* RW */
> > +
> > #define REQ_CMD_EIO (0x1 << 0)
> > #define REQ_CMD_TMO (0x1 << 1)
> > #define REQ_DAT_ERR (0x1 << 2)
> > @@ -219,6 +235,7 @@
> > #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
> > #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
> >
> > +#define DELAY_MAX 32 /* PAD dalay cells */
>
> /s/dalay/delay
>
> Can we have some more explaination around this define. Perhaps a more
> self-explaining name would be enough.-
This is the max step of the pad delay cells, our hardware use 5bits to
describe the pad delay.
will change it to
#define PAD_DELAY_MAX 32
> >
> > /*--*/
> > /* Descriptor Structure
> > */
> >
> > /*--*/
> > @@ -265,6 +282,14 @@ struct msdc_save_para {
> > u32 pad_tune;
> > u32 patch_bit0;
> > u32 patch_bit1;
> > + u32 pad_ds_tune;
> > + u32 emmc50_cfg0;
> > +};
> > +
> > +struct msdc_delay_phase {
> > + u8 maxlen;
> > + u8 start;
> > + u8 final_phase;
> > };
> >
> > struct msdc_host {
> > @@ -293,12 +318,15 @@ struct msdc_host {
> > int irq;/* host interrupt */
> >
> > struct clk *src_clk;/* msdc source clock */
> > + struct clk *src_clk_parent; /* src_clk's parent */
> > + struct clk *hs400_src; /* 400Mhz source clock */
>
> Hmm, so you need to control the upper level clocks. Can you elaborate
> on why this is needed?
>
hs400 is DDR200, in our host design, if the mode is DDR(HS400), if want
to get 200Mhz mmc bus clock frequency, the minimum source clock is
double of the mmc bus clock, So, we need it for HS400 mode with 200Mhz
bus clock.
> > struct clk *h_clk; /* msdc h_clk */
> > u32 mclk; /* mmc subsystem clock frequency */
> > u32 src_clk_freq; /* source clock frequency */
> > u32 sclk; /* SD/MS bus clock frequency */
> > - bool ddr;
> > + unsigned char timing;
> > bool vqmmc_enabled;
> > + u32 hs400_ds_delay;
> > struct msdc_save_para save_para; /* used when gate HCLK */
> > };
> >
> > @@ -353,7 +381,10 @@ static void msdc_reset_hw(struct msdc_host *host)
> > static void msdc_cmd_next(struct msdc_host *host,
> > struct mmc_request *mrq, struct mmc_command *cmd);
> >
> > -static u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
> > +static const u32 cmd_ints_mask = MSDC_INTEN_CMDRDY | MSDC_INTEN_RSPCRCERR |
> > +
RE: Re[2]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
On Thu, 2015-10-15 at 02:09 +, Brown, Len wrote: > Donald, Shane, > Thanks for reporting this. > > > > I also tried suggested /vmlinuz-4.3.0-rc3 parameter in grub: > > > "cpu_init_udelay=1" > > > which did not help getting missing CPU back online. > > right, if the issue is caused by the patch below, > that cmdline will not help. > > > Did you try reverting the "x86/smpboot: Remove APIC.wait_for_init_deassert > > and atomic init_deasserted" patch? > > Yes, please let me know if reverting that patch helps you too. How? Please send a patch or git cmd(s).I have the git/stable/linux-stable.git on my PC. Thanks. > You have similar hardware: > > Shane: > > smpboot: CPU0: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (fam: 06, > model: 0f, stepping: 06) > > Donald: > > CPU : Intel Core 2 CPU 6600 @ 2.4GHz Mine is also same (fam: 06, model: 0f, stepping: 06). > I think I can get ahold of a core2 6xxx box tomorrow. > Please send me your .config directly, and I'll see if I can reproduce the > issue. Will do. Don -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 5/5] nvme: LightNVM support
Hi Matias,
[auto build test WARNING on block/for-next -- if it's inappropriate base,
please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matias-Bj-rling/Support-for-Open-Channel-SSDs/20151014-224617
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/nvme/host/lightnvm.c:282:23: sparse: incorrect type in assignment
>> (different base types)
drivers/nvme/host/lightnvm.c:282:23:expected restricted __le32
[assigned] [usertype] nsid
drivers/nvme/host/lightnvm.c:282:23:got unsigned int [unsigned] ns_id
>> drivers/nvme/host/lightnvm.c:291:19: sparse: cast to restricted __le64
drivers/nvme/host/lightnvm.c:292:19: sparse: cast to restricted __le64
>> drivers/nvme/host/lightnvm.c:331:28: sparse: incorrect type in assignment
>> (different base types)
drivers/nvme/host/lightnvm.c:331:28:expected restricted __le64
[assigned] [usertype] slba
drivers/nvme/host/lightnvm.c:331:28:got unsigned long long [unsigned]
[usertype] cmd_slba
>> drivers/nvme/host/lightnvm.c:332:27: sparse: incorrect type in assignment
>> (different base types)
drivers/nvme/host/lightnvm.c:332:27:expected restricted __le32
[assigned] [usertype] nlb
drivers/nvme/host/lightnvm.c:332:27:got unsigned long long [unsigned]
[usertype] cmd_nlb
vim +282 drivers/nvme/host/lightnvm.c
276 struct nvme_nvm_command c = {};
277 int sz = sizeof(struct nvm_get_features);
278 int ret;
279 u64 *resp;
280
281 c.common.opcode = nvme_nvm_admin_get_features;
> 282 c.common.nsid = ns->ns_id;
283 resp = kmalloc(sz, GFP_KERNEL);
284 if (!resp)
285 return -ENOMEM;
286
287 ret = nvme_submit_sync_cmd(q, (struct nvme_command *), resp,
sz);
288 if (ret)
289 goto done;
290
> 291 gf->rsp = le64_to_cpu(resp[0]);
292 gf->ext = le64_to_cpu(resp[1]);
293
294 done:
295 kfree(resp);
296 return ret;
297 }
298
299 static int nvme_nvm_set_resp(struct request_queue *q, u64 resp)
300 {
301 struct nvme_ns *ns = q->queuedata;
302 struct nvme_nvm_command c = {};
303
304 c.resp.opcode = nvme_nvm_admin_set_resp;
305 c.resp.nsid = cpu_to_le32(ns->ns_id);
306 c.resp.resp = cpu_to_le64(resp);
307 return nvme_submit_sync_cmd(q, (struct nvme_command *), NULL,
0);
308 }
309
310 static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u64
nlb,
311 nvm_l2p_update_fn *update_l2p, void
*priv)
312 {
313 struct nvme_ns *ns = q->queuedata;
314 struct nvme_dev *dev = ns->dev;
315 struct nvme_nvm_command c = {};
316 u32 len = queue_max_hw_sectors(q) << 9;
317 u64 nlb_pr_rq = len / sizeof(u64);
318 u64 cmd_slba = slba;
319 void *entries;
320 int ret = 0;
321
322 c.l2p.opcode = nvme_nvm_admin_get_l2p_tbl;
323 c.l2p.nsid = cpu_to_le32(ns->ns_id);
324 entries = kmalloc(len, GFP_KERNEL);
325 if (!entries)
326 return -ENOMEM;
327
328 while (nlb) {
329 u64 cmd_nlb = min_t(u64, nlb_pr_rq, nlb);
330
> 331 c.l2p.slba = cmd_slba;
> 332 c.l2p.nlb = cmd_nlb;
333
334 ret = nvme_submit_sync_cmd(q, (struct nvme_command *),
335
entries, len);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the arm-soc tree
Dear all,
On Thu, 15 Oct 2015 10:19:20 +1100
Stephen Rothwell wrote:
> Hi all,
>
> After merging the arm-soc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/boot/dts/berlin2q.dtsi:62.24-25 syntax error
> FATAL ERROR: Unable to parse input tree
I just checked, this is caused by missing the following two commits
f72d787d9287 ("clk: berlin: move MAX_CLKS out of drivers/clk/berlin")
44b2e5f96d5e ("clk: berlin: add cpuclk")
Thanks,
Jisheng
>
> I can't see what caused this error, so I have just used the arm-soc tree
> from next-20151013 for today.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] watchdog: Add sysctl knob hardlockup_panic
The only way to enable a hardlockup to panic the machine is to set
'nmi_watchdog=panic' on the kernel command line.
This makes it awkward for end users and folks who want to run automate tests
(like myself).
Mimic the softlockup_panic knob and create a /proc/sys/kernel/hardlockup_panic
knob.
Signed-off-by: Don Zickus
---
Documentation/lockup-watchdogs.txt | 5 +++--
include/linux/sched.h | 1 +
kernel/sysctl.c| 9 +
kernel/watchdog.c | 2 +-
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/lockup-watchdogs.txt
b/Documentation/lockup-watchdogs.txt
index 22dd6af..4a6e33e 100644
--- a/Documentation/lockup-watchdogs.txt
+++ b/Documentation/lockup-watchdogs.txt
@@ -20,8 +20,9 @@ kernel mode for more than 10 seconds (see "Implementation"
below for
details), without letting other interrupts have a chance to run.
Similarly to the softlockup case, the current stack trace is displayed
upon detection and the system will stay locked up unless the default
-behavior is changed, which can be done through a compile time knob,
-"BOOTPARAM_HARDLOCKUP_PANIC", and a kernel parameter, "nmi_watchdog"
+behavior is changed, which can be done through a sysctl,
+'hardlockup_panic', a compile time knob, "BOOTPARAM_HARDLOCKUP_PANIC",
+and a kernel parameter, "nmi_watchdog"
(see "Documentation/kernel-parameters.txt" for details).
The panic option can be used in combination with panic_timeout (this
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b7b9501..5e65b14 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -384,6 +384,7 @@ extern int proc_dowatchdog_thresh(struct ctl_table *table,
int write,
void __user *buffer,
size_t *lenp, loff_t *ppos);
extern unsigned int softlockup_panic;
+extern unsigned int hardlockup_panic;
void lockup_detector_init(void);
#else
static inline void touch_softlockup_watchdog(void)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index efb0370..3e6a742 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -887,6 +887,15 @@ static struct ctl_table kern_table[] = {
.extra1 = ,
.extra2 = ,
},
+ {
+ .procname = "hardlockup_panic",
+ .data = _panic,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = ,
+ .extra2 = ,
+ },
#ifdef CONFIG_SMP
{
.procname = "softlockup_all_cpu_backtrace",
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index f6b32b8..0a23125 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -112,7 +112,7 @@ static unsigned long soft_lockup_nmi_warn;
* Should we panic when a soft-lockup or hard-lockup occurs:
*/
#ifdef CONFIG_HARDLOCKUP_DETECTOR
-static int hardlockup_panic =
+unsigned int __read_mostly hardlockup_panic =
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE;
static unsigned long hardlockup_allcpu_dumped;
/*
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/9] mm/compaction: redesign compaction
On Wed, Oct 14, 2015 at 01:38:07PM +0200, Vlastimil Babka wrote:
> On 08/24/2015 04:19 AM, Joonsoo Kim wrote:
>
> [...]
>
> > This patch solves these problems mentioned in above.
> > Freepage scanner is largely changed to scan zone from zone_start_pfn
> > to zone_end_pfn. And, by this change, compaction finish condition is also
> > changed that migration scanner reach zone_end_pfn. With these changes,
> > migration scanner can traverse anywhere in the zone.
> >
> > To prevent back and forth migration within one compaction iteration,
> > freepage scanner marks skip-bit when scanning pageblock. migration scanner
> > checks it and will skip this marked pageblock so back and forth migration
> > cannot be possible in one compaction iteration.
> >
> > If freepage scanner reachs the end of zone, it restarts at zone_start_pfn.
> > In this time, freepage scanner would scan the pageblock where migration
> > scanner has migrated some pages but fail to make high order page. This
> > leaved freepages means that they can't become high order page due to
> > the fragmentation so it is good source for freepage scanner.
>
> Hmm, there might be danger that freepage scanner will proceed faster than
> migration scanner, as evidenced by the current code where the scanners meet
> earlier than in the middle. Thus, it would likely mark pageblocks as
> unsuitable
> for migration scanner, before it can reach them?
That's right.
>
> > With this change, above test result is:
> >
> > Kernel: Base vs Redesign
> >
> > Test: hogger-frag-movable
> >
> > Success(N)70 94
> > compact_stall3073642
> > compact_success 64 144
> > compact_fail 2433498
> > pgmigrate_success 3459215897219
> > compact_isolated 7397731899553
> > compact_migrate_scanned 228077059146745
> > compact_free_scanned 471031349566134
> >
> > Test: hogger-frag-movable with free memory variation
> >
> > 200MB-Success(N)70 94
> > 250MB-Success(N)38 93
> > 300MB-Success(N)29 89
> >
> > Compaction gives us almost all possible high order page. Overhead is
> > highly increased, but, further patch will reduce it greatly
> > by adjusting depletion check with this new algorithm.
> >
> > Signed-off-by: Joonsoo Kim
> > ---
> > mm/compaction.c | 145
> > ++--
> > 1 file changed, 77 insertions(+), 68 deletions(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index a259608..ca4d6d1 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -53,17 +53,17 @@ static const char *const compaction_status_string[] = {
> > static unsigned long release_freepages(struct list_head *freelist)
> > {
> > struct page *page, *next;
> > - unsigned long high_pfn = 0;
> > + unsigned long low_pfn = ULONG_MAX;
> >
> > list_for_each_entry_safe(page, next, freelist, lru) {
> > unsigned long pfn = page_to_pfn(page);
> > list_del(>lru);
> > __free_page(page);
> > - if (pfn > high_pfn)
> > - high_pfn = pfn;
> > + if (pfn < low_pfn)
> > + low_pfn = pfn;
> > }
> >
> > - return high_pfn;
> > + return low_pfn;
>
> This assumes that the freelist won't contain both pages from the end of the
> zone, and from the beginning the zone after the free scanner has wrapped.
> Which
> is true, but not immediately obvious, so it deserves some comment.
Okay. Will add it.
> > }
> >
> > static void map_pages(struct list_head *list)
> > @@ -243,7 +243,7 @@ static void __reset_isolation_suitable(struct zone
> > *zone)
> >
> > zone->compact_cached_migrate_pfn[0] = start_pfn;
> > zone->compact_cached_migrate_pfn[1] = start_pfn;
> > - zone->compact_cached_free_pfn = end_pfn;
> > + zone->compact_cached_free_pfn = start_pfn;
> > zone->compact_blockskip_flush = false;
> >
> > clear_bit(ZONE_COMPACTION_SCANALLFREE, >flags);
> > @@ -335,7 +335,7 @@ static void update_pageblock_skip(struct
> > compact_control *cc,
> > if (!nr_isolated)
> > set_pageblock_skip_freescan(page);
> >
> > - if (pfn < zone->compact_cached_free_pfn)
> > + if (pfn > zone->compact_cached_free_pfn)
> > zone->compact_cached_free_pfn = pfn;
> > }
> > }
> > @@ -869,8 +869,11 @@ isolate_success:
> > nr_scanned, nr_isolated);
> >
> > count_compact_events(COMPACTMIGRATE_SCANNED, nr_scanned);
> > - if (nr_isolated)
> > + if (nr_isolated) {
> > count_compact_events(COMPACTISOLATED, nr_isolated);
> > + if (valid_page)
> > + clear_pageblock_skip_freescan(valid_page);
>
> This is explained in changelog, but a comment here would be useful too.
Okay.
> > + }
> >
> >
Re: linux-next: build failure after merge of the asm-generic tree
Hi, On Thu, 15 Oct 2015 07:32:27 +0800 kbuild test robot wrote: > > [auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please > suggest rules for selecting the more suitable base] I think you should just ignore any patches from me that have "linux-next:" in the subject line as they need to be applied either to a branch I have merged or to a combination of branches I have merged. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu/vt-d: Use cmpxchg16b to update posted format IRTE atomically
If IRTE is in posted format, the 'pda' field goes across the 64-bit
boundary, we need use cmpxchg16b to atomically update it. We only
expose posted-interrupt when X86_FEATURE_CX16 is supported and use
to update it atomically.
Signed-off-by: Feng Wu
---
drivers/iommu/intel_irq_remapping.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index f15692a..b4f7569 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -169,8 +169,26 @@ static int modify_irte(struct irq_2_iommu *irq_iommu,
index = irq_iommu->irte_index + irq_iommu->sub_handle;
irte = >ir_table->base[index];
- set_64bit(>low, irte_modified->low);
- set_64bit(>high, irte_modified->high);
+#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE)
+ if ((irte->pst == 1) || (irte_modified->pst == 1)) {
+ bool ret;
+
+ ret = cmpxchg_double(>low, >high,
+irte->low, irte->high,
+irte_modified->low, irte_modified->high);
+ /*
+* We use cmpxchg16 to atomically update the 128-bit IRTE,
+* and it cannot be updated by the hardware or other processors
+* behind us, so the return value of cmpxchg16 should be the
+* same as the old value.
+*/
+ BUG_ON(!ret);
+ } else
+#endif
+ {
+ set_64bit(>low, irte_modified->low);
+ set_64bit(>high, irte_modified->high);
+ }
__iommu_flush_cache(iommu, irte, sizeof(*irte));
rc = qi_flush_iec(iommu, index, 0);
@@ -725,7 +743,16 @@ static inline void set_irq_posting_cap(void)
struct intel_iommu *iommu;
if (!disable_irq_post) {
- intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
+ /*
+* If IRTE is in posted format, the 'pda' field goes across the
+* 64-bit boundary, we need use cmpxchg16b to atomically update
+* it. We only expose posted-interrupt when X86_FEATURE_CX16
+* is supported. Actually, hardware platforms supporting PI
+* should have X86_FEATURE_CX16 support, this has been confirmed
+* with Intel hardware guys.
+*/
+ if ( cpu_has_cx16 )
+ intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
for_each_iommu(iommu, drhd)
if (!cap_pi_support(iommu->cap)) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Produce system time from correlated clocksource
Richard, On Tue, 13 Oct 2015 14:12:24 -0700, Richard Cochran wrote: On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: Can we at least have a explanation of how the firmware operates? How are (ART,sys) pairs are generated, and how they are supposed to get into the DSP? I'll give it a try. The audio controller has a set of registers almost exactly like those on the network device. The e1000e patch adds the e1000e_phc_get_ts() function. It writes a register to start the cross-timestamp process and some time later the hardware sets a bit indicating that it's finished. In the case of the network, the host polls for this bit to be set, indicating the cross-timestamp registers have valid data. In the audio DSP case, it is the DSP that's doing the polling and it can only poll once per millisecond. The transfers look like: Host -PCI (write request) -> DSP [Transaction started from host] DSP -PCI (write to initiate)-> Audio controller [Transaction started from DSP] DSP <-PCI (read to poll status)- Audio Controller [Transaction Complete from DSP perspective] DSP <-PCI (read (ART,device) pair)- Audio Controller DSP -PCI (write notification) -> Host [Transaction complete from Host perspective] Host <-PCI read (ART,device) pair- DSP I hope this is helpful. Thanks. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: don't test shrinker_enabled in zs_shrinker_count()
On Wed, Oct 14, 2015 at 10:57:59AM +0900, Sergey Senozhatsky wrote:
> We don't let user to disable shrinker in zsmalloc (once
> it's been enabled), so no need to check ->shrinker_enabled
> in zs_shrinker_count(), at the moment at least.
I'm in favor of removing shrinker disable feature with this patch(
although we didn't implement it yet) because if there is some problem
of compaction, we should reveal and fix it without hiding with the
feature.
One thing I want is if we decide it, let's remove all things
about shrinker_enabled(ie, variable).
If we might need it later, we could introduce it easily.
Thanks.
>
> Signed-off-by: Sergey Senozhatsky
> ---
> mm/zsmalloc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 7ad5e54..8ba247d 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1822,9 +1822,6 @@ static unsigned long zs_shrinker_count(struct shrinker
> *shrinker,
> struct zs_pool *pool = container_of(shrinker, struct zs_pool,
> shrinker);
>
> - if (!pool->shrinker_enabled)
> - return 0;
> -
> for (i = zs_size_classes - 1; i >= 0; i--) {
> class = pool->size_class[i];
> if (!class)
> --
> 2.6.1.134.g4b1fd35
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the mfd tree
Hi Lee,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/mfd/intel-lpss.c:29:47: fatal error:
asm-generic/io-64-nonatomic-lo-hi.h: No such file or directory
#include
^
Caused by commit
6a1d82fbc8e8 ("mfd: intel-lpss: Use writeq() helper")
interacting with commit
f626fe17485b ("move io-64-nonatomic*.h out of asm-generic")
from the asm-generic tree.
I have added the following merge fix patch and can carry it as necessary.
From: Stephen Rothwell
Date: Thu, 15 Oct 2015 13:23:20 +1100
Subject: [PATCH] mfd: fix for "move io-64-nonatomic*.h out of asm-generic"
Signed-off-by: Stephen Rothwell
---
drivers/mfd/intel-lpss.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 001a7d7708ce..6255513f54c7 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -25,8 +25,7 @@
#include
#include
#include
-
-#include
+#include
#include "intel-lpss.h"
--
2.5.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the mfd tree with the arm-soc tree
2015-10-15 11:19 GMT+09:00 Stephen Rothwell :
> Hi Lee,
>
> Today's linux-next merge of the mfd tree got a conflict in:
>
> Documentation/devicetree/bindings/mfd/s2mps11.txt
>
> between commit:
>
> 6a4479f96543 ("dt-bindings: Document grounded ACOKB pin on S2MPS11")
>
> from the arm-soc tree and commit:
>
> db96ec728d69 ("mfd: dt-bindings: Document pulled down WRSTBI pin on
> S2MPS1X")
>
> from the mfd tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks! The fix for conflict is good.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: use preempt.h for in_interrupt()
On Wed, Oct 14, 2015 at 10:13:20PM +0900, Sergey Senozhatsky wrote:
> A cosmetic change.
>
> Commit c60369f01125 ("staging: zsmalloc: prevent mappping
> in interrupt context") added in_interrupt() check to
> zs_map_object() and 'hardirq.h' include; but in_interrupt()
> macro is defined in 'preempt.h' not in 'hardirq.h', so include
> it instead.
>
> Signed-off-by: Sergey Senozhatsky
Acked-by: Minchan Kim
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] extcon: Modify the id and name of external connector
Hi Roger,
On 2015년 10월 14일 16:13, Roger Quadros wrote:
> Chanwoo,
>
> On 08/10/15 12:24, Chanwoo Choi wrote:
>> This patch modifies the id and name of external connector with the
>> additional prefix to clarify both attribute and meaning of external
>> connector as following:
>> - EXTCON_CHG_* mean the charger connector.
>> - EXTCON_JACK_* mean the jack connector.
>> - EXTCON_DISP_* mean the display port connector.
>>
>> Following table show the new name of external connector with old name:
>> --
>> Old extcon name | New extcon name|
>> --
>> EXTCON_TA | EXTCON_CHG_USB_DCP |
>> EXTCON_CHARGE_DOWNSTREAM| EXTCON_CHG_USB_CDP |
>> EXTCON_FAST_CHARGER | EXTCON_CHG_USB_FAST|
>> EXTCON_SLOW_CHARGER | EXTCON_CHG_USB_SLOW|
>> --
>> EXTCON_MICROPHONE | EXTCON_JACK_MICROPHONE |
>> EXTCON_HEADPHONE| EXTCON_JACK_HEADPHONE |
>> EXTCON_LINE_IN | EXTCON_JACK_LINE_IN|
>> EXTCON_LINE_OUT | EXTCON_JACK_LINE_OUT |
>> EXTCON_VIDEO_IN | EXTCON_JACK_VIDEO_IN |
>> EXTCON_VIDEO_OUT| EXTCON_JACK_VIDEO_OUT |
>> EXTCON_SPDIF_IN | EXTCON_JACK_SPDIF_IN |
>> EXTCON_SPDIF_OUT| EXTCON_JACK_SPDIF_OUT |
>> --
>> EXTCON_HMDI | EXTCON_DISP_HDMI |
>> EXTCON_MHL | EXTCON_DISP_MHL|
>> EXTCON_DVI | EXTCON_DISP_DVI|
>> EXTCON_VGA | EXTCON_DISP_VGA|
>> --
>>
>> And, when altering the name of USB charger connector, EXTCON refers to the
>> "Battery Charging v1.2 Spec and Adopters Agreement"[1] to use the standard
>> name of USB charging port as following. Following name of USB charging port
>> are already used in power_supply subsystem. We chan check it on patch[2].
>> - EXTCON_CHG_USB_SDP /* Standard Downstream Port */
>> - EXTCON_CHG_USB_DCP /* Dedicated Charging Port */
>> - EXTCON_CHG_USB_CDP /* Charging Downstream Port */
>> - EXTCON_CHG_USB_ACA /* Accessory Charger Adapter */
>>
>> [1] www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
>> [2] commit 85efc8a18ced ("power_supply: Add types for USB chargers")
>>
>> Signed-off-by: Chanwoo Choi
>> [ckeepax: For the Arizona changes]
>> Acked-by: Charles Keepax
>> ---
>> Changes from v3:
>> (https://lkml.org/lkml/2015/10/6/984)
>> - Modify the name of fast/slow charger connector as following:
>> : EXTCON_CHG_USB_DCP_FAST -> EXTCON_CHG_USB_FAST
>> : EXTCON_CHG_USB_DCP_SLOW -> EXTCON_CHG_USB_SLOW
>> - Add EXTCON_CHG_USB_SDP to mean the charging connector of SDP (Standard
>> Downstream Port)
>>
>> Changes from v2:
>> (https://lkml.org/lkml/2015/10/6/239)
>> - Remove the EXTCON_CHG_USB type to remove the possible confusion according
>> to
>> Roger's comment and drop patch2 about EXTCON_CHG_USB.
>> - Fix the warning issue provided by scripts/checkpatch.pl
>>
>> Changes from v1:
>> (https://lkml.org/lkml/2015/10/3/304)
>> - Add acked tag by Charles Keepax for arizona changes
>> - Modify the name of USB charger connector as following:
>> : EXTCON_CHG_USB_FAST -> EXTCON_CHG_USB_DCP_FAST
>> : EXTCON_CHG_USB_SLOW -> EXTCON_CHG_USB_DCP_SLOW
>> - Add the missing EXTCON_CHG_USB_ACA charger connector
>> - Add one more patch to support the EXTCON_CHG_USB when SDP port is
>> connected or not
>>
>> drivers/extcon/extcon-arizona.c | 18 ++--
>> drivers/extcon/extcon-axp288.c | 12
>> drivers/extcon/extcon-max14577.c | 17 +--
>> drivers/extcon/extcon-max77693.c | 32 +++--
>> drivers/extcon/extcon-max77843.c | 27 +
>> drivers/extcon/extcon-max8997.c | 21 +++---
>> drivers/extcon/extcon-rt8973a.c | 4 +--
>> drivers/extcon/extcon-sm5502.c | 4 +--
>> drivers/extcon/extcon.c | 61
>> ---
>> include/linux/extcon.h | 62
>> +++-
>> 10 files changed, 139 insertions(+), 119 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-arizona.c
>> b/drivers/extcon/extcon-arizona.c
>> index a1ab0a56b798..e4890dd4fefd 100644
>> --- a/drivers/extcon/extcon-arizona.c
>> +++ b/drivers/extcon/extcon-arizona.c
>> @@ -137,9 +137,9 @@ static const int arizona_micd_levels[] = {
>>
>> static const unsigned int arizona_cable[] = {
>> EXTCON_MECHANICAL,
>> -EXTCON_MICROPHONE,
>> -EXTCON_HEADPHONE,
>> -EXTCON_LINE_OUT,
>> +EXTCON_JACK_MICROPHONE,
>> +EXTCON_JACK_HEADPHONE,
>> +EXTCON_JACK_LINE_OUT,
>> EXTCON_NONE,
>> };
>>
>> @@ -600,7 +600,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
>> struct arizona_extcon_info *info = data;
>> struct arizona *arizona = info->arizona;
>> int id_gpio = arizona->pdata.hpdet_id_gpio;
>> -unsigned int
Re: [PATCH V2 2/2] bpf: control a set of perf events by creating a new ioctl PERF_EVENT_IOC_SET_ENABLER
于 2015/10/15 5:28, Alexei Starovoitov 写道: > On 10/14/15 5:37 AM, Kaixu Xia wrote: >> +event->p_sample_disable = _event->sample_disable; > > I don't like it as a concept and it's buggy implementation. > What happens here when enabler is alive, but other event is destroyed? > >> --- a/kernel/trace/bpf_trace.c >> +++ b/kernel/trace/bpf_trace.c >> @@ -221,9 +221,12 @@ static u64 bpf_perf_event_sample_control(u64 r1, u64 >> index, u64 flag, u64 r4, u6 >> struct bpf_array *array = container_of(map, struct bpf_array, map); >> struct perf_event *event; >> >> -if (unlikely(index >= array->map.max_entries)) >> +if (unlikely(index > array->map.max_entries)) >> return -E2BIG; >> >> +if (index == array->map.max_entries) >> +index = 0; > > what is this hack for ? > > Either use notification and user space disable or > call bpf_perf_event_sample_control() manually for each cpu. I will discard current implemention that controlling a set of perf events by the 'enabler' event. Call bpf_perf_event_sample_control() manually for each cpu is fine. Maybe we can add a loop to control all the events stored in maps by judging the index, OK? > > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the mfd tree with the arm-soc tree
Hi Lee,
Today's linux-next merge of the mfd tree got a conflict in:
Documentation/devicetree/bindings/mfd/s2mps11.txt
between commit:
6a4479f96543 ("dt-bindings: Document grounded ACOKB pin on S2MPS11")
from the arm-soc tree and commit:
db96ec728d69 ("mfd: dt-bindings: Document pulled down WRSTBI pin on S2MPS1X")
from the mfd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/mfd/s2mps11.txt
index 90eaef393325,a0bc753955c2..
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@@ -15,10 -15,9 +15,13 @@@ Optional properties
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the interrupts from s2mps11 are delivered to.
- interrupts: Interrupt specifiers for interrupt sources.
+- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is
+ connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
+ register to turn off the power. Usually the ACOKB is pulled up to VBATT so
+ when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
+ - samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled
+ down. When the system is suspended it will always go down thus triggerring
+ unwanted buck warm reset (setting buck voltages to default values).
Optional nodes:
- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi: set return value to const char for some functions
On Wed, 2015-10-14 at 20:53 +, Moore, Robert wrote: > In ACPICA, we tend to be very careful concerning the "const" keyword in order > to avoid a phenomenon known as "const pollution". > > That is not to say that we won't use const in some limited cases. Please describe the effects of "const pollution". Why isn't it useful to update the functions that don't modify function pointer arguments to const? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/31] perf tools: Compile scriptlets to BPF objects when passing '.c' to --event
On 2015/10/14 23:45, Namhyung Kim wrote:
On Wed, Oct 14, 2015 at 12:41:20PM +, Wang Nan wrote:
This patch provides infrastructure for passing source files to --event
directly using:
# perf record --event bpf-file.c command
This patch does following works:
1) Allow passing '.c' file to '--event'. parse_events_load_bpf() is
expanded to allow caller tell it whether the passed file is source
file or object.
2) llvm__compile_bpf() is called to compile the '.c' file, the result
is saved into memory. Use bpf_object__open_buffer() to load the
in-memory object.
Introduces a bpf-script-example.c so we can manually test it:
# perf record --clang-opt "-DLINUX_VERSION_CODE=0x40200" --event
./bpf-script-example.c sleep 1
Note that '--clang-opt' must put before '--event'.
Futher patches will merge it into a testcase so can be tested automatically.
Signed-off-by: Wang Nan
Signed-off-by: He Kuang
Acked-by: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Signed-off-by: Arnaldo Carvalho de Melo
Link: http://lkml.kernel.org/n/ebpf-6yw9eg0ej3l4jnqhinngk...@git.kernel.org
---
tools/perf/tests/bpf-script-example.c | 44 +++
tools/perf/util/bpf-loader.c | 17 --
tools/perf/util/bpf-loader.h | 5 ++--
tools/perf/util/parse-events.c| 5 ++--
tools/perf/util/parse-events.h| 3 ++-
tools/perf/util/parse-events.l| 3 +++
tools/perf/util/parse-events.y| 15 ++--
7 files changed, 83 insertions(+), 9 deletions(-)
create mode 100644 tools/perf/tests/bpf-script-example.c
diff --git a/tools/perf/tests/bpf-script-example.c
b/tools/perf/tests/bpf-script-example.c
new file mode 100644
index 000..410a70b
--- /dev/null
+++ b/tools/perf/tests/bpf-script-example.c
Shouldn't it be a part of the next patch?
I think putting the sample file in this patch should be better.
In commit message I show a cmdline to utilize scriptlet compiling. If
we put the sample code into next patch, then people get to this point
have to write his/her own script to test scriptlet compiling manually.
Thank you.
Thanks,
Namhyung
@@ -0,0 +1,44 @@
+#ifndef LINUX_VERSION_CODE
+# error Need LINUX_VERSION_CODE
+# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200"
into llvm section of ~/.perfconfig'
+#endif
+#define BPF_ANY 0
+#define BPF_MAP_TYPE_ARRAY 2
+#define BPF_FUNC_map_lookup_elem 1
+#define BPF_FUNC_map_update_elem 2
+
+static void *(*bpf_map_lookup_elem)(void *map, void *key) =
+ (void *) BPF_FUNC_map_lookup_elem;
+static void *(*bpf_map_update_elem)(void *map, void *key, void *value, int
flags) =
+ (void *) BPF_FUNC_map_update_elem;
+
+struct bpf_map_def {
+ unsigned int type;
+ unsigned int key_size;
+ unsigned int value_size;
+ unsigned int max_entries;
+};
+
+#define SEC(NAME) __attribute__((section(NAME), used))
+struct bpf_map_def SEC("maps") flip_table = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(int),
+ .max_entries = 1,
+};
+
+SEC("func=sys_epoll_pwait")
+int bpf_func__sys_epoll_pwait(void *ctx)
+{
+ int ind =0;
+ int *flag = bpf_map_lookup_elem(_table, );
+ int new_flag;
+ if (!flag)
+ return 0;
+ /* flip flag and store back */
+ new_flag = !*flag;
+ bpf_map_update_elem(_table, , _flag, BPF_ANY);
+ return new_flag;
+}
+char _license[] SEC("license") = "GPL";
+int _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index aa784a4..ba6f752 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -12,6 +12,7 @@
#include "bpf-loader.h"
#include "probe-event.h"
#include "probe-finder.h" // for MAX_PROBES
+#include "llvm-utils.h"
#define DEFINE_PRINT_FN(name, level) \
static int libbpf_##name(const char *fmt, ...)\
@@ -33,7 +34,7 @@ struct bpf_prog_priv {
struct perf_probe_event pev;
};
-struct bpf_object *bpf__prepare_load(const char *filename)
+struct bpf_object *bpf__prepare_load(const char *filename, bool source)
{
struct bpf_object *obj;
static bool libbpf_initialized;
@@ -45,7 +46,19 @@ struct bpf_object *bpf__prepare_load(const char *filename)
libbpf_initialized = true;
}
- obj = bpf_object__open(filename);
+ if (source) {
+ int err;
+ void *obj_buf;
+ size_t obj_buf_sz;
+
+ err = llvm__compile_bpf(filename, _buf, _buf_sz);
+ if (err)
+ return ERR_PTR(err);
+ obj = bpf_object__open_buffer(obj_buf, obj_buf_sz, filename);
+ free(obj_buf);
+ } else
[PATCH 00/13] ACPICA: 20150930 Release
The 20150930 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + allyes 2. i386 + allno 3. i386 + default + ACPI_DEBUGGER=y 4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 5. i386 + default + ACPI_DEBUG=n + ACPI=y 6. i386 + default + ACPI=n 7. x86_64 + allyes 8. x86_64 + allno 9. x86_64 + default + ACPI_DEBUGGER=y 10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 11.x86_64 + default + ACPI_DEBUG=n + ACPI=y 12.x86_64 + default + ACPI=n Boot tests are performed as follows: 1. i386 + default + ACPI_DEBUGGER=y 2. x86_64 + default + ACPI_DEBUGGER=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150818 Release): 517 lines After applying (20150930 Release): 517 lines Note there are still 2 ACPICA debugger patches not released during this release cycle, so the debugger IO driver is not released in this cycle. In this series the ACPICA debugger core is compile time enabled as all ACPICA debugger files can be built with ACPI_DEBUGGER=y, but not runtime enabled as there is no invocations calling ACPICA debugger APIs and its required OSls are just stubs. Bob Moore (8): ACPICA: Remove unnecessary conditional compilation. ACPICA: iASL: Add symbolic operator support for Index() operator. ACPICA: Update exception code for "file not found" error ACPICA: Debugger: Update mutexes used for multithreaded debugger ACPICA: Update NFIT table to rename a flags field ACPICA: Improve typechecking, both compile-time and runtime ACPICA: iASL: General cleanup of the file suffix #defines ACPICA: Update version to 20150930 Lv Zheng (5): ACPICA: Linuxize: Export debugger files to Linux ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic ACPI: Enable build of AML interpreter debugger ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode drivers/acpi/Kconfig |9 + drivers/acpi/acpica/Makefile | 16 + drivers/acpi/acpica/acapps.h |2 +- drivers/acpi/acpica/acdebug.h |6 + drivers/acpi/acpica/acglobal.h|6 +- drivers/acpi/acpica/acinterp.h|2 - drivers/acpi/acpica/aclocal.h | 14 +- drivers/acpi/acpica/acnamesp.h|4 - drivers/acpi/acpica/acopcode.h|4 +- drivers/acpi/acpica/acparser.h|4 - drivers/acpi/acpica/acutils.h |2 - drivers/acpi/acpica/amlcode.h | 11 +- drivers/acpi/acpica/dbcmds.c | 1187 +++ drivers/acpi/acpica/dbconvert.c | 484 +++ drivers/acpi/acpica/dbdisply.c| 1108 + drivers/acpi/acpica/dbexec.c | 763 + drivers/acpi/acpica/dbfileio.c| 256 ++ drivers/acpi/acpica/dbhistry.c| 239 ++ drivers/acpi/acpica/dbinput.c | 1267 + drivers/acpi/acpica/dbmethod.c| 369 + drivers/acpi/acpica/dbnames.c | 947 + drivers/acpi/acpica/dbobject.c| 533 drivers/acpi/acpica/dbstats.c | 546 + drivers/acpi/acpica/dbtest.c | 1057 drivers/acpi/acpica/dbutils.c | 457 +++ drivers/acpi/acpica/dbxface.c | 487 +++ drivers/acpi/acpica/evxface.c |2 +- drivers/acpi/acpica/exconvrt.c|1 + drivers/acpi/acpica/exresolv.c|1 - drivers/acpi/acpica/exresop.c |2 + drivers/acpi/acpica/exstore.c | 120 ++- drivers/acpi/acpica/exstoren.c|5 +- drivers/acpi/acpica/nsdump.c |6 - drivers/acpi/acpica/nspredef.c|2 +- drivers/acpi/acpica/pstree.c |2 - drivers/acpi/acpica/psutils.c |2 - drivers/acpi/acpica/rsdump.c |3 - drivers/acpi/acpica/rsutils.c |2 - drivers/acpi/acpica/rsxface.c |4 +- drivers/acpi/acpica/utdecode.c| 21 +- drivers/acpi/acpica/utfileio.c|6 + drivers/acpi/acpica/utinit.c | 15 +- drivers/acpi/acpica/utmutex.c | 21 + drivers/acpi/acpica/utxface.c | 19 +- drivers/acpi/nfit.c
[PATCH 02/13] ACPICA: iASL: Add symbolic operator support for Index() operator.
From: Bob Moore
ACPICA commit fbe67c46830f10c839941f8512cac5bddcb86bd3
Index (, 2) is now supported by [2]
This patch doesn't affect Linux kernel.
Link: https://github.com/acpica/acpica/commit/fbe67c46
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 6f70826..8a66fef 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -848,7 +848,7 @@ struct acpi_parse_state {
#define ACPI_PARSEOP_PARAMLIST 0x02
#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
#define ACPI_PARSEOP_PREDEF_CHECKED 0x08
-#define ACPI_PARSEOP_SPECIAL0x10
+#define ACPI_PARSEOP_CLOSING_PAREN 0x10
#define ACPI_PARSEOP_COMPOUND 0x20
#define ACPI_PARSEOP_ASSIGNMENT 0x40
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/13] ACPICA: Debugger: Update mutexes used for multithreaded debugger
From: Bob Moore
ACPICA commit 6b2701f619040e803313363f516b200e362a9100
Make these mutex objects independent of the deadlock detection mechanism.
This mechanism caused failures with the multithread debugger.
This patch doesn't affect Linux kernel as debugger is currently not fully
functioning in the Linux kernel. And the further debugger cleanups will
take care of handling debugger command signalling correctly instead of
using such kind of mutexes. So it is safe to leave this patch as it is.
Link: https://github.com/acpica/acpica/commit/6b2701f6
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |3 +++
drivers/acpi/acpica/aclocal.h |4 +---
drivers/acpi/acpica/utdecode.c |2 --
drivers/acpi/acpica/utmutex.c | 21 +
include/acpi/platform/acenv.h |6 +++---
5 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 09f37b5..593de41 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -357,6 +357,9 @@ ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc);
ACPI_GLOBAL(u32, acpi_gbl_num_nodes);
ACPI_GLOBAL(u32, acpi_gbl_num_objects);
+ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_ready);
+ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_complete);
+
#endif /* ACPI_DEBUGGER */
/*
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 8a66fef..918f70d 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -83,10 +83,8 @@ union acpi_parse_object;
#define ACPI_MTX_EVENTS 3 /* Data for ACPI events */
#define ACPI_MTX_CACHES 4 /* Internal caches, general
purposes */
#define ACPI_MTX_MEMORY 5 /* Debug memory tracking lists
*/
-#define ACPI_MTX_DEBUG_CMD_COMPLETE 6 /* AML debugger */
-#define ACPI_MTX_DEBUG_CMD_READY7 /* AML debugger */
-#define ACPI_MAX_MUTEX 7
+#define ACPI_MAX_MUTEX 5
#define ACPI_NUM_MUTEX ACPI_MAX_MUTEX+1
/* Lock structure for reader/writer interfaces */
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 988e23b..d452a78 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -407,8 +407,6 @@ static char *acpi_gbl_mutex_names[ACPI_NUM_MUTEX] = {
"ACPI_MTX_Events",
"ACPI_MTX_Caches",
"ACPI_MTX_Memory",
- "ACPI_MTX_CommandComplete",
- "ACPI_MTX_CommandReady"
};
char *acpi_ut_get_mutex_name(u32 mutex_id)
diff --git a/drivers/acpi/acpica/utmutex.c b/drivers/acpi/acpica/utmutex.c
index 37b8b58..ce406e3 100644
--- a/drivers/acpi/acpica/utmutex.c
+++ b/drivers/acpi/acpica/utmutex.c
@@ -108,6 +108,21 @@ acpi_status acpi_ut_mutex_initialize(void)
/* Create the reader/writer lock for namespace access */
status = acpi_ut_create_rw_lock(_gbl_namespace_rw_lock);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+#ifdef ACPI_DEBUGGER
+
+ /* Debugger Support */
+
+ status = acpi_os_create_mutex(_gbl_db_command_ready);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ status = acpi_os_create_mutex(_gbl_db_command_complete);
+#endif
+
return_ACPI_STATUS(status);
}
@@ -147,6 +162,12 @@ void acpi_ut_mutex_terminate(void)
/* Delete the reader/writer lock */
acpi_ut_delete_rw_lock(_gbl_namespace_rw_lock);
+
+#ifdef ACPI_DEBUGGER
+ acpi_os_delete_mutex(acpi_gbl_db_command_ready);
+ acpi_os_delete_mutex(acpi_gbl_db_command_complete);
+#endif
+
return_VOID;
}
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 15ef08c..056f245 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -304,11 +304,11 @@
* multi-threaded if ACPI_APPLICATION is not set.
*/
#ifndef DEBUGGER_THREADING
-#ifdef ACPI_APPLICATION
-#define DEBUGGER_THREADING DEBUGGER_SINGLE_THREADED
+#if !defined (ACPI_APPLICATION) || defined (ACPI_EXEC_APP)
+#define DEBUGGER_THREADING DEBUGGER_MULTI_THREADED
#else
-#define DEBUGGER_THREADING DEBUGGER_MULTI_THREADED
+#define DEBUGGER_THREADING DEBUGGER_SINGLE_THREADED
#endif
#endif /* !DEBUGGER_THREADING */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig
> On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > > > > > > > > > > wrote: > > > > > > > > > > > [Alison Wang] Thanks for your reply. I agreed with you about > > > > > > creating a new multi_v7_lpae_defconfig. In > > > > > > multi_v7_lpae_defconfig, I need to add the following CONFIG_XX > > > > > > to support LS1021A based on > > > > > multi_v7_defconfig. > > > > > > > > > > > > CONFIG_ARM_LPAE=y > > > > > > CONFIG_VMSPLIT_2G=y > > > > > > > > > > Is CONFIG_VMSPLIT_2G=y really needed? > > > > [Alison Wang] I tried to remove CONFIG_VMSPLIT_2G and used the > > > > default CONFIG_VMSPLIT_3G, but kernel could not boot up. It hangs > > > > at " Starting > > > kernel ... ". > > > > > > > > Any suggestion? Thanks. > > > > > > Try enabling DEBUG_LL for your platform to get some debug output, if > > > you still don't get any helpful messages, try also inserting > > > > > > printascii(__func__); > > > > > > statements in the early boot process to see how far you get before the > hang. > > > > > [Alison Wang] I can get to __turn_mmu_on or later, but I could not get > > the print message "Booting Linux on physical CPU 0xf00" in > smp_setup_processor_id(). > > > > I guess something wrong with the initial page tables in > > __create_page_tables, as for CONFIG_VMSPLIT_3G, only PAGE_OFFSET is > changed from 0x8000 to 0xC000. > > BTW, on our platform, TEXT_OFFSET is 0x8000, PHYS_OFFSET is > 0x8000. > > > > Any suggestion? Thanks. > > My first guess is that there is something wrong with your debug_ll > implementation, as that would explain why you can't get anything to the > console after turning on page tables. > > It looks like ls1021a uses lpuart, but I can't even see an implementation > for that in arch/arm/include/debug/. What code do you use for printing? > [Alison Wang] ls1021a uses duart as the default serial port, not lpuart. So 8250/16550 serial driver is used. Let me explain my debug process in detail. When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and get the print message " Booting Linux on physical CPU 0xf00" after "Starting kernel" as below. Starting kernel ... [0.00] Booting Linux on physical CPU 0xf00 . But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " Booting Linux on physical CPU 0xf00". It only hangs at "Starting kernel ...". Moreover, I add some asm code in __turn_mmu_on to print some simple characters, and I could get the print characters when CONFIG_VMSPLIT_3G is used. So I guess there is something wrong with the page tables. Best Regards, Alison Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/13] ACPICA: Improve typechecking, both compile-time and runtime
From: Bob Moore ACPICA commit 8d0f96e2a11a4ceabb2cae4b41e0ce1f4d3786b9 Adds much stricter typechecking in the iASL compiler, and also adds some additional checking in the interpreter. Link: https://github.com/acpica/acpica/commit/8d0f96e2 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/aclocal.h |8 ++- drivers/acpi/acpica/acopcode.h |4 +- drivers/acpi/acpica/amlcode.h | 11 ++-- drivers/acpi/acpica/exconvrt.c |1 + drivers/acpi/acpica/exresolv.c |1 - drivers/acpi/acpica/exresop.c |2 + drivers/acpi/acpica/exstore.c | 120 ++-- drivers/acpi/acpica/exstoren.c |5 +- drivers/acpi/acpica/nspredef.c |2 +- drivers/acpi/acpica/utdecode.c | 19 ++- include/acpi/acexcep.h |7 ++- 11 files changed, 134 insertions(+), 46 deletions(-) diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h index 918f70d..4e41b43 100644 --- a/drivers/acpi/acpica/aclocal.h +++ b/drivers/acpi/acpica/aclocal.h @@ -285,13 +285,17 @@ acpi_status(*acpi_internal_method) (struct acpi_walk_state * walk_state); #define ACPI_BTYPE_BUFFER_FIELD 0x2000 #define ACPI_BTYPE_DDB_HANDLE 0x4000 #define ACPI_BTYPE_DEBUG_OBJECT 0x8000 -#define ACPI_BTYPE_REFERENCE0x0001 +#define ACPI_BTYPE_REFERENCE_OBJECT 0x0001 /* From Index(), ref_of(), etc (type6_opcodes) */ #define ACPI_BTYPE_RESOURCE 0x0002 +#define ACPI_BTYPE_NAMED_REFERENCE 0x0004 /* Generic unresolved Name or Namepath */ #define ACPI_BTYPE_COMPUTE_DATA (ACPI_BTYPE_INTEGER | ACPI_BTYPE_STRING | ACPI_BTYPE_BUFFER) #define ACPI_BTYPE_DATA (ACPI_BTYPE_COMPUTE_DATA | ACPI_BTYPE_PACKAGE) -#define ACPI_BTYPE_DATA_REFERENCE (ACPI_BTYPE_DATA | ACPI_BTYPE_REFERENCE | ACPI_BTYPE_DDB_HANDLE) + + /* Used by Copy, de_ref_of, Store, Printf, Fprintf */ + +#define ACPI_BTYPE_DATA_REFERENCE (ACPI_BTYPE_DATA | ACPI_BTYPE_REFERENCE_OBJECT | ACPI_BTYPE_DDB_HANDLE) #define ACPI_BTYPE_DEVICE_OBJECTS (ACPI_BTYPE_DEVICE | ACPI_BTYPE_THERMAL | ACPI_BTYPE_PROCESSOR) #define ACPI_BTYPE_OBJECTS_AND_REFS 0x0001 /* ARG or LOCAL */ #define ACPI_BTYPE_ALL_OBJECTS 0x diff --git a/drivers/acpi/acpica/acopcode.h b/drivers/acpi/acpica/acopcode.h index fd85ad0..f9acf92 100644 --- a/drivers/acpi/acpica/acopcode.h +++ b/drivers/acpi/acpica/acopcode.h @@ -211,7 +211,7 @@ #define ARGI_ARG4 ARG_NONE #define ARGI_ARG5 ARG_NONE #define ARGI_ARG6 ARG_NONE -#define ARGI_BANK_FIELD_OP ARGI_INVALID_OPCODE +#define ARGI_BANK_FIELD_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_BIT_AND_OP ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_BIT_NAND_OPARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_BIT_NOR_OP ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) @@ -307,7 +307,7 @@ #define ARGI_SLEEP_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_STALL_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_STATICSTRING_OPARGI_INVALID_OPCODE -#define ARGI_STORE_OP ARGI_LIST2 (ARGI_DATAREFOBJ, ARGI_TARGETREF) +#define ARGI_STORE_OP ARGI_LIST2 (ARGI_DATAREFOBJ, ARGI_STORE_TARGET) #define ARGI_STRING_OP ARGI_INVALID_OPCODE #define ARGI_SUBTRACT_OPARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_THERMAL_ZONE_OPARGI_INVALID_OPCODE diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h index be9fd00..883f20c 100644 --- a/drivers/acpi/acpica/amlcode.h +++ b/drivers/acpi/acpica/amlcode.h @@ -277,14 +277,15 @@ #define ARGI_TARGETREF 0x0F /* Target, subject to implicit conversion */ #define ARGI_FIXED_TARGET 0x10 /* Target, no implicit conversion */ #define ARGI_SIMPLE_TARGET 0x11 /* Name, Local, Arg -- no implicit conversion */ +#define ARGI_STORE_TARGET 0x12 /* Target for store is TARGETREF + package objects */ /* Multiple/complex types */ -#define ARGI_DATAOBJECT 0x12 /* Buffer, String, package or reference to a node - Used only by size_of operator */ -#define ARGI_COMPLEXOBJ 0x13 /* Buffer, String, or package (Used by INDEX op only) */ -#define ARGI_REF_OR_STRING 0x14 /* Reference or String (Used by DEREFOF op only) */ -#define ARGI_REGION_OR_BUFFER 0x15 /* Used by LOAD op only */ -#define ARGI_DATAREFOBJ 0x16 +#define ARGI_DATAOBJECT 0x13 /* Buffer, String, package or reference to a node - Used only by size_of operator */ +#define ARGI_COMPLEXOBJ 0x14 /*
Re: [PATCH v2] watchdog: Compile possible drivers with COMPILE_TEST
2015-10-15 7:40 GMT+09:00 Guenter Roeck : > On 10/14/2015 03:11 PM, Luis de Bethencourt wrote: >> >> On 14/10/15 22:35, Guenter Roeck wrote: >>> >>> On 10/14/2015 11:55 AM, Luis de Bethencourt wrote: These drivers have depends that aren't build dependencies, so it's a good idea to allow these drivers to always be built when the COMPILE_TEST option is enabled. That way, the drivers can be built with a config generated by make allyesconfig and check if a patch would break the build. Signed-off-by: Luis de Bethencourt >>> >>> >>> What architectures have you actually tested this for ? >>> >>> Guenter >>> >> >> I've compiled it in x86 and then I tried ARM >> (with CROSS_COMPILE="ccache arm-linux-gnueabihf-" ARCH=arm) >> >> But ARM kept failing due to other drivers, first Lustre then an Ethernet >> driver (I40E), and more. >> > arm:allmodconfig should build fine. Either case, you can always run "make > -i" > to ignore errors, to ensure that you at least don't introduce new problems. > >> Is there a better way of doing this? >> > Sure, at least run allmodconfig for _all_ architectures, or at least > for the major architectures. At least 32-bit and 64-bit of mixtures. x86 and ARMv7 is not enough. For example something like: $ apt-get install build-essential gcc-4.8-multilib gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu libc6-dev-arm64-cross gcc-powerpc-linux-gnu (PPC can be built for 32- and 64-bit) And you can get MIPS from CodeSourcery. Toggling COMPILE_TEST with this may break someone's else allyesconfig. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re[2]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
Donald, Shane,
Thanks for reporting this.
> > I also tried suggested /vmlinuz-4.3.0-rc3 parameter in grub:
> > "cpu_init_udelay=1"
> > which did not help getting missing CPU back online.
right, if the issue is caused by the patch below,
that cmdline will not help.
> Did you try reverting the "x86/smpboot: Remove APIC.wait_for_init_deassert
> and atomic init_deasserted" patch?
Yes, please let me know if reverting that patch helps you too.
You have similar hardware:
Shane:
smpboot: CPU0: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (fam: 06, model:
0f, stepping: 06)
Donald:
CPU : Intel Core 2 CPU 6600 @ 2.4GHz
I think I can get ahold of a core2 6xxx box tomorrow.
Please send me your .config directly, and I'll see if I can reproduce the issue.
thanks,
-Len
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 09/13] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic
ACPICA commit 0dd68e16274cd38224aa4781eddc57dc2cbaa108
The quit/exit commands shouldn't invoke acpi_terminate_debugger() and
acpi_terminate() right in the user command loop, because when the debugger
exits, the kernel ACPI subsystem shouldn't be terminated (acpi_terminate())
and the debugger should only be terminated by its users
(acpi_terminate_debugger()) rather than being terminated itself. Leaving such
invocations causes kernel panic when the debugger is shipped in the Linux
kernel.
This patch fixes this issue. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/0dd68e16
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |3 ++-
drivers/acpi/acpica/dbinput.c | 16
drivers/acpi/acpica/dbxface.c | 20
drivers/acpi/acpica/utinit.c |2 --
drivers/acpi/acpica/utxface.c |4
5 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 593de41..d82249c 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -324,7 +324,6 @@ ACPI_GLOBAL(struct acpi_external_file *,
acpi_gbl_external_file_list);
#ifdef ACPI_DEBUGGER
-ACPI_INIT_GLOBAL(u8, acpi_gbl_db_terminate_threads, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_abort_method, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE);
@@ -336,6 +335,8 @@ ACPI_GLOBAL(char *, acpi_gbl_db_filename);
ACPI_GLOBAL(u32, acpi_gbl_db_debug_level);
ACPI_GLOBAL(u32, acpi_gbl_db_console_debug_level);
ACPI_GLOBAL(struct acpi_namespace_node *, acpi_gbl_db_scope_node);
+ACPI_GLOBAL(u8, acpi_gbl_db_terminate_loop);
+ACPI_GLOBAL(u8, acpi_gbl_db_threads_terminated);
ACPI_GLOBAL(char *, acpi_gbl_db_args[ACPI_DEBUGGER_MAX_ARGS]);
ACPI_GLOBAL(acpi_object_type, acpi_gbl_db_arg_types[ACPI_DEBUGGER_MAX_ARGS]);
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index 7f1b6ec..f8cddd6 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -694,7 +694,7 @@ acpi_db_command_dispatch(char *input_buffer,
/* If acpi_terminate has been called, terminate this thread */
- if (acpi_gbl_db_terminate_threads) {
+ if (acpi_gbl_db_terminate_loop) {
return (AE_CTRL_TERMINATE);
}
@@ -1116,7 +1116,7 @@ acpi_db_command_dispatch(char *input_buffer,
#ifdef ACPI_APPLICATION
acpi_db_close_debug_file();
#endif
- acpi_gbl_db_terminate_threads = TRUE;
+ acpi_gbl_db_terminate_loop = TRUE;
return (AE_CTRL_TERMINATE);
case CMD_NOT_FOUND:
@@ -1166,6 +1166,7 @@ void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void
*context)
acpi_os_release_mutex(acpi_gbl_db_command_complete);
}
+ acpi_gbl_db_threads_terminated = TRUE;
}
/***
@@ -1212,7 +1213,7 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
/* TBD: [Restructure] Need a separate command line buffer for step mode
*/
- while (!acpi_gbl_db_terminate_threads) {
+ while (!acpi_gbl_db_terminate_loop) {
/* Force output to console until a command is entered */
@@ -1261,14 +1262,5 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
}
}
- /* Shut down the debugger */
-
- acpi_terminate_debugger();
-
- /*
-* Only this thread (the original thread) should actually terminate the
-* subsystem, because all the semaphores are deleted during termination
-*/
- status = acpi_terminate();
return (status);
}
diff --git a/drivers/acpi/acpica/dbxface.c b/drivers/acpi/acpica/dbxface.c
index 26023bd..bef5f4e 100644
--- a/drivers/acpi/acpica/dbxface.c
+++ b/drivers/acpi/acpica/dbxface.c
@@ -401,6 +401,10 @@ acpi_status acpi_initialize_debugger(void)
acpi_gbl_db_scope_buf[1] = 0;
acpi_gbl_db_scope_node = acpi_gbl_root_node;
+ /* Initialize user commands loop */
+
+ acpi_gbl_db_terminate_loop = FALSE;
+
/*
* If configured for multi-thread support, the debug executor runs in
* a separate thread so that the front end can be in another address
@@ -426,11 +430,13 @@ acpi_status acpi_initialize_debugger(void)
/* Create the debug execution thread to execute commands */
+ acpi_gbl_db_threads_terminated = FALSE;
status = acpi_os_execute(OSL_DEBUGGER_THREAD,
acpi_db_execute_thread, NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"Could not start debugger thread"));
+ acpi_gbl_db_threads_terminated = TRUE;
return_ACPI_STATUS(status);
Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
Hi Rich,
On 14/10/15 01:49, Rich Felker wrote:
> On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote:
>> Hi Rich,
>>
>> On 09/10/15 02:38, Rich Felker wrote:
>>> From: Rich Felker
>>>
>>> The ELF binary loader in binfmt_elf.c requires an MMU, making it
>>> impossible to use regular ELF binaries on NOMMU archs. However, the
>>> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
>>> for plain ELF, which requires constant displacements between LOAD
>>> segments, since it already supports FDPIC ELF files flagged as needing
>>> constant displacement.
>>>
>>> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
>>> on NOMMU archs. They are treated identically to FDPIC ELF files with
>>> the constant-displacement flag bit set, except for personality, which
>>> must match the ABI of the program being loaded; the PER_LINUX_FDPIC
>>> personality controls how the kernel interprets function pointers
>>> passed to sigaction.
>>>
>>> Files that do not set a stack size requirement explicitly are given a
>>> default stack size (matching the amount of committed stack the normal
>>> ELF loader for MMU archs would give them) rather than being rejected;
>>> this is necessary because plain ELF files generally do not declare
>>> stack requirements in theit program headers.
>>>
>>> Only ET_DYN (PIE) format ELF files are supported, since loading at a
>>> fixed virtual address is not possible on NOMMU.
>>>
>>> Signed-off-by: Rich Felker
>>
>> I have no problem with this, so from me:
>>
>> Acked-by: Greg Ungerer
>
> Thanks!
>
>>> ---
>>>
>>> This patch was developed and tested on J2 (SH2-compatible) but should
>>> be usable immediately on all archs where binfmt_elf_fdpic is
>>> available. Moreover, by providing dummy definitions of the
>>> elf_check_fdpic() and elf_check_const_displacement() macros for archs
>>> which lack an FDPIC ABI, it should be possible to enable building of
>>> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
>>> binary support, but I have not yet tested this.
>>
>> There is a couple of other details that will currently stop this from
>> working on other arches too.
>>
>> .. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
>> .. arch specific mm_context_t may not have members
>> ‘interp_fdpic_loadmap' or 'exec_fdpic_loadmap'
>>
>> Should be easy to fix those.
>
> I see. For archs that lack an FDPIC ABI, I'm not sure it makes sense
> to add these things unless/until someone developes an FDPIC ABI. Would
Ok. I was looking at it from the point of view of supoporting ELF
on m68k/coldfire, that doesn't currently support FDPIC. So bypassing
FDPIC support completely.
> it instead make sense to add a new kconfig switch
> CONFIG_BINFMT_ELF_NOMMU ("NOMMU ELF loader") that's implied-on by
> CONFIG_BINFMT_ELF_FDPIC but that can also be enabled independently on
> archs where CONFIG_BINFMT_ELF_FDPIC is not available?
Yes that may be the only answer here.
> Right now these are just ideas. Unless there's a quick and easy
> decision to be made, I'd like it if we could move forward with the
> current patch (which only offers the feature on archs where
> CONFIG_BINFMT_ELF_FDPIC is already available) first and continue to
> explore options for making this available to other archs separately.
Oh, yes. No problem with that. Looks like Andrew has picked it
up. So all good there.
>> It would be good to get some testing and verification on other
>> fdpic supported arches (frv or blackfin or microblaze for example).
>
> I wasn't aware Microblaze had an FDPIC ABI; are you sure it does?
Sorry, my mistake. No microblaze FDPIC as far as I know.
Regards
Greg
> Testing to make sure these aren't broken by the patch shouldn't be
> hard to do; I'll start looking into getting a setup for it or finding
> someone who has one. If you want to also test non-FDPIC ELF binaries,
> I think just using the ELF output of a bFLT toolchain without running
> elf2flt may work as a test case, but I'm not sure. Alternatively, any
> FDPIC binary linked with -pie that doesn't use signals can run as a
> non-FDPIC one just by clearing the FDPIC bit in the header.
>
> Rich
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/13] ACPICA: Update version to 20150930
From: Bob Moore ACPICA commit e9c75ca267262326e80d49a290e8387a5963e2d2 Version 20150930. Link: https://github.com/acpica/acpica/commit/e9c75ca2 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 89a4018..b9ee2fb 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150818 +#define ACPI_CA_VERSION 0x20150930 #include #include -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/13] ACPI: Enable build of AML interpreter debugger
This patch enables ACPICA debugger files using a configurable CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that was originally masked as ACPI_FUTURE_USAGE now gets unmasked. Necessary OSL stubs are also added in this patch: 1. acpi_os_readable(): This should be arch specific in Linux, while this patch doesn't introduce real implementation and a complex mechanism to allow architecture specific acpi_os_readable() to be implemented to validate the address. It may be done by future commits. 2. acpi_os_get_line(): This is used to obtain debugger command input. This patch only introduces a simple KDB concept example in it and the example should be co-working with the code implemented in acpi_os_printf(). Since this KDB example won't be compiled unless ENABLE_DEBUGGER is defined and it seems Linux has already stopped to use ENABLE_DEBUGGER, thus do not expect it can work properly. This patch also cleans up all other ACPI_FUTURE_USAGE surroundings accordingly. 1. Since linkage error can be automatically detected, declaration in the headers needn't be surrounded by ACPI_FUTURE_USAGE. So only the following separate exported fuction bodies are masked by this macro (other exported fucntions may have already been masked at entire module level via drivers/acpi/acpica/Makefile): acpi_install_exception_handler() acpi_subsystem_status() acpi_get_system_info() acpi_get_statistics() acpi_install_initialization_handler() 2. Since strip can automatically zap the no-user functions, functions that are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by ACPI_FUTURE_USAGE. So the following function which is not used by Linux kernel now won't get surrounded by this macro: acpi_ps_get_name() Signed-off-by: Lv Zheng --- drivers/acpi/Kconfig |9 + drivers/acpi/acpica/Makefile | 16 drivers/acpi/acpica/acinterp.h|2 -- drivers/acpi/acpica/acnamesp.h|4 drivers/acpi/acpica/acparser.h|4 drivers/acpi/acpica/acutils.h |2 -- drivers/acpi/acpica/evxface.c |2 +- drivers/acpi/acpica/nsdump.c |6 -- drivers/acpi/acpica/pstree.c |2 -- drivers/acpi/acpica/psutils.c |2 -- drivers/acpi/acpica/rsutils.c |2 -- drivers/acpi/acpica/rsxface.c |4 ++-- drivers/acpi/acpica/utxface.c |2 +- drivers/acpi/osl.c| 11 +++ include/acpi/acpixf.h | 10 -- include/acpi/platform/aclinux.h |7 +-- include/acpi/platform/aclinuxex.h |5 + 17 files changed, 42 insertions(+), 48 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 5d1015c..706c2e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -57,6 +57,15 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT config ACPI_CCA_REQUIRED bool +config ACPI_DEBUGGER + bool "In-kernel debugger (EXPERIMENTAL)" + select ACPI_DEBUG + help + Enable in-kernel debugging facilities: statistics, internal + object dump, single step control method execution. + This is still under development, currently enabling this only + results in the compilation of the ACPICA debugger files. + config ACPI_SLEEP bool depends on SUSPEND || HIBERNATION diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile index fedcc16..a57f019 100644 --- a/drivers/acpi/acpica/Makefile +++ b/drivers/acpi/acpica/Makefile @@ -178,7 +178,23 @@ acpi-y += \ utxferror.o \ utxfmutex.o +acpi-$(CONFIG_ACPI_DEBUGGER) +=\ + dbcmds.o\ + dbconvert.o \ + dbdisply.o \ + dbexec.o\ + dbhistry.o \ + dbinput.o \ + dbmethod.o \ + dbnames.o \ + dbobject.o \ + dbstats.o \ + dbutils.o \ + dbxface.o + acpi-$(ACPI_FUTURE_USAGE) += \ + dbfileio.o \ + dbtest.o\ utcache.o \ utfileio.o \ utprint.o \ diff --git a/drivers/acpi/acpica/acinterp.h b/drivers/acpi/acpica/acinterp.h index e820ed8..e9e936e 100644 --- a/drivers/acpi/acpica/acinterp.h +++ b/drivers/acpi/acpica/acinterp.h @@ -397,12 +397,10 @@ void acpi_ex_dump_operands(union acpi_operand_object **operands, const char *opcode_name, u32 num_opcodes); -#ifdef ACPI_FUTURE_USAGE void acpi_ex_dump_object_descriptor(union acpi_operand_object *object, u32 flags); void acpi_ex_dump_namespace_node(struct acpi_namespace_node *node, u32 flags); -#endif /* ACPI_FUTURE_USAGE */ /* * exnames - AML namestring support diff --git a/drivers/acpi/acpica/acnamesp.h
[PATCH 12/13] ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode
ACPICA commit 35273add90da19cd8790fdb5735f52e3c9861684
When single step execution is not ended, executing another control methods
leads to dead locks around interpreter lock/namespace lock/method
serialization lock. So we should only allow one execution from the debugger
at same time. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/35273add
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dbexec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/acpi/acpica/dbexec.c b/drivers/acpi/acpica/dbexec.c
index 8eef298..9da2daa 100644
--- a/drivers/acpi/acpica/dbexec.c
+++ b/drivers/acpi/acpica/dbexec.c
@@ -370,7 +370,17 @@ acpi_db_execute(char *name, char **args, acpi_object_type
* types, u32 flags)
#ifdef ACPI_DEBUG_OUTPUT
u32 previous_allocations;
u32 allocations;
+#endif
+ /*
+* Allow one execution to be performed by debugger or single step
+* execution will be dead locked by the interpreter mutexes.
+*/
+ if (acpi_gbl_method_executing) {
+ acpi_os_printf("Only one debugger execution is allowed.\n");
+ return;
+ }
+#ifdef ACPI_DEBUG_OUTPUT
/* Memory allocation tracking */
previous_allocations = acpi_db_get_outstanding_allocations();
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/13] ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic
ACPICA commit 7e823714911480be47e310fb1b3590d289b9fd99
Segmentation fault can be seen for executing the "terminate" command. This
is because acpi_ut_subsystem_shutdown() is errnously called multiple times.
This patch cleans up acpi_ut_subsystem_shutdown() logics to fix this
issue. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/7e823714
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dbinput.c |3 ++-
drivers/acpi/acpica/utinit.c | 13 +
drivers/acpi/acpica/utxface.c | 13 -
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index f8cddd6..0480254 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -1074,6 +1074,7 @@ acpi_db_command_dispatch(char *input_buffer,
* re-creating the semaphores!
*/
+ acpi_gbl_db_terminate_loop = TRUE;
/* acpi_initialize (NULL); */
break;
@@ -1151,7 +1152,7 @@ void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void
*context)
acpi_status status = AE_OK;
acpi_status Mstatus;
- while (status != AE_CTRL_TERMINATE) {
+ while (status != AE_CTRL_TERMINATE && !acpi_gbl_db_terminate_loop) {
acpi_gbl_method_executing = FALSE;
acpi_gbl_step_to_next_call = FALSE;
diff --git a/drivers/acpi/acpica/utinit.c b/drivers/acpi/acpica/utinit.c
index d8699df..ccd0745 100644
--- a/drivers/acpi/acpica/utinit.c
+++ b/drivers/acpi/acpica/utinit.c
@@ -282,6 +282,19 @@ void acpi_ut_subsystem_shutdown(void)
{
ACPI_FUNCTION_TRACE(ut_subsystem_shutdown);
+ /* Just exit if subsystem is already shutdown */
+
+ if (acpi_gbl_shutdown) {
+ ACPI_ERROR((AE_INFO, "ACPI Subsystem is already terminated"));
+ return_VOID;
+ }
+
+ /* Subsystem appears active, go ahead and shut it down */
+
+ acpi_gbl_shutdown = TRUE;
+ acpi_gbl_startup_flags = 0;
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Shutting down ACPI Subsystem\n"));
+
#ifndef ACPI_ASL_COMPILER
/* Close the acpi_event Handling */
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index f183daf..a6b0eb0 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -67,19 +67,6 @@ acpi_status __init acpi_terminate(void)
ACPI_FUNCTION_TRACE(acpi_terminate);
- /* Just exit if subsystem is already shutdown */
-
- if (acpi_gbl_shutdown) {
- ACPI_ERROR((AE_INFO, "ACPI Subsystem is already terminated"));
- return_ACPI_STATUS(AE_OK);
- }
-
- /* Subsystem appears active, go ahead and shut it down */
-
- acpi_gbl_shutdown = TRUE;
- acpi_gbl_startup_flags = 0;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Shutting down ACPI Subsystem\n"));
-
/* Shutdown and free all resources */
acpi_ut_subsystem_shutdown();
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/13] ACPICA: Update exception code for "file not found" error
From: Bob Moore
ACPICA commit ac1564c26d239348ef13455f61d5616f3961ff43
Used by the ACPICA applications.
This patch is a bit broken due to non-portable inclusion as on
some platforms, there is no such a header file for their lib-c exports.
Fortunately, Linux doesn't compile utfileio.c for either the kernel
space ACPICA core (drivers/acpi/acpica) or the userspace ACPICA tools
(tools/power/acpi) for now, so it's safe to leave this patch as it is.
Link: https://github.com/acpica/acpica/commit/ac1564c2
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/utfileio.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index 75a94f5..d435b7b 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -45,6 +45,7 @@
#include "accommon.h"
#include "actables.h"
#include "acapps.h"
+#include "errno.h"
#ifdef ACPI_ASL_COMPILER
#include "aslcompiler.h"
@@ -301,6 +302,11 @@ acpi_ut_read_table_from_file(char *filename, struct
acpi_table_header ** table)
file = fopen(filename, "rb");
if (!file) {
perror("Could not open input file");
+
+ if (errno == ENOENT) {
+ return (AE_NOT_EXIST);
+ }
+
return (status);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/13] ACPICA: Update NFIT table to rename a flags field
From: Bob Moore
ACPICA commit 534deab97fb416a13bfede15c538e2c9eac9384a
Updated one of the memory subtable flags to clarify.
Link: https://github.com/acpica/acpica/commit/534deab9
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/nfit.c |6 +++---
drivers/acpi/nfit.h |2 +-
include/acpi/actbl1.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index c1b8d03..bc18aa2 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -706,7 +706,7 @@ static ssize_t flags_show(struct device *dev,
flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "",
flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "",
flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "",
- flags & ACPI_NFIT_MEM_ARMED ? "not_armed " : "",
+ flags & ACPI_NFIT_MEM_NOT_ARMED ? "not_armed " : "",
flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "");
}
static DEVICE_ATTR_RO(flags);
@@ -815,7 +815,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc
*acpi_desc)
flags |= NDD_ALIASING;
mem_flags = __to_nfit_memdev(nfit_mem)->flags;
- if (mem_flags & ACPI_NFIT_MEM_ARMED)
+ if (mem_flags & ACPI_NFIT_MEM_NOT_ARMED)
flags |= NDD_UNARMED;
rc = acpi_nfit_add_dimm(acpi_desc, nfit_mem, device_handle);
@@ -839,7 +839,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc
*acpi_desc)
mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? " save_fail" : "",
mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? " restore_fail":"",
mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? " flush_fail" : "",
- mem_flags & ACPI_NFIT_MEM_ARMED ? " not_armed" : "");
+ mem_flags & ACPI_NFIT_MEM_NOT_ARMED ? " not_armed" : "");
}
diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h
index 7e74015..329a1eb 100644
--- a/drivers/acpi/nfit.h
+++ b/drivers/acpi/nfit.h
@@ -24,7 +24,7 @@
#define UUID_NFIT_DIMM "4309ac30-0d11-11e4-9191-0800200c9a66"
#define ACPI_NFIT_MEM_FAILED_MASK (ACPI_NFIT_MEM_SAVE_FAILED \
| ACPI_NFIT_MEM_RESTORE_FAILED | ACPI_NFIT_MEM_FLUSH_FAILED \
- | ACPI_NFIT_MEM_ARMED)
+ | ACPI_NFIT_MEM_NOT_ARMED)
enum nfit_uuids {
NFIT_SPA_VOLATILE,
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index fcd5709..1bb979e 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -1012,7 +1012,7 @@ struct acpi_nfit_memory_map {
#define ACPI_NFIT_MEM_SAVE_FAILED (1)/* 00: Last SAVE to Memory
Device failed */
#define ACPI_NFIT_MEM_RESTORE_FAILED(1<<1) /* 01: Last RESTORE from Memory
Device failed */
#define ACPI_NFIT_MEM_FLUSH_FAILED (1<<2) /* 02: Platform flush failed */
-#define ACPI_NFIT_MEM_ARMED (1<<3) /* 03: Memory Device observed
to be not armed */
+#define ACPI_NFIT_MEM_NOT_ARMED (1<<3) /* 03: Memory Device is not
armed */
#define ACPI_NFIT_MEM_HEALTH_OBSERVED (1<<4) /* 04: Memory Device observed
SMART/health events */
#define ACPI_NFIT_MEM_HEALTH_ENABLED(1<<5) /* 05: SMART/health events
enabled */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/13] ACPICA: Remove unnecessary conditional compilation.
From: Bob Moore
ACPICA commit eea1f0e561893b6d6417913b2d224082fe3a0a5e
Remove use of ACPI_DEBUGGER and ACPI_DISASSEMBLER where these
defines are used around entire modules.
Note: This type of code also causes problems with IDEs.
Link: https://github.com/acpica/acpica/commit/eea1f0e5
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acdebug.h |6 ++
drivers/acpi/acpica/rsdump.c |3 ---
include/acpi/platform/acenv.h |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index eb2e926..c928ba4 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -44,6 +44,12 @@
#ifndef __ACDEBUG_H__
#define __ACDEBUG_H__
+/* The debugger is used in conjunction with the disassembler most of time */
+
+#ifdef ACPI_DISASSEMBLER
+#include "acdisasm.h"
+#endif
+
#define ACPI_DEBUG_BUFFER_SIZE 0x4000 /* 16K buffer for return objects */
struct acpi_db_command_info {
diff --git a/drivers/acpi/acpica/rsdump.c b/drivers/acpi/acpica/rsdump.c
index c428bb3..2a09288 100644
--- a/drivers/acpi/acpica/rsdump.c
+++ b/drivers/acpi/acpica/rsdump.c
@@ -51,7 +51,6 @@ ACPI_MODULE_NAME("rsdump")
/*
* All functions in this module are used by the AML Debugger only
*/
-#if defined(ACPI_DEBUGGER)
/* Local prototypes */
static void acpi_rs_out_string(char *title, char *value);
@@ -565,5 +564,3 @@ static void acpi_rs_dump_word_list(u16 length, u16 *data)
acpi_os_printf("%25s%2.2X : %4.4X\n", "Word", i, data[i]);
}
}
-
-#endif
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index ec00e2b..15ef08c 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -142,7 +142,7 @@
#ifdef ACPI_LIBRARY
#define ACPI_USE_LOCAL_CACHE
-#define ACPI_FUTURE_USAGE
+#define ACPI_FULL_DEBUG
#endif
/* Common for all ACPICA applications */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/13] ACPICA: iASL: General cleanup of the file suffix #defines
From: Bob Moore
ACPICA commit bed456ed2976bdaafdef406b982fdf6c539befc0
Removed some extraneous defines, reordered others.
Link: https://github.com/acpica/acpica/commit/bed456ed
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acapps.h |2 +-
tools/power/acpi/tools/acpidump/apfiles.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/acapps.h b/drivers/acpi/acpica/acapps.h
index e9f0833..e4cc48f 100644
--- a/drivers/acpi/acpica/acapps.h
+++ b/drivers/acpi/acpica/acapps.h
@@ -88,7 +88,7 @@
acpi_os_printf (" %-18s%s\n", name, description);
#define FILE_SUFFIX_DISASSEMBLY "dsl"
-#define ACPI_TABLE_FILE_SUFFIX ".dat"
+#define FILE_SUFFIX_BINARY_TABLE".dat" /* Needs the dot */
/*
* getopt
diff --git a/tools/power/acpi/tools/acpidump/apfiles.c
b/tools/power/acpi/tools/acpidump/apfiles.c
index a37f970..a1c62de 100644
--- a/tools/power/acpi/tools/acpidump/apfiles.c
+++ b/tools/power/acpi/tools/acpidump/apfiles.c
@@ -150,7 +150,7 @@ int ap_write_to_binary_file(struct acpi_table_header
*table, u32 instance)
strcat(filename, instance_str);
}
- strcat(filename, ACPI_TABLE_FILE_SUFFIX);
+ strcat(filename, FILE_SUFFIX_BINARY_TABLE);
if (gbl_verbose_mode) {
acpi_log_error
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_irq.c
between commit:
fd8f507c0de9 ("drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.")
from the drm-intel tree and commit:
88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_irq.c
index e24378ee7eda,bc732eb52b50..
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@@ -710,11 -611,12 +710,11 @@@ static u32 i915_get_vblank_counter(stru
return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
}
- static u32 g4x_get_vblank_counter(struct drm_device *dev, int pipe)
-static u32 gm45_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
++static u32 g4x_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- int reg = PIPE_FRMCOUNT_GM45(pipe);
- return I915_READ(reg);
+ return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
}
/* raw reads, only for fast reads of display block, no need for forcewake
etc. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 8/8] zram: enable contextless compression alg in zram
On (10/14/15 16:38), Joonsoo Kim wrote:
[..]
> @@ -352,6 +352,7 @@ static ssize_t comp_algorithm_show(struct device *dev,
> size_t sz;
> struct zram *zram = dev_to_zram(dev);
>
> + deprecated_attr_warn("comp_algorithm");
> down_read(>init_lock);
> sz = zcomp_available_show(zram->compressor, buf);
> up_read(>init_lock);
oh, one more thing.
deprecated_attr_warn() should come with
`Documentation/ABI/obsolete/sysfs-block-zram' update.
something like:
diff --git a/Documentation/ABI/obsolete/sysfs-block-zram
b/Documentation/ABI/obsolete/sysfs-block-zram
index 720ea92..ad5b59d 100644
--- a/Documentation/ABI/obsolete/sysfs-block-zram
+++ b/Documentation/ABI/obsolete/sysfs-block-zram
@@ -117,3 +117,14 @@ Description:
Downgraded to write-only node: so it's possible to set new
value only; its current value is stored in zram/mm_stat
node.
+
+What: /sys/block/zram/comp_algorithm
+Date: XXX
+Contact: XXX
+Description:
+ The comp_algorithm file is read/write and provides information
+ on available, currently selected compression algorithm (read
+ operation) and lets one to change the compression algorithm
+ (write operation).
+ Downgraded to write-only node: use `/proc/crypto' to get the
+ list of supported compression algorithms.
---
And I guess Cc `Jonathan Corbet ' (doc maintainer) and
'linux-...@vger.kernel.org' will be the right thing to do here.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled
2015-10-15 4:08 GMT+09:00 Javier Martinez Canillas : > Hello Stephen, > > On 10/14/2015 08:38 PM, Stephen Boyd wrote: >> On 10/13, Javier Martinez Canillas wrote: >>> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig >>> index 1530c9352a76..fc50b6264bed 100644 >>> --- a/drivers/clk/versatile/Kconfig >>> +++ b/drivers/clk/versatile/Kconfig >>> @@ -1,6 +1,6 @@ >>> config COMMON_CLK_VERSATILE >>> bool "Clock driver for ARM Reference designs" >>> -depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 >>> +depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 >>> || COMPILE_TEST >> >> Have you compiled these drivers on an architecture that doesn't >> have IOMEM? Perhaps tile or um? I'm all for more build coverage, >> but it's not always as simple as just sprinkling some >> COMPILE_TEST around the Kconfigs. >> > > No, I only build tested on arm32 and x86. The 0-day bot haven't reported a > build error yet and I didn't see any platform dependent code in the drivers. I see you guys with Luis are adding a lot of COMPILE_TEST. But building only on these two architectures *is not enough*. Run at least armv8, PPC and the x86_64. MIPS would be nice as well (I use the CodeSourcery's MIPS). All of these (ARM64, X86_64, PPC, MIPS) can be easily installed on typical debian-like Linux distro. Really easily. By adding this non-tested build coverage you can actually fail some other architecture's allyesconfig/allmodconfig builds. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwrng: stm32 - Fix build with CONFIG_PM
On Wed, Oct 14, 2015 at 05:04:55PM +0100, Daniel Thompson wrote:
> Commit c6a97c42e399 ("hwrng: stm32 - add support for STM32 HW RNG")
> was inadequately tested (actually it was tested quite hard so
> incompetent would be a better description that inadequate) and does
> not compile on platforms with CONFIG_PM set.
>
> Fix this.
>
> Signed-off-by: Daniel Thompson
Patch applied. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the crypto tree
On Thu, Oct 15, 2015 at 12:37:00PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
>
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_runtime_suspend':
> drivers/char/hw_random/stm32-rng.c:163:51: error: 'pdev' undeclared (first
> use in this function)
> struct stm32_rng_private *priv = dev_get_drvdata(pdev);
>^
> drivers/char/hw_random/stm32-rng.c:163:51: note: each undeclared identifier
> is reported only once for each function it appears in
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_runtime_resume':
> drivers/char/hw_random/stm32-rng.c:172:51: error: 'pdev' undeclared (first
> use in this function)
> struct stm32_rng_private *priv = dev_get_drvdata(pdev);
>^
>
> Caused by commit
>
> c6a97c42e399 ("Add support for STMicroelectronics STM32 random number
> generator.")
>
> I have used the crypto tree from next-20151013 for today.
Thanks Stephen! I've just pushed out a fix for this.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 08/10] spi: rockchip: modify DMA max burst to 1
From: Addy Ke
Generic dma controller on Rockchips' platform cannot support
DMAFLUSHP instruction which make dma to flush the req of non-aligned
or non-multiple of what we need. That will cause an unrecoverable
dma bus error. The saftest way is to set dma max burst to 1.
Signed-off-by: Addy ke
Fixes: 64e36824b32b06 ("spi/rockchip: add driver for Rockchip...")
Signed-off-by: Shawn Lin
cc: Heiko Stuebner
cc: Olof Johansson
cc: Doug Anderson
cc: Sonny Rao
Acked-by: Mark Brown
---
Changes in v6:
- remove quirks and get dma caps in order to limit burst
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
drivers/spi/spi-rockchip.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 79a8bc4..aa9561f 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -199,6 +199,7 @@ struct rockchip_spi {
struct sg_table rx_sg;
struct rockchip_spi_dma_data dma_rx;
struct rockchip_spi_dma_data dma_tx;
+ struct dma_slave_caps dma_caps;
};
static inline void spi_enable_chip(struct rockchip_spi *rs, int enable)
@@ -449,7 +450,10 @@ static void rockchip_spi_prepare_dma(struct rockchip_spi
*rs)
rxconf.direction = rs->dma_rx.direction;
rxconf.src_addr = rs->dma_rx.addr;
rxconf.src_addr_width = rs->n_bytes;
- rxconf.src_maxburst = rs->n_bytes;
+ if (rs->dma_caps.max_burst > 4)
+ rxconf.src_maxburst = 4;
+ else
+ rxconf.src_maxburst = 1;
dmaengine_slave_config(rs->dma_rx.ch, );
rxdesc = dmaengine_prep_slave_sg(
@@ -466,7 +470,10 @@ static void rockchip_spi_prepare_dma(struct rockchip_spi
*rs)
txconf.direction = rs->dma_tx.direction;
txconf.dst_addr = rs->dma_tx.addr;
txconf.dst_addr_width = rs->n_bytes;
- txconf.dst_maxburst = rs->n_bytes;
+ if (rs->dma_caps.max_burst > 4)
+ txconf.dst_maxburst = 4;
+ else
+ txconf.dst_maxburst = 1;
dmaengine_slave_config(rs->dma_tx.ch, );
txdesc = dmaengine_prep_slave_sg(
@@ -730,6 +737,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
}
if (rs->dma_tx.ch && rs->dma_rx.ch) {
+ dma_get_slave_caps(rs->dma_rx.ch, &(rs->dma_caps));
rs->dma_tx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_TXDR);
rs->dma_rx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_RXDR);
rs->dma_tx.direction = DMA_MEM_TO_DEV;
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
