[PATCH 1/2] send-email: add an option to impose delay sent E-Mails

Add a --send-delay option with a corresponding sendemail.smtpSendDelay configuration variable. When set to e.g. 2, this causes send-email to sleep 2 seconds before sending the next E-Mail. We'll only sleep between sends, not before the first send, or after the last. This option is useful because

[PATCH 1/2] send-email: add an option to impose delay sent E-Mails

Add a --send-delay option with a corresponding sendemail.smtpSendDelay configuration variable. When set to e.g. 2, this causes send-email to sleep 2 seconds before sending the next E-Mail. We'll only sleep between sends, not before the first send, or after the last. This option is useful because

[PATCH 2/2] send-email: supply a --send-delay=1 by default

The earlier change to add this option described the problem this option is trying to solve. This turns it on by default with a value of 1 second, which'll hopefully solve it, and if not user reports as well as the X-Mailer-Send-Delay header should help debug it. I think the trade-off of slowing

[PATCH 2/2] send-email: supply a --send-delay=1 by default

The earlier change to add this option described the problem this option is trying to solve. This turns it on by default with a value of 1 second, which'll hopefully solve it, and if not user reports as well as the X-Mailer-Send-Delay header should help debug it. I think the trade-off of slowing

[PATCH 0/2] send-email: impose a delay while sending to appease GMail

GMail doesn't sort E-Mail by the "Date" header, but by when the E-Mail was received. As a result patches sent to the git ML and LKML (and friends) show up out of order in GMail. This series works around that issue by sleeping for 1 second between sending E-Mails. If you're on the LKML and

[PATCH 0/2] send-email: impose a delay while sending to appease GMail

GMail doesn't sort E-Mail by the "Date" header, but by when the E-Mail was received. As a result patches sent to the git ML and LKML (and friends) show up out of order in GMail. This series works around that issue by sleeping for 1 second between sending E-Mails. If you're on the LKML and

Re: [PATCH v2 1/6] bus: arm-cci: use asm unreachable

On 25.03.2018 20:14, Nicolas Pitre wrote: > On Sun, 25 Mar 2018, Stefan Agner wrote: > >> Mixing asm and C code is not recommended in a naked function by >> gcc and leads to an error when using clang: >> drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked >> function is not

Re: [PATCH v2 1/6] bus: arm-cci: use asm unreachable

On 25.03.2018 20:14, Nicolas Pitre wrote: > On Sun, 25 Mar 2018, Stefan Agner wrote: > >> Mixing asm and C code is not recommended in a naked function by >> gcc and leads to an error when using clang: >> drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked >> function is not

Re: [PATCH v2 2/6] i2c: i2c-stm32f7: Add slave support

On Wed, Mar 21, 2018 at 05:48:56PM +0100, Pierre-Yves MORDRET wrote: > This patch adds slave support for I2C controller embedded in STM32F7 SoC > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET Looks OK from

Re: [PATCH v2 2/6] i2c: i2c-stm32f7: Add slave support

On Wed, Mar 21, 2018 at 05:48:56PM +0100, Pierre-Yves MORDRET wrote: > This patch adds slave support for I2C controller embedded in STM32F7 SoC > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET Looks OK from a first look. What kind of tests did you do? > --- >

Re: [PATCH v2 1/6] bus: arm-cci: use asm unreachable

On Sun, 25 Mar 2018, Stefan Agner wrote: > Mixing asm and C code is not recommended in a naked function by > gcc and leads to an error when using clang: > drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked > function is not supported > unreachable(); > ^ > >

Re: [PATCH v2 1/6] bus: arm-cci: use asm unreachable

On Sun, 25 Mar 2018, Stefan Agner wrote: > Mixing asm and C code is not recommended in a naked function by > gcc and leads to an error when using clang: > drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked > function is not supported > unreachable(); > ^ > >

[PATCH v2 0/6] ARM: clang support

This patchset fixes some remaining issues when building the ARM architecture using LLVM/clang. The patchset requires the following kbuild change: https://lkml.org/lkml/2018/3/19/1756 With that patch and this patchset applied and I can successfully build (and boot) the multi_v7_defconfig with

[PATCH v2 4/6] ARM: drop no-thumb-interwork in EABI mode

According to GCC documentation -m(no-)thumb-interwork is meaningless in AAPCS configurations. Also clang does not support the flag: clang-5.0: error: unknown argument: '-mno-thumb-interwork' Just drop -mno-thumb-interwork in AEABI configuration. Signed-off-by: Stefan Agner

[PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

As documented in GCC naked functions should only use Basic asm syntax. The Extended asm or mixture of Basic asm and "C" code is not guaranteed. Currently this works because it was hard coded to follow and check GCC behavior for arguments and register placement. Furthermore with clang using

[PATCH v2 2/6] efi/libstub/arm: add support for building with clang

Use cc-options call for -mno-single-pic-base since the option is not available in clang. LLVM/clang always assumes a fixed displacement between text/data and hence uses PC relative addressing. Signed-off-by: Stefan Agner --- drivers/firmware/efi/libstub/Makefile | 3 ++- 1 file

[PATCH v2 0/6] ARM: clang support

This patchset fixes some remaining issues when building the ARM architecture using LLVM/clang. The patchset requires the following kbuild change: https://lkml.org/lkml/2018/3/19/1756 With that patch and this patchset applied and I can successfully build (and boot) the multi_v7_defconfig with

[PATCH v2 4/6] ARM: drop no-thumb-interwork in EABI mode

According to GCC documentation -m(no-)thumb-interwork is meaningless in AAPCS configurations. Also clang does not support the flag: clang-5.0: error: unknown argument: '-mno-thumb-interwork' Just drop -mno-thumb-interwork in AEABI configuration. Signed-off-by: Stefan Agner ---

[PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

As documented in GCC naked functions should only use Basic asm syntax. The Extended asm or mixture of Basic asm and "C" code is not guaranteed. Currently this works because it was hard coded to follow and check GCC behavior for arguments and register placement. Furthermore with clang using

[PATCH v2 2/6] efi/libstub/arm: add support for building with clang

Use cc-options call for -mno-single-pic-base since the option is not available in clang. LLVM/clang always assumes a fixed displacement between text/data and hence uses PC relative addressing. Signed-off-by: Stefan Agner --- drivers/firmware/efi/libstub/Makefile | 3 ++- 1 file changed, 2

[PATCH v2 5/6] ARM: add support for building ARM kernel with clang

Use cc-options call for compiler options which are not available in clang. With this patch an ARMv7 multi platform kernel can be successfully build using clang (tested with version 5.0.1). Based-on-patches-by: Behan Webster Signed-off-by: Stefan Agner

[PATCH v2 5/6] ARM: add support for building ARM kernel with clang

Use cc-options call for compiler options which are not available in clang. With this patch an ARMv7 multi platform kernel can be successfully build using clang (tested with version 5.0.1). Based-on-patches-by: Behan Webster Signed-off-by: Stefan Agner --- Changes in v2: - Drop cc-options in

[PATCH v2 1/6] bus: arm-cci: use asm unreachable

Mixing asm and C code is not recommended in a naked function by gcc and leads to an error when using clang: drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked function is not supported unreachable(); ^ While the function is marked __naked it actually properly

[PATCH v2 1/6] bus: arm-cci: use asm unreachable

Mixing asm and C code is not recommended in a naked function by gcc and leads to an error when using clang: drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked function is not supported unreachable(); ^ While the function is marked __naked it actually properly

[PATCH v2 6/6] ARM: uaccess: remove const to avoid duplicate specifier

Some users of get_user use the macro with an argument p which is already specified as static. When using clang this leads to a duplicate specifier: CC arch/arm/kernel/process.o In file included from init/do_mounts.c:15: In file included from ./include/linux/tty.h:7: In file included

[PATCH v2 6/6] ARM: uaccess: remove const to avoid duplicate specifier

Some users of get_user use the macro with an argument p which is already specified as static. When using clang this leads to a duplicate specifier: CC arch/arm/kernel/process.o In file included from init/do_mounts.c:15: In file included from ./include/linux/tty.h:7: In file included

Re: [PATCH 4/4] staging: iio: tsl2x7x: move out of staging

On Sat, 24 Mar 2018 16:05:55 -0400 Brian Masney wrote: > Move the tsl2x7x driver out of staging and into mainline. > > Signed-off-by: Brian Masney Various comments inline. I'm wondering if we should rename the driver before moving it. The wild

Re: [PATCH 4/4] staging: iio: tsl2x7x: move out of staging

On Sat, 24 Mar 2018 16:05:55 -0400 Brian Masney wrote: > Move the tsl2x7x driver out of staging and into mainline. > > Signed-off-by: Brian Masney Various comments inline. I'm wondering if we should rename the driver before moving it. The wild cards bother me as we are very likely to see

[PATCH v2 1/2] gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal --- drivers/gpu/drm/drm_lease.c | 2 +- 1 file changed, 1

[PATCH v2 1/2] gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal --- drivers/gpu/drm/drm_lease.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 1 file

[PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 0/2] drm: Replace list_entry

Replace list_entry with list_{next/prev}_entry. Arushi Singhal (2): gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry drivers/gpu/drm/drm_lease.c| 2 +-

[PATCH v2 0/2] drm: Replace list_entry

Replace list_entry with list_{next/prev}_entry. Arushi Singhal (2): gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry drivers/gpu/drm/drm_lease.c| 2 +-

[PATCH 2/2] smp: introduce kick_active_cpus_sync()

kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI. If CPU is in extended quiescent state (idle task or nohz_full userspace), this work may be done at the exit of this state. Delaying synchronization helps to save power if CPU is in idle state and decrease latency for

[PATCH 2/2] smp: introduce kick_active_cpus_sync()

kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI. If CPU is in extended quiescent state (idle task or nohz_full userspace), this work may be done at the exit of this state. Delaying synchronization helps to save power if CPU is in idle state and decrease latency for

[PATCH 1/2] rcu: declare rcu_eqs_special_set() in public header

rcu_eqs_special_set() is declared only in internal header kernel/rcu/tree.h and stubbed in include/linux/rcutiny.h. This patch declares rcu_eqs_special_set() in include/linux/rcutree.h, so it can be used in non-rcu kernel code. Signed-off-by: Yury Norov ---

[PATCH 1/2] rcu: declare rcu_eqs_special_set() in public header

rcu_eqs_special_set() is declared only in internal header kernel/rcu/tree.h and stubbed in include/linux/rcutiny.h. This patch declares rcu_eqs_special_set() in include/linux/rcutree.h, so it can be used in non-rcu kernel code. Signed-off-by: Yury Norov --- include/linux/rcutree.h | 1 + 1

[PATCH 0/2] smp: don't kick CPUs running idle or nohz_full tasks

kick_all_cpus_sync() is used to broadcast IPIs to all online CPUs to force them sync caches, TLB etc. It is is called only 3 times - from mm/slab, arm64 and powerpc code. With framework introduced in patch b8c17e6664c46 ("rcu: Maintain special bits at bottom of ->dynticks counter") we can delay

[PATCH 0/2] smp: don't kick CPUs running idle or nohz_full tasks

kick_all_cpus_sync() is used to broadcast IPIs to all online CPUs to force them sync caches, TLB etc. It is is called only 3 times - from mm/slab, arm64 and powerpc code. With framework introduced in patch b8c17e6664c46 ("rcu: Maintain special bits at bottom of ->dynticks counter") we can delay

Re: [PATCH 3/4] staging: iio: tsl2x7x: use either direction for IIO_EV_INFO_{ENABLE,PERIOD}

On Sat, 24 Mar 2018 16:05:54 -0400 Brian Masney wrote: > The events IIO_EV_INFO_VALUE and IIO_EV_INFO_ENABLE currently have a > falling and rising direction configured. There does not need to be a > separate distinction so this patch changes these to use the > either

Re: [PATCH 3/4] staging: iio: tsl2x7x: use either direction for IIO_EV_INFO_{ENABLE,PERIOD}

On Sat, 24 Mar 2018 16:05:54 -0400 Brian Masney wrote: > The events IIO_EV_INFO_VALUE and IIO_EV_INFO_ENABLE currently have a > falling and rising direction configured. There does not need to be a > separate distinction so this patch changes these to use the > either direction. Directory listing

Re: [PATCH v6 04/11] clk: actions: Add gate clock support

: https://github.com/0day-ci/linux/commits/Manivannan-Sadhasivam/Add-clock-driver-for-Actions-S900-SoC/20180325-231339 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce

Re: [PATCH v6 04/11] clk: actions: Add gate clock support

: https://github.com/0day-ci/linux/commits/Manivannan-Sadhasivam/Add-clock-driver-for-Actions-S900-SoC/20180325-231339 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce

Re: [PATCH 01/16] initrd: Add generic code path for common initrd unloading logic.

Shea Levy a écrit : Signed-off-by: Shea Levy --- init/initramfs.c | 7 +++ usr/Kconfig | 4 2 files changed, 11 insertions(+) diff --git a/init/initramfs.c b/init/initramfs.c index 7e99a0038942..de5ce873eb5a 100644 --- a/init/initramfs.c

Re: [PATCH 01/16] initrd: Add generic code path for common initrd unloading logic.

Shea Levy a écrit : Signed-off-by: Shea Levy --- init/initramfs.c | 7 +++ usr/Kconfig | 4 2 files changed, 11 insertions(+) diff --git a/init/initramfs.c b/init/initramfs.c index 7e99a0038942..de5ce873eb5a 100644 --- a/init/initramfs.c +++ b/init/initramfs.c @@ -526,6

Re: [PATCH 2/4] staging: iio: tsl2x7x: move IIO_CHAN_INFO_CALIB{SCALE,BIAS} to IIO_LIGHT channel

On Sat, 24 Mar 2018 16:05:53 -0400 Brian Masney wrote: > The IIO_CHAN_INFO_CALIBSCALE and IIO_CHAN_INFO_CALIBBIAS masks are > currently associated with the IIO_INTENSITY channel but should be > associated with the IIO_LIGHT channel since these values are used to >

Re: [PATCH 2/4] staging: iio: tsl2x7x: move IIO_CHAN_INFO_CALIB{SCALE,BIAS} to IIO_LIGHT channel

On Sat, 24 Mar 2018 16:05:53 -0400 Brian Masney wrote: > The IIO_CHAN_INFO_CALIBSCALE and IIO_CHAN_INFO_CALIBBIAS masks are > currently associated with the IIO_INTENSITY channel but should be > associated with the IIO_LIGHT channel since these values are used to > calculate the lux. Directory

Re: [PATCH 1/4] staging: iio: tsl2x7x: use auto increment I2C protocol

On Sat, 24 Mar 2018 16:05:52 -0400 Brian Masney wrote: > The hardware supports 16-bit ALS and proximity readings, however the > datasheet recommends using the I2C auto increment protocol so that the > correct high and low bytes are read even if the integration cycle ends >

Re: [PATCH] ftrace: fix stddev calculation in function profiler (again)

On 03/24/2018 11:03 PM, Matthias Schiffer wrote: > On 03/24/2018 05:26 PM, Matthias Schiffer wrote: >> It is well-known that it is not possible to accurately calculate variances >> just by accumulating squared samples; in fact, such an approach can even >> result in negative numbers. An earlier

Re: [PATCH 1/4] staging: iio: tsl2x7x: use auto increment I2C protocol

On Sat, 24 Mar 2018 16:05:52 -0400 Brian Masney wrote: > The hardware supports 16-bit ALS and proximity readings, however the > datasheet recommends using the I2C auto increment protocol so that the > correct high and low bytes are read even if the integration cycle ends > between reading the

Re: [PATCH] ftrace: fix stddev calculation in function profiler (again)

On 03/24/2018 11:03 PM, Matthias Schiffer wrote: > On 03/24/2018 05:26 PM, Matthias Schiffer wrote: >> It is well-known that it is not possible to accurately calculate variances >> just by accumulating squared samples; in fact, such an approach can even >> result in negative numbers. An earlier

[PATCH][V3] staging: r8822be: fix typos in header guard macros

From: Colin Ian King The macros for __PHYDMKFREE_H__ and __PHYDM_FEATURES_H__ contain typos and don't match the #if guard check. Defined them correctly. Cleans up clang warnings: warning: '__PHYDMKFREE_H__' is used as a header guard here, followed by #define of a

[PATCH][V3] staging: r8822be: fix typos in header guard macros

From: Colin Ian King The macros for __PHYDMKFREE_H__ and __PHYDM_FEATURES_H__ contain typos and don't match the #if guard check. Defined them correctly. Cleans up clang warnings: warning: '__PHYDMKFREE_H__' is used as a header guard here, followed by #define of a different macro

Re: [PATCH v5 1/8] counter: Introduce the Generic Counter interface

On Sun, 2018-03-25 at 17:56 +0100, Jonathan Cameron wrote: > On Sun, 25 Mar 2018 00:46:10 -0700 > Joe Perches wrote: > > > On Sat, 2018-03-24 at 17:33 +, Jonathan Cameron wrote: > > > checkpatch.pl --strict (but take into account some of the warnings will > > > be silly so

Re: [PATCH v5 1/8] counter: Introduce the Generic Counter interface

On Sun, 2018-03-25 at 17:56 +0100, Jonathan Cameron wrote: > On Sun, 25 Mar 2018 00:46:10 -0700 > Joe Perches wrote: > > > On Sat, 2018-03-24 at 17:33 +, Jonathan Cameron wrote: > > > checkpatch.pl --strict (but take into account some of the warnings will > > > be silly so don't fix them

Re: [PATCH v5 1/8] counter: Introduce the Generic Counter interface

On Sun, 25 Mar 2018 00:46:10 -0700 Joe Perches wrote: > On Sat, 2018-03-24 at 17:33 +, Jonathan Cameron wrote: > > checkpatch.pl --strict (but take into account some of the warnings will > > be silly so don't fix them all). > > What checkpatch output is silly? Sorry -

Re: [PATCH v5 1/8] counter: Introduce the Generic Counter interface

On Sun, 25 Mar 2018 00:46:10 -0700 Joe Perches wrote: > On Sat, 2018-03-24 at 17:33 +, Jonathan Cameron wrote: > > checkpatch.pl --strict (but take into account some of the warnings will > > be silly so don't fix them all). > > What checkpatch output is silly? Sorry - bad word choice. It

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sun, 25 Mar 2018 01:29:41 -0700 John Syne wrote: > Hi Jonathan, Hi John, Please wrap your normal emails (excepting tables) to 80 chars. > > I was speaking with Rodrigo and here is what I think must be done to move > ADE7878 out of staging > > Here are the steps as I

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sun, 25 Mar 2018 01:29:41 -0700 John Syne wrote: > Hi Jonathan, Hi John, Please wrap your normal emails (excepting tables) to 80 chars. > > I was speaking with Rodrigo and here is what I think must be done to move > ADE7878 out of staging > > Here are the steps as I see them: > > 1)

Re: [PATCH v2] scripts/kconfig: cleanup symbol handling code

2018-03-10 19:56 GMT+09:00 Joey Pabalinas : > Many of the variable names in scripts/kconfig/symbol.c are > far too terse to the point of not at all identifying _what_ > they are actually used for (`p` and `l` as a couple examples), > and overall there is a large amount of

Re: [PATCH v2] scripts/kconfig: cleanup symbol handling code

2018-03-10 19:56 GMT+09:00 Joey Pabalinas : > Many of the variable names in scripts/kconfig/symbol.c are > far too terse to the point of not at all identifying _what_ > they are actually used for (`p` and `l` as a couple examples), > and overall there is a large amount of code that could use >

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sat, 24 Mar 2018 16:06:17 -0700 John Syne wrote: This thread is becoming unmanageable so I am cropping this down to just the questions that remain open. > >> Probably easier to copy and paste this table into a spreadsheet. Let me > >> know if there is anything I got

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sat, 24 Mar 2018 16:06:17 -0700 John Syne wrote: This thread is becoming unmanageable so I am cropping this down to just the questions that remain open. > >> Probably easier to copy and paste this table into a spreadsheet. Let me > >> know if there is anything I got wrong. Thank you again

compliment of the day

-- Hi dear. It is wonderful to contact you, I want us to have correspondence. I wish you will have the desire so that we can get acquainted to each other. Life itself is a mystery, you never know where it might lead you. I'm Tracy.William, a French American . I will be pleased if you reply

compliment of the day

-- Hi dear. It is wonderful to contact you, I want us to have correspondence. I wish you will have the desire so that we can get acquainted to each other. Life itself is a mystery, you never know where it might lead you. I'm Tracy.William, a French American . I will be pleased if you reply

Re: [PATCH V2 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations

Hi Dong, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on clk/clk-next] [also build test WARNING on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH V2 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations

Hi Dong, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on clk/clk-next] [also build test WARNING on v4.16-rc6 next-20180323] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sat, 24 Mar 2018 15:45:21 -0700 John Syne wrote: > > On Mar 24, 2018, at 8:02 AM, Jonathan Cameron wrote: > > > > On Mon, 19 Mar 2018 22:57:16 -0700 > > John Syne wrote: > > > >> Hi Jonathan, > >> > >> Thank you for all your

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sat, 24 Mar 2018 15:45:21 -0700 John Syne wrote: > > On Mar 24, 2018, at 8:02 AM, Jonathan Cameron wrote: > > > > On Mon, 19 Mar 2018 22:57:16 -0700 > > John Syne wrote: > > > >> Hi Jonathan, > >> > >> Thank you for all your hard work. Your feedback is really helpful. I’m > >>

[PATCH] syscalls: define and explain goal to not call syscalls in the kernel

The syscall entry points to the kernel defined by SYSCALL_DEFINEx() and COMPAT_SYSCALL_DEFINEx() should only be called from userspace through kernel entry points, but not from the kernel itself. This will allow cleanups and optimizations to the entry paths *and* to the parts of the kernel code

[PATCH] syscalls: define and explain goal to not call syscalls in the kernel

The syscall entry points to the kernel defined by SYSCALL_DEFINEx() and COMPAT_SYSCALL_DEFINEx() should only be called from userspace through kernel entry points, but not from the kernel itself. This will allow cleanups and optimizations to the entry paths *and* to the parts of the kernel code

One more thing...

Sorry, once again, but there's another critical piece of info you need, whether you know it or not. rEFIt, the Mac boot loader, bridged two vectors of the intel machine, formerally separate FOR DECADES between Apple and PC worlds. This has also exercised the hardware and software issues for the

One more thing...

Sorry, once again, but there's another critical piece of info you need, whether you know it or not. rEFIt, the Mac boot loader, bridged two vectors of the intel machine, formerally separate FOR DECADES between Apple and PC worlds. This has also exercised the hardware and software issues for the

Re: [PATCH] proc: move /proc/sysvipc creation to where it belongs

On Fri, 16 Feb 2018, Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan Acked. However, a small redundant description might be nice. " Move the proc_mkdir() call within the sysvipc subsystem such that we avoid polluting proc_root_init() with petty cpp. " Thanks,

Re: [PATCH] proc: move /proc/sysvipc creation to where it belongs

On Fri, 16 Feb 2018, Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan Acked. However, a small redundant description might be nice. " Move the proc_mkdir() call within the sysvipc subsystem such that we avoid polluting proc_root_init() with petty cpp. " Thanks, Davidlohr

[PATCH v7 1/2] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

[PATCH v7 1/2] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

[PATCH v7 2/2] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. --- drivers/hid/hid-steam.c | 140 +++- 1 file changed, 139 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c

[PATCH v7 0/2] hid-steam driver with user mode client dection

This is a reroll of the Steam Controller driver. This time the client usage is detected by using exposing a custom hidraw device (hid_ll_driver) to userland and forwarding that to the real one. About how the lizard-mode/hidraw-client issue is handled, I have added a module parameter (I don't

[PATCH v7 2/2] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. --- drivers/hid/hid-steam.c | 140 +++- 1 file changed, 139 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c

[PATCH v7 0/2] hid-steam driver with user mode client dection

This is a reroll of the Steam Controller driver. This time the client usage is detected by using exposing a custom hidraw device (hid_ll_driver) to userland and forwarding that to the real one. About how the lizard-mode/hidraw-client issue is handled, I have added a module parameter (I don't

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* Pavel Machek [180324 20:03]: > On Sat 2018-03-24 07:25:17, Tony Lindgren wrote: > > * Dan Williams [180324 14:00]: > > > On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote: > > > > Does ofonod work for you? I could not get that one to work... > > > > > >

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* Pavel Machek [180324 20:03]: > On Sat 2018-03-24 07:25:17, Tony Lindgren wrote: > > * Dan Williams [180324 14:00]: > > > On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote: > > > > Does ofonod work for you? I could not get that one to work... > > > > > > Because it's looking for a Gobi

SPECTRE, MELTDOWN, boot loaders, and cursors: A shot out of the blue....

I apogize for what is probably going to be a VERY unusual and perhaps rude email to the kernel list, but I'm taking a wild shot at something in order to fix the Meltdown and Spectre bugs which perhaps were wrongly blamed on Intel and now maybe AMD. The issue, lads, may be *interdimensional*.

SPECTRE, MELTDOWN, boot loaders, and cursors: A shot out of the blue....

I apogize for what is probably going to be a VERY unusual and perhaps rude email to the kernel list, but I'm taking a wild shot at something in order to fix the Meltdown and Spectre bugs which perhaps were wrongly blamed on Intel and now maybe AMD. The issue, lads, may be *interdimensional*.

[PATCH] mtd: Use DIV_ROUND_UP()

The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. Signed-off-by: Arushi Singhal --- drivers/mtd/ftl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/ftl.c

[PATCH] mtd: Use DIV_ROUND_UP()

The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. Signed-off-by: Arushi Singhal --- drivers/mtd/ftl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/ftl.c b/drivers/mtd/ftl.c index a048429..61d5cf8

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 25 March 2018 at 12:21, Jonathan Liu wrote: > On 8 February 2018 at 14:55, Jeffy Chen wrote: >> From: AMAN DEEP >> >> There is a race condition between finish_unlinks->finish_urb() function >> and usb_kill_urb() in ohci

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

Hi, On 25 March 2018 at 12:21, Jonathan Liu wrote: > On 8 February 2018 at 14:55, Jeffy Chen wrote: >> From: AMAN DEEP >> >> There is a race condition between finish_unlinks->finish_urb() function >> and usb_kill_urb() in ohci controller case. The finish_urb calls >> spin_unlock(>lock) before

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, On 03/25/2018 09:41 AM, Paul Menzel wrote: On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel wrote: According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM)

Re: efisubsys_init takes more than a few milliseconds

Dear Ard, On 03/25/2018 09:41 AM, Paul Menzel wrote: On 03/24/2018 11:35 PM, Ard Biesheuvel wrote: On 24 March 2018 at 22:10, Paul Menzel wrote: According to `initcall_debug`, `efisubsys_init` takes more than a few milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM)

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

On Sun, 25 Mar 2018, Arushi Singhal wrote: > > > On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall wrote: > > > On Mon, 19 Mar 2018, Arushi Singhal wrote: > > > This patch replace list_entry with list_{next/prev}_entry as > it makes > > the code more

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

On Sun, 25 Mar 2018, Arushi Singhal wrote: > > > On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall wrote: > > > On Mon, 19 Mar 2018, Arushi Singhal wrote: > > > This patch replace list_entry with list_{next/prev}_entry as > it makes > > the code more clear to read. >

[PATCH v7 5/7] net: qlge: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

[PATCH v7 5/7] net: qlge: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

[PATCH v7 6/7] bnxt_en: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

[PATCH v7 1/7] net: qla3xxx: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing code to wmb() writel_relaxed() mmiowb()

[PATCH v7 6/7] bnxt_en: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Create a new wrapper function with relaxed write operator. Use the new wrapper when a write is

[PATCH v7 1/7] net: qla3xxx: Eliminate duplicate barriers on weakly-ordered archs

Code includes wmb() followed by writel(). writel() already has a barrier on some architectures like arm64. This ends up CPU observing two barriers back to back before executing the register write. Since code already has an explicit barrier call, changing code to wmb() writel_relaxed() mmiowb()

<    1   2   3   4   5   6   7   >