[PATCH 093/100] rtc: s35390a: remove useless indirection

s35390a_set_datetime, s35390a_get_datetime, s35390a_set_alarm and s35390a_read_alarm are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-s35390a.c | 32 1 file changed, 8

[PATCH 085/100] rtc: pm8xxx: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pm8xxx.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/rtc/rtc-pm8xxx.c

[PATCH 078/100] rtc: m41t80: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-m41t80.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 080/100] rtc: max77686: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max77686.c | 4 +--- 1 file changed, 1 insertion(+), 3

[PATCH 080/100] rtc: max77686: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max77686.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH 078/100] rtc: m41t80: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-m41t80.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 099/100] rtc: pcf85063: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf85063.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 099/100] rtc: pcf85063: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf85063.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 087/100] rtc: rx8581: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rx8581.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff

[PATCH 087/100] rtc: rx8581: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rx8581.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git

[PATCH 096/100] rtc: rs5c372: remove useless indirection

rs5c372_get_datetime and rs5c372_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-)

[PATCH 096/100] rtc: rs5c372: remove useless indirection

rs5c372_get_datetime and rs5c372_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git

[PATCH 095/100] rtc: rs5c372: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH 097/100] rtc: max6900: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max6900.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 095/100] rtc: rs5c372: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 097/100] rtc: max6900: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max6900.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

On Wed, Feb 21, 2018 at 12:04:03PM -0800, Andrew Morton wrote: > On Wed, 21 Feb 2018 22:53:40 +0300 Alexey Dobriyan > wrote: > > > I totally forgot that _parse_integer() accepts arbitrary amount of > > leading zeroes leading to the following: > > > > OK > >

[PATCH 094/100] rtc: rs5c372: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

On Wed, Feb 21, 2018 at 12:04:03PM -0800, Andrew Morton wrote: > On Wed, 21 Feb 2018 22:53:40 +0300 Alexey Dobriyan > wrote: > > > I totally forgot that _parse_integer() accepts arbitrary amount of > > leading zeroes leading to the following: > > > > OK > > # readlink

[PATCH 094/100] rtc: rs5c372: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-rs5c372.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/rtc/rtc-rs5c372.c

Re: [PATCH v2] iio:dummy: Replace S_IWUSR by 0200

On Wed, Feb 21, 2018 at 9:28 PM, Rodrigo Siqueira wrote: > This patch fixes the checkpatch.pl warning: > > drivers/iio/dummy/iio_dummy_evgen.c:151: WARNING: Symbolic permissions > 'S_IWUSR' are not preferred. Consider using octal permissions '0200'. > ... Why this

Re: [PATCH v2] iio:dummy: Replace S_IWUSR by 0200

On Wed, Feb 21, 2018 at 9:28 PM, Rodrigo Siqueira wrote: > This patch fixes the checkpatch.pl warning: > > drivers/iio/dummy/iio_dummy_evgen.c:151: WARNING: Symbolic permissions > 'S_IWUSR' are not preferred. Consider using octal permissions '0200'. > ... Why this "..." :)? Commit subject could

Re: [PATCH v12 11/11] sparc64: Update signal delivery to use new helper functions

Khalid Aziz writes: > Commit f8ec66014ffd ("signal: Add send_sig_fault and force_sig_fault") > added new helper functions to streamline signal delivery. This patch > updates signal delivery for new/updated handlers for ADI related > exceptions to use the helper function.

Re: [PATCH v12 11/11] sparc64: Update signal delivery to use new helper functions

Khalid Aziz writes: > Commit f8ec66014ffd ("signal: Add send_sig_fault and force_sig_fault") > added new helper functions to streamline signal delivery. This patch > updates signal delivery for new/updated handlers for ADI related > exceptions to use the helper function. > > Signed-off-by:

Re: [PATCH v2] fork: Unconditionally clear stack on fork

On Wed, 21 Feb 2018 11:29:33 +0100 Michal Hocko wrote: > On Tue 20-02-18 18:16:59, Kees Cook wrote: > > One of the classes of kernel stack content leaks[1] is exposing the > > contents of prior heap or stack contents when a new process stack is > > allocated. Normally, those

Re: [PATCH v2] fork: Unconditionally clear stack on fork

On Wed, 21 Feb 2018 11:29:33 +0100 Michal Hocko wrote: > On Tue 20-02-18 18:16:59, Kees Cook wrote: > > One of the classes of kernel stack content leaks[1] is exposing the > > contents of prior heap or stack contents when a new process stack is > > allocated. Normally, those stacks are not

[PATCH] smpboot: correctly update number of booted cores

Without this fix, /proc/cpuinfo will display an incorrect amount of CPU cores, after bringing them offline and online again, as exemplified below: $ cat /proc/cpuinfo | grep cores cpu cores : 4 cpu cores : 8 cpu cores : 8 cpu cores : 20 cpu cores : 4 cpu cores

[PATCH] smpboot: correctly update number of booted cores

Without this fix, /proc/cpuinfo will display an incorrect amount of CPU cores, after bringing them offline and online again, as exemplified below: $ cat /proc/cpuinfo | grep cores cpu cores : 4 cpu cores : 8 cpu cores : 8 cpu cores : 20 cpu cores : 4 cpu cores

Re: [PATCH v12 01/11] signals, sparc: Add signal codes for ADI violations

Khalid Aziz writes: > SPARC M7 processor introduces a new feature - Application Data > Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. > When a rogue access occurs, MMU blocks the access and raises an > exception. In response to the exception, kernel

Re: [PATCH v12 01/11] signals, sparc: Add signal codes for ADI violations

Khalid Aziz writes: > SPARC M7 processor introduces a new feature - Application Data > Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. > When a rogue access occurs, MMU blocks the access and raises an > exception. In response to the exception, kernel sends the offending >

[PATCH 091/100] rtc: s35390a: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-s35390a.c | 4 1 file changed, 4 deletions(-) diff --git

[PATCH 091/100] rtc: s35390a: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-s35390a.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/rtc/rtc-s35390a.c

[PATCH 098/100] rtc: max6900: remove useless indirection

max6900_i2c_read_time and max6900_i2c_set_time are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max6900.c | 17 - 1 file changed, 4 insertions(+), 13

[PATCH 098/100] rtc: max6900: remove useless indirection

max6900_i2c_read_time and max6900_i2c_set_time are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-max6900.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git

[PATCH 100/100] rtc: pcf85063: remove useless indirection

pcf85063_get_datetime and pcf85063_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf85063.c | 16 1 file changed, 4 insertions(+), 12

[PATCH 100/100] rtc: pcf85063: remove useless indirection

pcf85063_get_datetime and pcf85063_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf85063.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git

[PATCH 092/100] rtc: s35390a: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-s35390a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 092/100] rtc: s35390a: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-s35390a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 029/100] rtc: efi: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 088/100] rtc: tile: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-tile.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 029/100] rtc: efi: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-efi.c

[PATCH 088/100] rtc: tile: remove useless message

It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-tile.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/rtc/rtc-tile.c

[PATCH 075/100] rtc: zynqmp: stop validating rtc_time in .read_time

rtc_time64_to_tm never generates an invalid tm. It is not necessary to validate it. Also, the RTC core is always calling rtc_valid_tm after the read_time callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-zynqmp.c | 2 +- 1 file changed, 1

[PATCH 075/100] rtc: zynqmp: stop validating rtc_time in .read_time

rtc_time64_to_tm never generates an invalid tm. It is not necessary to validate it. Also, the RTC core is always calling rtc_valid_tm after the read_time callback. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-zynqmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 001/100] rtc: ds1511: let the core handle invalid time

Returning a valid time when the time is invalid is a bad practice, because then userspace is not able to react on the information. Also, it doesn't make sense to return epoch because it is already the default time. Signed-off-by: Alexandre Belloni ---

[PATCH 001/100] rtc: ds1511: let the core handle invalid time

Returning a valid time when the time is invalid is a bad practice, because then userspace is not able to react on the information. Also, it doesn't make sense to return epoch because it is already the default time. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-ds1511.c | 4 1 file

Re: [PATCH v2 0/3] Directed kmem charging

On Wed, 21 Feb 2018 09:18:35 -0800 Shakeel Butt wrote: > On Wed, Feb 21, 2018 at 8:09 AM, Christopher Lameter wrote: > > Another way to solve this is to switch the user context right? > > > > Isnt it possible to avoid these patches if do the allocation in

Re: [PATCH v2 0/3] Directed kmem charging

On Wed, 21 Feb 2018 09:18:35 -0800 Shakeel Butt wrote: > On Wed, Feb 21, 2018 at 8:09 AM, Christopher Lameter wrote: > > Another way to solve this is to switch the user context right? > > > > Isnt it possible to avoid these patches if do the allocation in another > > task context instead? > > >

linux-next: Signed-off-by missing for commits in the renesas tree

Hi Simon, Commits b9f945d06b08 ("arm64: dts: renesas: Add R-Car Salvator-x M3-N support") 4cc11f95789c ("soc: renesas: rcar-sysc: Add R-Car M3-N support") are missing a Signed-off-by from their committer. -- Cheers, Stephen Rothwell pgpYcHJvUmPeC.pgp Description: OpenPGP digital

linux-next: Signed-off-by missing for commits in the renesas tree

Hi Simon, Commits b9f945d06b08 ("arm64: dts: renesas: Add R-Car Salvator-x M3-N support") 4cc11f95789c ("soc: renesas: rcar-sysc: Add R-Car M3-N support") are missing a Signed-off-by from their committer. -- Cheers, Stephen Rothwell pgpYcHJvUmPeC.pgp Description: OpenPGP digital

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

On 29.11.2017 16:41, Adrian Hunter wrote: > Define and use a blk-mq queue. Discards and flushes are processed > synchronously, but reads and writes asynchronously. In order to support > slow DMA unmapping, DMA unmapping is not done until after the next request > is started. That means the request

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

On 29.11.2017 16:41, Adrian Hunter wrote: > Define and use a blk-mq queue. Discards and flushes are processed > synchronously, but reads and writes asynchronously. In order to support > slow DMA unmapping, DMA unmapping is not done until after the next request > is started. That means the request

Re: [PATCH v2 19/19] ARM64: dts: r8a77965: Add EtherAVB device node

On Wed, Feb 21, 2018 at 08:53:53PM +0300, Sergei Shtylyov wrote: > On 02/21/2018 08:38 PM, Sergei Shtylyov wrote: ... > >> + clocks = < CPG_MOD 812>; > >> + power-domains = < 32>; > >> + resets = < 812>; > >> +

Re: [PATCH v2 0/3] Directed kmem charging

On Wed, Feb 21, 2018 at 9:57 AM, Christopher Lameter wrote: > On Wed, 21 Feb 2018, Shakeel Butt wrote: > >> On Wed, Feb 21, 2018 at 8:09 AM, Christopher Lameter wrote: >> > Another way to solve this is to switch the user context right? >> > >> > Isnt it possible

Re: [PATCH v2 19/19] ARM64: dts: r8a77965: Add EtherAVB device node

On Wed, Feb 21, 2018 at 08:53:53PM +0300, Sergei Shtylyov wrote: > On 02/21/2018 08:38 PM, Sergei Shtylyov wrote: ... > >> + clocks = < CPG_MOD 812>; > >> + power-domains = < 32>; > >> + resets = < 812>; > >> +

Re: [PATCH v2 0/3] Directed kmem charging

On Wed, Feb 21, 2018 at 9:57 AM, Christopher Lameter wrote: > On Wed, 21 Feb 2018, Shakeel Butt wrote: > >> On Wed, Feb 21, 2018 at 8:09 AM, Christopher Lameter wrote: >> > Another way to solve this is to switch the user context right? >> > >> > Isnt it possible to avoid these patches if do the

Re: [PATCH 4.9 00/77] 4.9.83-stable review

On Wed, Feb 21, 2018 at 01:48:09PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.83 release. > There are 77 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.9 00/77] 4.9.83-stable review

On Wed, Feb 21, 2018 at 01:48:09PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.83 release. > There are 77 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, Feb 21, 2018 at 01:38:35PM -0500, Alan Stern wrote: > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > On Wed, Feb 21, 2018 at 11:50:31AM -0500, Alan Stern wrote: > > > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > > > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, Feb 21, 2018 at 01:38:35PM -0500, Alan Stern wrote: > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > On Wed, Feb 21, 2018 at 11:50:31AM -0500, Alan Stern wrote: > > > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > > > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern

[PATCH v3 0/2] KVM: MSR-based features

The following series implements support within KVM for MSR-based features. The first patch creates the MSR-based feature framework used to retrieve the available MSR-based features. The second patch makes use of the framework to allow a guest to determine if the LFENCE instruction is serializing

[PATCH v3 0/2] KVM: MSR-based features

The following series implements support within KVM for MSR-based features. The first patch creates the MSR-based feature framework used to retrieve the available MSR-based features. The second patch makes use of the framework to allow a guest to determine if the LFENCE instruction is serializing

Re: [PATCH] proc: fix /proc/*/map_files lookup some more

On Wed, Feb 21, 2018 at 09:44:11PM +0300, Alexey Dobriyan wrote: > + len = strlen(str); > + if (len > 1 && *str == '0') > + return -EINVAL; if (s[0] == '0' && s[1]) please...

Re: [PATCH] proc: fix /proc/*/map_files lookup some more

On Wed, Feb 21, 2018 at 09:44:11PM +0300, Alexey Dobriyan wrote: > + len = strlen(str); > + if (len > 1 && *str == '0') > + return -EINVAL; if (s[0] == '0' && s[1]) please...

Re: [PATCH v5 2/2] mm/memcontrol.c: Reduce reclaim retries in mem_cgroup_resize_limit()

On Fri, 19 Jan 2018 16:11:18 +0100 Michal Hocko wrote: > And to be honest, I do not really see why keeping retrying from > mem_cgroup_resize_limit should be so much faster than keep retrying from > the direct reclaim path. We are doing SWAP_CLUSTER_MAX batches anyway. >

Re: [PATCH v5 2/2] mm/memcontrol.c: Reduce reclaim retries in mem_cgroup_resize_limit()

On Fri, 19 Jan 2018 16:11:18 +0100 Michal Hocko wrote: > And to be honest, I do not really see why keeping retrying from > mem_cgroup_resize_limit should be so much faster than keep retrying from > the direct reclaim path. We are doing SWAP_CLUSTER_MAX batches anyway. > mem_cgroup_resize_limit

Re: [PATCH v2 3/6] platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR variants

On Wed, Feb 21, 2018 at 7:07 PM, Enric Balletbo i Serra wrote: > Use DEVICE_ATTR variants for read/write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH v2 3/6] platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR variants

On Wed, Feb 21, 2018 at 7:07 PM, Enric Balletbo i Serra wrote: > Use DEVICE_ATTR variants for read/write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > > Signed-off-by: Enric Balletbo i Serra > --- > Changes since v1: > - New in

[PATCH v3] staging:iio:meter: Add name to function definition arguments

This patch fixes the checkpatch.pl warning: drivers/staging/iio/meter/ade7854.h:157: WARNING: function definition argument 'struct device *' should also have an identifier name... This commit adds arguments names to the signature declared in the ade7854_state struct. For consistency reason, It

[PATCH v3] staging:iio:meter: Add name to function definition arguments

This patch fixes the checkpatch.pl warning: drivers/staging/iio/meter/ade7854.h:157: WARNING: function definition argument 'struct device *' should also have an identifier name... This commit adds arguments names to the signature declared in the ade7854_state struct. For consistency reason, It

Re: [PATCH] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

Hi Evgeniy On 02/21/2018 09:57 AM, Evgeniy Didin wrote: In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have been made changes which can cause multiply overflow for 32-bit systems. Awesome, thx for quickly narrowing it down. I tried the fix and it cures my issue.

Re: [PATCH] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

Hi Evgeniy On 02/21/2018 09:57 AM, Evgeniy Didin wrote: In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have been made changes which can cause multiply overflow for 32-bit systems. Awesome, thx for quickly narrowing it down. I tried the fix and it cures my issue.

Re: [PATCH 2/2] i2c: add support for Socionext SynQuacer I2C controller

On 20 February 2018 at 19:39, Andy Shevchenko wrote: > On Tue, Feb 20, 2018 at 8:04 PM, Ard Biesheuvel > wrote: >> On 20 February 2018 at 14:02, Andy Shevchenko >> wrote: >>> On Tue, Feb 20, 2018 at 11:08 AM, Ard

Re: [PATCH 2/2] i2c: add support for Socionext SynQuacer I2C controller

On 20 February 2018 at 19:39, Andy Shevchenko wrote: > On Tue, Feb 20, 2018 at 8:04 PM, Ard Biesheuvel > wrote: >> On 20 February 2018 at 14:02, Andy Shevchenko >> wrote: >>> On Tue, Feb 20, 2018 at 11:08 AM, Ard Biesheuvel >>> wrote: > +/* SPDX-License-Identifier: GPL-2.0 */ >>> >>>

Re: [PATCH v2 08/10] gpio: Add gpio driver for Actions OWL S900 SoC

On Wed, Feb 21, 2018 at 6:00 PM, Manivannan Sadhasivam wrote: > Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers > controlling the gpio shares the same register range with pinctrl block. > > GPIO registers are organized as 6 banks and each

Re: [PATCH v2 08/10] gpio: Add gpio driver for Actions OWL S900 SoC

On Wed, Feb 21, 2018 at 6:00 PM, Manivannan Sadhasivam wrote: > Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers > controlling the gpio shares the same register range with pinctrl block. > > GPIO registers are organized as 6 banks and each bank controls the > maximum of 32

[PATCH 2/5] proc: more "unsigned int" in /proc/*/cmdline

access_remote_vm() doesn't return negative errors, it returns number of bytes read/written (0 if error occurs). This allows to delete some comparisons which never trigger. Reuse "nr_read" variable while I'm at it. Signed-off-by: Alexey Dobriyan --- fs/proc/base.c | 29

[PATCH 2/5] proc: more "unsigned int" in /proc/*/cmdline

access_remote_vm() doesn't return negative errors, it returns number of bytes read/written (0 if error occurs). This allows to delete some comparisons which never trigger. Reuse "nr_read" variable while I'm at it. Signed-off-by: Alexey Dobriyan --- fs/proc/base.c | 29

[PATCH] arm64: dts: stratix10: enable i2c, add i2c periperals

Add clock for i2c Enable i2c1 Set the i2c bus speed to 100KHz Add the following i2c peripherals * ds1339 RTC * 24c32 EEPROM * max1619 temperature monitor * ltc2497 ADC * Add a fixed regulator for the ADC's Vref. This requires Dinh Nguyen's Stratix10 clock driver ("clk: socfpga: stratix10: add

[PATCH] arm64: dts: stratix10: enable i2c, add i2c periperals

Add clock for i2c Enable i2c1 Set the i2c bus speed to 100KHz Add the following i2c peripherals * ds1339 RTC * 24c32 EEPROM * max1619 temperature monitor * ltc2497 ADC * Add a fixed regulator for the ADC's Vref. This requires Dinh Nguyen's Stratix10 clock driver ("clk: socfpga: stratix10: add

[PATCH v6 0/6] fuse: mounts from non-init user namespaces

This patchset builds on the work by Donsu Park and Seth Forshee and is reduced to the set of patches that just affect fuse. The non-fuse patches are far enough along we can ignore them except possibly for the question of when does FS_USERNS_MOUNT get set in fuse_fs_type. Fuse with a block

[PATCH v6 0/6] fuse: mounts from non-init user namespaces

This patchset builds on the work by Donsu Park and Seth Forshee and is reduced to the set of patches that just affect fuse. The non-fuse patches are far enough along we can ignore them except possibly for the question of when does FS_USERNS_MOUNT get set in fuse_fs_type. Fuse with a block

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

On 2/21/2018 9:58 AM, Greg KH wrote: On Wed, Feb 21, 2018 at 08:15:59AM -0800, Jae Hyun Yoo wrote: This commit adds driver implementation for PECI bus into linux driver framework. Signed-off-by: Jae Hyun Yoo --- Why is there no other Intel developers willing to

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

On 2/21/2018 9:58 AM, Greg KH wrote: On Wed, Feb 21, 2018 at 08:15:59AM -0800, Jae Hyun Yoo wrote: This commit adds driver implementation for PECI bus into linux driver framework. Signed-off-by: Jae Hyun Yoo --- Why is there no other Intel developers willing to review and sign off on this

[PATCH] fs/iomap: fix memory leak on error condition

If the call to is_sync_kiocb() fails an error is returned without freeing dio. Set the return code and jump to out_free_dio. Detected by CoverityScan, CID 1429424 ("Resource leak") Signed-off-by: Garry McNulty --- fs/iomap.c | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH] fs/iomap: fix memory leak on error condition

If the call to is_sync_kiocb() fails an error is returned without freeing dio. Set the return code and jump to out_free_dio. Detected by CoverityScan, CID 1429424 ("Resource leak") Signed-off-by: Garry McNulty --- fs/iomap.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Wed, Feb 21, 2018 at 11:58 AM, Luck, Tony wrote: > > How are you envisioning this rate-limiting to be implemented? Are > you going to fail an EFI call if the rate is too high? I'm thinking that > we just add a delay to each call so that we can't exceed the limit.

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Wed, Feb 21, 2018 at 11:58 AM, Luck, Tony wrote: > > How are you envisioning this rate-limiting to be implemented? Are > you going to fail an EFI call if the rate is too high? I'm thinking that > we just add a delay to each call so that we can't exceed the limit. Delaying sounds ok, I guess.

Re: [PATCH 1/3] ARC: mcip: halt GFRC together with ARC cores

Hi Eugeniy, On 02/21/2018 01:40 AM, Eugeniy Paltsev wrote: Currently GFRC is running regardless state of ARC cores in the SMP cluster. That means even if ARC cores are halted when doing JTAG debugging GFRC [our source of wall-time] continues to run giving us unexpected warnings once we allow

Re: [PATCH 1/3] ARC: mcip: halt GFRC together with ARC cores

Hi Eugeniy, On 02/21/2018 01:40 AM, Eugeniy Paltsev wrote: Currently GFRC is running regardless state of ARC cores in the SMP cluster. That means even if ARC cores are halted when doing JTAG debugging GFRC [our source of wall-time] continues to run giving us unexpected warnings once we allow

[PATCH v6 4/5] fuse: Ensure posix acls are translated outside of init_user_ns

Ensure the translation happens by failing to read or write posix acls when the filesystem has not indicated it supports posix acls. This ensures that modern cached posix acl support is available and used when dealing with posix acls. This is important because only that path has the code to

[PATCH v6 4/5] fuse: Ensure posix acls are translated outside of init_user_ns

Ensure the translation happens by failing to read or write posix acls when the filesystem has not indicated it supports posix acls. This ensures that modern cached posix acl support is available and used when dealing with posix acls. This is important because only that path has the code to

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

On 02/20/2018 04:39 PM, Bjorn Helgaas wrote: Both these patches are on my pci/sparc branch and appeared in the Feb 19 linux-next tree. Any testing and feedback (especially on the second patch, which should change /proc/iomem) would be great. They're headed for v4.17 unless I hear about

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

On 02/20/2018 04:39 PM, Bjorn Helgaas wrote: Both these patches are on my pci/sparc branch and appeared in the Feb 19 linux-next tree. Any testing and feedback (especially on the second patch, which should change /proc/iomem) would be great. They're headed for v4.17 unless I hear about

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Wed, Feb 21, 2018 at 06:58:57PM +0100, Andrea Parri wrote: > On Wed, Feb 21, 2018 at 12:15:56PM -0500, Alan Stern wrote: > > Commit bf28ae562744 ("tools/memory-model: Remove rb-dep, > > smp_read_barrier_depends, and lockless_dereference") was accidentally > > merged too early, while it was

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Wed, Feb 21, 2018 at 06:58:57PM +0100, Andrea Parri wrote: > On Wed, Feb 21, 2018 at 12:15:56PM -0500, Alan Stern wrote: > > Commit bf28ae562744 ("tools/memory-model: Remove rb-dep, > > smp_read_barrier_depends, and lockless_dereference") was accidentally > > merged too early, while it was

[PATCH] clocksource: arc_timer: update some comments

TIMER0 interrupt ACK is different for ARC700 and HS3x cores. This came to light in some internal discussions and it is nice to have this documented rather than digging up the PRM (Prog Ref Manual) again Signed-off-by: Vineet Gupta --- drivers/clocksource/arc_timer.c | 11

[PATCH] clocksource: arc_timer: update some comments

TIMER0 interrupt ACK is different for ARC700 and HS3x cores. This came to light in some internal discussions and it is nice to have this documented rather than digging up the PRM (Prog Ref Manual) again Signed-off-by: Vineet Gupta --- drivers/clocksource/arc_timer.c | 11 --- 1 file

Re: [PATCH] PCI: stop crashing in pci_release_resource v2

On Wed, Feb 21, 2018 at 11:07 AM, Christian König wrote: > Is it entirely possible that the BIOS wasn't able to assign resources to > a device. In this case don't crash in pci_release_resource() when we try > to resize the resource. > > v2: keep printing the info

Re: [PATCH] PCI: stop crashing in pci_release_resource v2

On Wed, Feb 21, 2018 at 11:07 AM, Christian König wrote: > Is it entirely possible that the BIOS wasn't able to assign resources to > a device. In this case don't crash in pci_release_resource() when we try > to resize the resource. > > v2: keep printing the info that we try to release the BAR >

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