[PATCH 08/10] vfio: ccw: Handling reset and shutdown with states

Two new events, VFIO_CCW_EVENT_ONLINE and VFIO_CCW_EVENT_OFFLINE allow to handle the enabling and disabling of a Sub Channel and the shutdown, quiesce and reset operations are changed accordingly. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c |

[PATCH 08/10] vfio: ccw: Handling reset and shutdown with states

Two new events, VFIO_CCW_EVENT_ONLINE and VFIO_CCW_EVENT_OFFLINE allow to handle the enabling and disabling of a Sub Channel and the shutdown, quiesce and reset operations are changed accordingly. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 47

[PATCH 04/10] vfio: ccw: replace IO_REQ event with SSCH_REQ event

This patch simplifies the IO request handling to handle the only implemented request: SSCH. Other request are invalid and get a return value of -EINVAL. This patch change the event name to VFIO_CCW_EVENT_SSCH_REQ to reflect what is done and prepare for future implementation of other requests.

[PATCH 04/10] vfio: ccw: replace IO_REQ event with SSCH_REQ event

This patch simplifies the IO request handling to handle the only implemented request: SSCH. Other request are invalid and get a return value of -EINVAL. This patch change the event name to VFIO_CCW_EVENT_SSCH_REQ to reflect what is done and prepare for future implementation of other requests.

[PATCH 07/10] vfio: ccw: Introduce the INIT event

The VFIO_CCW_EVENT_INIT event allows to export the initial state into the FSM. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 26 +++--- drivers/s390/cio/vfio_ccw_fsm.c | 21 +

[PATCH 07/10] vfio: ccw: Introduce the INIT event

The VFIO_CCW_EVENT_INIT event allows to export the initial state into the FSM. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 26 +++--- drivers/s390/cio/vfio_ccw_fsm.c | 21 + drivers/s390/cio/vfio_ccw_ops.c | 11

[PATCH 05/10] vfio: ccw: Suppress unused event parameter

The fsm_func_t function type definition does not need the event parameter since all functions are in a state/event table. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_fsm.c | 34 +++--- drivers/s390/cio/vfio_ccw_private.h |

[PATCH 05/10] vfio: ccw: Suppress unused event parameter

The fsm_func_t function type definition does not need the event parameter since all functions are in a state/event table. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_fsm.c | 34 +++--- drivers/s390/cio/vfio_ccw_private.h | 5 ++--- 2 files changed,

[PATCH 03/10] vfio: ccw: new SCH_EVENT event

The Sub channel event callback is threaded using workqueues. The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT event. The update of the SCHIB is now done inside the FSM function. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 33

[PATCH 06/10] vfio: ccw: Make FSM functions atomic

We use mutex around the FSM function call to make the FSM event handling and state change atomic. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 3 +-- drivers/s390/cio/vfio_ccw_fsm.c | 2 -- drivers/s390/cio/vfio_ccw_ops.c | 4 +---

[PATCH 03/10] vfio: ccw: new SCH_EVENT event

The Sub channel event callback is threaded using workqueues. The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT event. The update of the SCHIB is now done inside the FSM function. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 33

[PATCH 06/10] vfio: ccw: Make FSM functions atomic

We use mutex around the FSM function call to make the FSM event handling and state change atomic. Signed-off-by: Pierre Morel --- drivers/s390/cio/vfio_ccw_drv.c | 3 +-- drivers/s390/cio/vfio_ccw_fsm.c | 2 -- drivers/s390/cio/vfio_ccw_ops.c | 4 +---

[PATCH v3 04/17] y2038: s390: Remove unneeded ipc uapi header files

The s390 msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements, to avoid having to modify each copy when we extend sysvipc to deal with 64-bit time_t in 32-bit user space. Note that unlike

[PATCH v3 04/17] y2038: s390: Remove unneeded ipc uapi header files

The s390 msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements, to avoid having to modify each copy when we extend sysvipc to deal with 64-bit time_t in 32-bit user space. Note that unlike

Re: [PATCH v2] tracing: fix bad use of igrab in trace_uprobe.c

On Thu, Apr 19, 2018 at 10:58 AM, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 7:40 PM, Song Liu wrote: >> As Miklos reported and suggested: >> >> This pattern repeats two times in trace_uprobe.c and in >> kernel/events/core.c as well: >> >>

Re: [PATCH v2] tracing: fix bad use of igrab in trace_uprobe.c

On Thu, Apr 19, 2018 at 10:58 AM, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 7:40 PM, Song Liu wrote: >> As Miklos reported and suggested: >> >> This pattern repeats two times in trace_uprobe.c and in >> kernel/events/core.c as well: >> >> ret = kern_path(filename, LOOKUP_FOLLOW,

[PATCH v3 08/17] y2038: parisc: Extend sysvipc data structures

parisc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, parisc actually succeeded in defining this right for big-endian CPUs, but as

[PATCH v3 13/17] y2038: ipc: Report long times to user space

The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended to contain extra fields for storing the upper bits of the time stamps, this patch does the other half of the job and and fills the new fields on 32-bit architectures as well as 32-bit tasks running on a 64-bit kernel in compat

[PATCH v3 13/17] y2038: ipc: Report long times to user space

The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended to contain extra fields for storing the upper bits of the time stamps, this patch does the other half of the job and and fills the new fields on 32-bit architectures as well as 32-bit tasks running on a 64-bit kernel in compat

[PATCH v3 08/17] y2038: parisc: Extend sysvipc data structures

parisc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, parisc actually succeeded in defining this right for big-endian CPUs, but as

[PATCH v3 12/17] y2038: ipc: Use ktime_get_real_seconds consistently

In some places, we still used get_seconds() instead of ktime_get_real_seconds(), and I'm changing the remaining ones now to all use ktime_get_real_seconds() so we use the full available range for timestamps instead of overflowing the 'unsigned long' return value in year 2106 on 32-bit kernels.

[PATCH v3 12/17] y2038: ipc: Use ktime_get_real_seconds consistently

In some places, we still used get_seconds() instead of ktime_get_real_seconds(), and I'm changing the remaining ones now to all use ktime_get_real_seconds() so we use the full available range for timestamps instead of overflowing the 'unsigned long' return value in year 2106 on 32-bit kernels.

[PATCH v3 05/17] y2038: arm64: Extend sysvipc compat data structures

Both 32-bit amd 64-bit ARM use the asm-generic header files for their sysvipc data structures, so no special care is needed to make those work beyond y2038, with the one exception of compat mode: Since there is no asm-generic definition of the compat mode IPC structures, ARM64 provides its own

[PATCH v3 05/17] y2038: arm64: Extend sysvipc compat data structures

Both 32-bit amd 64-bit ARM use the asm-generic header files for their sysvipc data structures, so no special care is needed to make those work beyond y2038, with the one exception of compat mode: Since there is no asm-generic definition of the compat mode IPC structures, ARM64 provides its own

[PATCH v3 15/17] y2038: ipc: Enable COMPAT_32BIT_TIME

Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop) take a timespec argument. After we move 32-bit architectures over to useing 64-bit time_t based syscalls, we need seperate entry points for the old 32-bit based interfaces. This changes the #ifdef guards for the existing 32-bit

[PATCH v3 11/17] y2038: xtensa: Extend sysvipc data structures

xtensa, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. xtensa tries hard to define the structures so they work in both big-endian and little-endian systems with

[PATCH v3 15/17] y2038: ipc: Enable COMPAT_32BIT_TIME

Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop) take a timespec argument. After we move 32-bit architectures over to useing 64-bit time_t based syscalls, we need seperate entry points for the old 32-bit based interfaces. This changes the #ifdef guards for the existing 32-bit

[PATCH v3 11/17] y2038: xtensa: Extend sysvipc data structures

xtensa, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. xtensa tries hard to define the structures so they work in both big-endian and little-endian systems with

[PATCH v3 09/17] y2038: sparc: Extend sysvipc data structures

sparc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, sparc actually succeeded in defining this right for big-endian CPUs, but as

[PATCH v3 09/17] y2038: sparc: Extend sysvipc data structures

sparc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. Unlike most architectures, sparc actually succeeded in defining this right for big-endian CPUs, but as

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Dave Martin writes: > On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: > > [...] > >> The other thing we should do is to get rid of the stupid padding. >> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is >> completely insane, when it's

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Dave Martin writes: > On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: > > [...] > >> The other thing we should do is to get rid of the stupid padding. >> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is >> completely insane, when it's always just zero in the

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

Pavel Machek wrote: > > There is currently no way to verify the resume image when returning > > from hibernate. This might compromise the signed modules trust model, > > so until we can work with signed hibernate images we disable it when the > > kernel is locked down. > > I'd

[PATCH v3 17/17] y2038: compat: Move common compat types to asm-generic/compat.h

The architectures that support 32-bit compat mode define a number of simple types for use in compat handlers. About half of those are identical between architectures, and some of those are also required now by handlers shared with CONFIG_COMPAT_32BIT_TIME functions on 32-bit architectures. Let's

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

Pavel Machek wrote: > > There is currently no way to verify the resume image when returning > > from hibernate. This might compromise the signed modules trust model, > > so until we can work with signed hibernate images we disable it when the > > kernel is locked down. > > I'd rather see

[PATCH v3 17/17] y2038: compat: Move common compat types to asm-generic/compat.h

The architectures that support 32-bit compat mode define a number of simple types for use in compat handlers. About half of those are identical between architectures, and some of those are also required now by handlers shared with CONFIG_COMPAT_32BIT_TIME functions on 32-bit architectures. Let's

[PATCH v3 16/17] y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop

32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME need to have the traditional semtimedop() behavior with 32-bit timestamps for sys_ipc() by calling compat_ksys_semtimedop(), while those that are not yet converted need to keep using ksys_semtimedop() like 64-bit architectures do.

Re: [PATCH] vfio-ccw: process ssch with interrupts disabled

On 13/04/2018 16:05, Cornelia Huck wrote: When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing. Note that the subchannel lock is the same

[PATCH v3 16/17] y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop

32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME need to have the traditional semtimedop() behavior with 32-bit timestamps for sys_ipc() by calling compat_ksys_semtimedop(), while those that are not yet converted need to keep using ksys_semtimedop() like 64-bit architectures do.

Re: [PATCH] vfio-ccw: process ssch with interrupts disabled

On 13/04/2018 16:05, Cornelia Huck wrote: When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing. Note that the subchannel lock is the same

[PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Most architectures now use the asm-generic copy of the sysvipc data structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit __kernel_time_t on 32-bit architectures but have padding behind them to allow extending the type to 64-bit. Unfortunately, that fails on all big-endian

[PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures

Most architectures now use the asm-generic copy of the sysvipc data structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit __kernel_time_t on 32-bit architectures but have padding behind them to allow extending the type to 64-bit. Unfortunately, that fails on all big-endian

[PATCH v3 10/17] y2038: powerpc: Extend sysvipc data structures

powerpc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. powerpc has the same definition as parisc and sparc, but now also supports little-endian mode, which is

[PATCH v3 07/17] y2038: x86: Extend sysvipc data structures

This extends the x86 copy of the sysvipc data structures to deal with 32-bit user space that has 64-bit time_t and wants to see timestamps beyond 2038. Fortunately, x86 has padding for this purpose in all the data structures, so we can just add extra fields. With msgid64_ds and shmid64_ds, the

[PATCH v3 10/17] y2038: powerpc: Extend sysvipc data structures

powerpc, uses a nonstandard variation of the generic sysvipc data structures, intended to have the padding moved around so it can deal with big-endian 32-bit user space that has 64-bit time_t. powerpc has the same definition as parisc and sparc, but now also supports little-endian mode, which is

[PATCH v3 07/17] y2038: x86: Extend sysvipc data structures

This extends the x86 copy of the sysvipc data structures to deal with 32-bit user space that has 64-bit time_t and wants to see timestamps beyond 2038. Fortunately, x86 has padding for this purpose in all the data structures, so we can just add extra fields. With msgid64_ds and shmid64_ds, the

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

Op 19-04-18 om 13:05 schreef Fengguang Wu: > Hi Maarten, > >> What extra dmesg output do you get when you boot with drm.debug=0x1f ? > > Attached is the dmesg with drm.debug=0x1f. > > Thanks, > Fengguang Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768: kern :debug : [

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

Op 19-04-18 om 13:05 schreef Fengguang Wu: > Hi Maarten, > >> What extra dmesg output do you get when you boot with drm.debug=0x1f ? > > Attached is the dmesg with drm.debug=0x1f. > > Thanks, > Fengguang Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768: kern :debug : [

[PATCH v3 14/17] y2038: ipc: Use __kernel_timespec

This is a preparatation for changing over __kernel_timespec to 64-bit times, which involves assigning new system call numbers for mq_timedsend(), mq_timedreceive() and semtimedop() for compatibility with future y2038 proof user space. The existing ABIs will remain available through compat code.

[PATCH] mmc: sdhci-cadence: fix logically and structurally dead code

Currently, the code block inside the for loop will never execute more than once, because the function returns inmediately after the first iteration, hence the execution of the code at the second iteration is structurally dead and, code at line 281: return 0; is never reached. Based on the code

[PATCH v3 06/17] y2038: mips: Extend sysvipc data structures

MIPS is the weirdest case for sysvipc, because each of the three data structures is done differently: * msqid64_ds has padding in the right place so we could in theory extend this one to just have 64-bit values instead of time_t. As this does not work for most of the other combinations, we

[PATCH v3 14/17] y2038: ipc: Use __kernel_timespec

This is a preparatation for changing over __kernel_timespec to 64-bit times, which involves assigning new system call numbers for mq_timedsend(), mq_timedreceive() and semtimedop() for compatibility with future y2038 proof user space. The existing ABIs will remain available through compat code.

[PATCH] mmc: sdhci-cadence: fix logically and structurally dead code

Currently, the code block inside the for loop will never execute more than once, because the function returns inmediately after the first iteration, hence the execution of the code at the second iteration is structurally dead and, code at line 281: return 0; is never reached. Based on the code

[PATCH v3 06/17] y2038: mips: Extend sysvipc data structures

MIPS is the weirdest case for sysvipc, because each of the three data structures is done differently: * msqid64_ds has padding in the right place so we could in theory extend this one to just have 64-bit values instead of time_t. As this does not work for most of the other combinations, we

[PATCH v3 02/17] y2038: alpha: Remove unneeded ipc uapi header files

The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 series. Since there is no 32-bit syscall support for alpha, we don't need the other changes, but

[PATCH v3 02/17] y2038: alpha: Remove unneeded ipc uapi header files

The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 series. Since there is no 32-bit syscall support for alpha, we don't need the other changes, but

[PATCH v3 03/17] y2038: ia64: Remove unneeded ipc uapi header files

The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 changes. While ia64 no longer has a compat mode and doesn't need the file any more, it seem nicer to

[PATCH v3 03/17] y2038: ia64: Remove unneeded ipc uapi header files

The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical to the version from asm-generic. This patch removes the files and replaces them with 'generic-y' statements as part of the y2038 changes. While ia64 no longer has a compat mode and doesn't need the file any more, it seem nicer to

[PATCH v3 00/17] y2038: Convert IPC syscalls

This is an update of a series I posted a long time ago [1], updating the IPC subsystem to pass down 64-bit time stamps to user space. In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not introduce a completely new set of replacement system calls, but instead extend the existing ones

[PATCH v3 00/17] y2038: Convert IPC syscalls

This is an update of a series I posted a long time ago [1], updating the IPC subsystem to pass down 64-bit time stamps to user space. In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not introduce a completely new set of replacement system calls, but instead extend the existing ones

Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down

Pavel Machek wrote: > > (1) chmod and chown are disallowed on debugfs objects (though the root dir > > can be modified by mount and remount, but I'm not worried about that). > > This has nothing to do with the lockdown goals, right? I find chown of > such files quite nice,

Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down

Pavel Machek wrote: > > (1) chmod and chown are disallowed on debugfs objects (though the root dir > > can be modified by mount and remount, but I'm not worried about that). > > This has nothing to do with the lockdown goals, right? I find chown of > such files quite nice, to allow

Re: [PATCH 2/6] tracing: Add trace event error log

On Thu, 19 Apr 2018 09:40:33 +0900 Namhyung Kim wrote: > > I totally agree. I just want to make sure that whatever we come up with > > will be well thought out. Perhaps we can wait till November to talk > > about it. > > I'm not sure I can go to LPC this year, but

Re: [PATCH 2/6] tracing: Add trace event error log

On Thu, 19 Apr 2018 09:40:33 +0900 Namhyung Kim wrote: > > I totally agree. I just want to make sure that whatever we come up with > > will be well thought out. Perhaps we can wait till November to talk > > about it. > > I'm not sure I can go to LPC this year, but definitely interested in >

[PATCH 1/2] ARM: dts: stm32: add RTC support to stm32mp157c

Add support for RTC (Real Time Clock) to STM32MP157C SoC. Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi index

[PATCH 1/2] ARM: dts: stm32: add RTC support to stm32mp157c

Add support for RTC (Real Time Clock) to STM32MP157C SoC. Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi index bc3eddc..954 100644 ---

[PATCH 0/2] Add STM32 RTC to stm32mp157c

This series adds support for STM32 RTC to stm32mp157c SoC and enable it on stm32mp157c-ed1 board. Amelie Delaunay (2): ARM: dts: stm32: add RTC support to stm32mp157c ARM: dts: stm32: enable RTC on stm32mp157c-ed1 arch/arm/boot/dts/stm32mp157c-ed1.dts | 4

[PATCH 0/2] Add STM32 RTC to stm32mp157c

This series adds support for STM32 RTC to stm32mp157c SoC and enable it on stm32mp157c-ed1 board. Amelie Delaunay (2): ARM: dts: stm32: add RTC support to stm32mp157c ARM: dts: stm32: enable RTC on stm32mp157c-ed1 arch/arm/boot/dts/stm32mp157c-ed1.dts | 4

[PATCH 2/2] ARM: dts: stm32: enable RTC on stm32mp157c-ed1

Enable RTC (Real Time Clock) on stm32mp157c-ed1 board. Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts b/arch/arm/boot/dts/stm32mp157c-ed1.dts index

[PATCH 2/2] ARM: dts: stm32: enable RTC on stm32mp157c-ed1

Enable RTC (Real Time Clock) on stm32mp157c-ed1 board. Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts b/arch/arm/boot/dts/stm32mp157c-ed1.dts index 9f90337a..f9c4f8f 100644

Re: [PATCH 03/61] auxdisplay: simplify getting .drvdata

[CC'ing Linus W.] On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Seems

Re: [PATCH 03/61] auxdisplay: simplify getting .drvdata

[CC'ing Linus W.] On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Seems fine and other drivers in platform/ also call dev_get_drvdata

[PATCH][next] ASoC: rt5668: fix incorrect 'and' operator

From: Colin Ian King Currently logical and is being used instead of bitwise and. Fix this. Detected by CoverityScan, CID#1468008 ("Logical vs bitwise operator") Fixes: d59fb2856223 ("ASoC: rt5668: add rt5668B codec driver") Signed-off-by: Colin Ian King

[PATCH][next] ASoC: rt5668: fix incorrect 'and' operator

From: Colin Ian King Currently logical and is being used instead of bitwise and. Fix this. Detected by CoverityScan, CID#1468008 ("Logical vs bitwise operator") Fixes: d59fb2856223 ("ASoC: rt5668: add rt5668B codec driver") Signed-off-by: Colin Ian King --- sound/soc/codecs/rt5668.c | 2 +-

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v3 1/3] lan78xx: Read MAC address from DT if present

There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v3 1/3] lan78xx: Read MAC address from DT if present

There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell ---

[PATCH v3 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity

[PATCH v3 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity

[PATCH v6] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

This commit adds device tree description of Kieback & Peter GmbH iMX6Q TPC board. Signed-off-by: Lukasz Majewski Reviewed-by: Fabio Estevam --- Changes for v6: - Add space between // and SPDX - Replace 'disp0' with 'display' - Replace 'rtc: ds1307@32' with

[PATCH v6] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

This commit adds device tree description of Kieback & Peter GmbH iMX6Q TPC board. Signed-off-by: Lukasz Majewski Reviewed-by: Fabio Estevam --- Changes for v6: - Add space between // and SPDX - Replace 'disp0' with 'display' - Replace 'rtc: ds1307@32' with 'ds1307: rtc@32' - Replace 'codec:

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v3 3/3] dt-bindings: Document the DT bindings for lan78xx

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. Document the supported properties in

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for

[PATCH v3 3/3] dt-bindings: Document the DT bindings for lan78xx

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. Document the supported properties in

Re: [RFC PATCH v2 2/4] acpi: apei: Split GHES handlers outside of ghes_do_proc

On Thu, Apr 19, 2018 at 09:19:03AM -0500, Alex G. wrote: > On the other side, you lose readability as soon as you get a few more > handlers and the function becomes too long. No you don't - you split it properly. > And more importantly, you lose generality: it's not obvious that > there's

Re: [RFC PATCH v2 2/4] acpi: apei: Split GHES handlers outside of ghes_do_proc

On Thu, Apr 19, 2018 at 09:19:03AM -0500, Alex G. wrote: > On the other side, you lose readability as soon as you get a few more > handlers and the function becomes too long. No you don't - you split it properly. > And more importantly, you lose generality: it's not obvious that > there's

Re: [PATCH 0/2] nvmem: meson-efuse: add write support

On 19/04/18 15:13, Jerome Brunet wrote: On Fri, 2018-03-16 at 16:01 +0100, Jerome Brunet wrote: This changeset adds write support to meson efuse driver. The first patch just changes the way the nvmem data are allocated w/o any functional changes. The second patches actually adds write

Re: [PATCH 0/2] nvmem: meson-efuse: add write support

On 19/04/18 15:13, Jerome Brunet wrote: On Fri, 2018-03-16 at 16:01 +0100, Jerome Brunet wrote: This changeset adds write support to meson efuse driver. The first patch just changes the way the nvmem data are allocated w/o any functional changes. The second patches actually adds write

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote: > On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote: > > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: > > > Hi Rahul, > > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote: > > > > On production servers

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote: > On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote: > > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: > > > Hi Rahul, > > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote: > > > > On production servers

Re: [PATCH v4 05/15] KVM: s390: enable/disable AP interpretive execution

On 04/18/2018 04:31 AM, Pierre Morel wrote: On 17/04/2018 20:11, Tony Krowiak wrote: On 04/17/2018 12:55 PM, Pierre Morel wrote: On 17/04/2018 18:22, Tony Krowiak wrote: On 04/17/2018 12:13 PM, Pierre Morel wrote: On 17/04/2018 17:02, Tony Krowiak wrote: On 04/16/2018 06:51 AM, Pierre Morel

Re: [PATCH v4 05/15] KVM: s390: enable/disable AP interpretive execution

On 04/18/2018 04:31 AM, Pierre Morel wrote: On 17/04/2018 20:11, Tony Krowiak wrote: On 04/17/2018 12:55 PM, Pierre Morel wrote: On 17/04/2018 18:22, Tony Krowiak wrote: On 04/17/2018 12:13 PM, Pierre Morel wrote: On 17/04/2018 17:02, Tony Krowiak wrote: On 04/16/2018 06:51 AM, Pierre Morel

[PATCH 05/61] clk: samsung: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++

[PATCH 05/61] clk: samsung: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++ 1 file changed, 2 insertions(+),

[PATCH 08/61] dmaengine: dw: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/dma/dw/platform.c | 6 ++ 1 file

[PATCH 08/61] dmaengine: dw: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/dma/dw/platform.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH 06/61] crypto: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/crypto/exynos-rng.c | 6 ++

[PATCH 06/61] crypto: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Build tested only. buildbot is happy. Please apply individually. drivers/crypto/exynos-rng.c | 6 ++ drivers/crypto/picoxcell_crypto.c | 6

<    5   6   7   8   9   10   11   12   13   14   >