Re: [PATCH 12/17] tty: New RISC-V SBI Console Driver

On Wed, 07 Jun 2017 00:58:04 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:15 AM, Geert Uytterhoeven > wrote: >> CC (hypervisor) console folks >> >> On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt wrote: >>> This patch adds a new driver

Re: [PATCH 12/17] tty: New RISC-V SBI Console Driver

On Wed, 07 Jun 2017 00:58:04 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:15 AM, Geert Uytterhoeven > wrote: >> CC (hypervisor) console folks >> >> On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt wrote: >>> This patch adds a new driver for the console availiable via the RISC-V

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote: > On Thu, Jun 22, 2017 at 6:52 PM, Greg Kroah-Hartman > wrote: > > On Thu, Jun 22, 2017 at 10:50:43AM -0700, Kees Cook wrote: > >> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote: > On Thu, Jun 22, 2017 at 6:52 PM, Greg Kroah-Hartman > wrote: > > On Thu, Jun 22, 2017 at 10:50:43AM -0700, Kees Cook wrote: > >> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski wrote: > >> > On Thu, Jun 22, 2017 at 10:09 AM,

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote: > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote: > > All ACPI device notify callbacks are invoked using acpi_os_execute(), > > which causes the supplied callback to be queued to a static workqueue > > which always executes

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote: > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote: > > All ACPI device notify callbacks are invoked using acpi_os_execute(), > > which causes the supplied callback to be queued to a static workqueue > > which always executes

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 05:34:23PM -0600, Andreas Dilger wrote: > > Sure, but that is a problem independent of the readdir case I think? This is lookup case not the readdir case > Wouldn't it just make sense to mount the filesystem with "errors=remount-ro" > or "errors=panic" in your case,

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 05:34:23PM -0600, Andreas Dilger wrote: > > Sure, but that is a problem independent of the readdir case I think? This is lookup case not the readdir case > Wouldn't it just make sense to mount the filesystem with "errors=remount-ro" > or "errors=panic" in your case,

Re: linux-next: BUG: Bad page state in process ip6tables-save pfn:1499f4

42082] Modules linked in: [ 337.342089] CPU: 1 PID: 22242 Comm: criu Not tainted 4.12.0-rc6-next-20170623 #1 [ 337.342091] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 337.342094] Call Trace: [ 337.342106] dump_stack+0x85/0xc7 [ 337.342113]

Re: linux-next: BUG: Bad page state in process ip6tables-save pfn:1499f4

42082] Modules linked in: [ 337.342089] CPU: 1 PID: 22242 Comm: criu Not tainted 4.12.0-rc6-next-20170623 #1 [ 337.342091] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 337.342094] Call Trace: [ 337.342106] dump_stack+0x85/0xc7 [ 337.342113]

Re: [PATCH v5] fscrypt: Add support for AES-128-CBC

On Mon, Jun 19, 2017 at 09:27:58AM +0200, David Gstir wrote: > From: Daniel Walter > > fscrypt provides facilities to use different encryption algorithms which > are selectable by userspace when setting the encryption policy. Currently, > only AES-256-XTS for file contents

Re: [PATCH v5] fscrypt: Add support for AES-128-CBC

On Mon, Jun 19, 2017 at 09:27:58AM +0200, David Gstir wrote: > From: Daniel Walter > > fscrypt provides facilities to use different encryption algorithms which > are selectable by userspace when setting the encryption policy. Currently, > only AES-256-XTS for file contents and AES-256-CBC-CTS

[PATCH v2 3/5] PCI / PM: Drop pme_interrupt flag from struct pci_dev

From: Rafael J. Wysocki The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which

[PATCH v2 3/5] PCI / PM: Drop pme_interrupt flag from struct pci_dev

From: Rafael J. Wysocki The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which returns as soon as it sees

[PATCH v2 5/5] PM / core: Drop run_wake flag from struct dev_pm_info

From: Rafael J. Wysocki The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system

[PATCH v2 5/5] PM / core: Drop run_wake flag from struct dev_pm_info

From: Rafael J. Wysocki The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system wakeup signaling has always been

[PATCH v2 2/5] ACPI / PM: Consolidate device wakeup settings code

From: Rafael J. Wysocki Currently, there are two separate ways of handling device wakeup settings in the ACPI core, depending on whether this is runtime wakeup or system wakeup (from sleep states). However, after the previous commit eliminating the run_wake ACPI

[PATCH v2 2/5] ACPI / PM: Consolidate device wakeup settings code

From: Rafael J. Wysocki Currently, there are two separate ways of handling device wakeup settings in the ACPI core, depending on whether this is runtime wakeup or system wakeup (from sleep states). However, after the previous commit eliminating the run_wake ACPI device wakeup flag, there is no

[PATCH v2 4/5] PCI / PM: Simplify device wakeup settings code

From: Rafael J. Wysocki After previous changes it is not necessary to distinguish between device wakeup for run time and device wakeup from system sleep states any more, so rework the PCI device wakeup settings code accordingly. Signed-off-by: Rafael J. Wysocki

[PATCH v2 4/5] PCI / PM: Simplify device wakeup settings code

From: Rafael J. Wysocki After previous changes it is not necessary to distinguish between device wakeup for run time and device wakeup from system sleep states any more, so rework the PCI device wakeup settings code accordingly. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg

[PATCH v2 1/5] ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags

From: Rafael J. Wysocki The run_wake flag in struct acpi_device_wakeup_flags stores the information on whether or not the device can generate wakeup signals at run time, but in ACPI that really is equivalent to being able to generate wakeup signals at all. In fact,

[PATCH v2 0/5] PM: Unify the handling of device wakeup settings

On Monday, June 19, 2017 11:31:58 PM Rafael J. Wysocki wrote: > Hi All, > > The handling of device wakeup settings, especially in the ACPI core and the > PCI > bus type, depends on whether it is about system wakeup from sleep states or > remote wakeup in the working state (runtime). However,

[PATCH v2 1/5] ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags

From: Rafael J. Wysocki The run_wake flag in struct acpi_device_wakeup_flags stores the information on whether or not the device can generate wakeup signals at run time, but in ACPI that really is equivalent to being able to generate wakeup signals at all. In fact, run_wake will always be set

[PATCH v2 0/5] PM: Unify the handling of device wakeup settings

On Monday, June 19, 2017 11:31:58 PM Rafael J. Wysocki wrote: > Hi All, > > The handling of device wakeup settings, especially in the ACPI core and the > PCI > bus type, depends on whether it is about system wakeup from sleep states or > remote wakeup in the working state (runtime). However,

Re: [PATCH V5 Resend] PM / OPP: Use - instead of @ for DT entries

On Thursday, June 22, 2017 09:15:11 AM Viresh Kumar wrote: > Compiling the DT file with W=1, DTC warns like follows: > > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a > unit name, but no reg property > > Fix this by replacing '@' with '-' as the OPP nodes will never have a

Re: [PATCH V5 Resend] PM / OPP: Use - instead of @ for DT entries

On Thursday, June 22, 2017 09:15:11 AM Viresh Kumar wrote: > Compiling the DT file with W=1, DTC warns like follows: > > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a > unit name, but no reg property > > Fix this by replacing '@' with '-' as the OPP nodes will never have a

Re: [PATCH 0/3] Enable namespaced file capabilities

On 6/23/2017 4:09 PM, Stefan Berger wrote: > On 06/23/2017 02:35 PM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stef...@linux.vnet.ibm.com): >>> On 06/23/2017 12:16 PM, Casey Schaufler wrote: On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: > Quoting Amir Goldstein (amir7...@gmail.com):

Re: [PATCH 0/3] Enable namespaced file capabilities

On 6/23/2017 4:09 PM, Stefan Berger wrote: > On 06/23/2017 02:35 PM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stef...@linux.vnet.ibm.com): >>> On 06/23/2017 12:16 PM, Casey Schaufler wrote: On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: > Quoting Amir Goldstein (amir7...@gmail.com):

Re: [PATCH 3/3] Enable security.selinux in user namespaces

On 06/23/2017 04:30 PM, Stephen Smalley wrote: On Thu, 2017-06-22 at 14:59 -0400, Stefan Berger wrote: Before the current modifications, SELinux extended attributes were visible inside the user namespace but changes in patch 1 hid them. This patch enables security.selinux in user namespaces and

Re: [PATCH 3/3] Enable security.selinux in user namespaces

On 06/23/2017 04:30 PM, Stephen Smalley wrote: On Thu, 2017-06-22 at 14:59 -0400, Stefan Berger wrote: Before the current modifications, SELinux extended attributes were visible inside the user namespace but changes in patch 1 hid them. This patch enables security.selinux in user namespaces and

[PATCH] firmware: wake all waiters

Multiple devices may be waiting for firmware with the same name. In that case we will make them all use the same struct firmware_buf. When wake up happens make sure it's propagated to all of them. Signed-off-by: Jakub Kicinski --- drivers/base/firmware_class.c | 2

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Sat, 24 Jun 2017, Frans Klaver wrote: > Hm. For some reason the great mail filtering scheme decided to push > this past my inbox :-/ > > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: > >> The header field in

[PATCH] firmware: wake all waiters

Multiple devices may be waiting for firmware with the same name. In that case we will make them all use the same struct firmware_buf. When wake up happens make sure it's propagated to all of them. Signed-off-by: Jakub Kicinski --- drivers/base/firmware_class.c | 2 +- 1 file changed, 1

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

On Sat, 24 Jun 2017, Frans Klaver wrote: > Hm. For some reason the great mail filtering scheme decided to push > this past my inbox :-/ > > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: > >> The header field in struct pd_message

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Jun 23, 2017, at 5:26 PM, Theodore Ts'o wrote: > > On Fri, Jun 23, 2017 at 03:33:46PM -0700, Khazhismel Kumykov wrote: >> >> Giving up early or checking future blocks both work, critical thing >> here is not returning NULL after seeing a read error. >> Previously to this the

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Jun 23, 2017, at 5:26 PM, Theodore Ts'o wrote: > > On Fri, Jun 23, 2017 at 03:33:46PM -0700, Khazhismel Kumykov wrote: >> >> Giving up early or checking future blocks both work, critical thing >> here is not returning NULL after seeing a read error. >> Previously to this the behavior was to

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 03:33:46PM -0700, Khazhismel Kumykov wrote: > > Giving up early or checking future blocks both work, critical thing > here is not returning NULL after seeing a read error. > Previously to this the behavior was to continue to check future blocks > after a read error, and it

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 03:33:46PM -0700, Khazhismel Kumykov wrote: > > Giving up early or checking future blocks both work, critical thing > here is not returning NULL after seeing a read error. > Previously to this the behavior was to continue to check future blocks > after a read error, and it

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Wed, 07 Jun 2017 00:35:04 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 10:53 PM, Palmer Dabbelt wrote: >> On Tue, 06 Jun 2017 02:31:02 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: On Fri,

Re: [PATCH 5/7] RISC-V: arch/riscv/lib

On Wed, 07 Jun 2017 00:35:04 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 10:53 PM, Palmer Dabbelt wrote: >> On Tue, 06 Jun 2017 02:31:02 PDT (-0700), Arnd Bergmann wrote: >>> On Tue, Jun 6, 2017 at 6:56 AM, Palmer Dabbelt wrote: On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

On Wed, 07 Jun 2017 00:25:37 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:12 AM, Geert Uytterhoeven > wrote: >> CC clocksource folks >> >> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: >>> The RISC-V ISA defines a single RTC as

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

On Wed, 07 Jun 2017 00:25:37 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 9:12 AM, Geert Uytterhoeven > wrote: >> CC clocksource folks >> >> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: >>> The RISC-V ISA defines a single RTC as well as an SBI oneshot timer. >>> This

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote: > > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch > series and I'm happy we have finally landed on it. Yes, indeed the new API > proposed here provides more flexibility, and it does so by

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote: > > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch > series and I'm happy we have finally landed on it. Yes, indeed the new API > proposed here provides more flexibility, and it does so by embracing a > "data

Re: [PATCH 0/3] Enable namespaced file capabilities

On 06/23/2017 02:35 PM, Serge E. Hallyn wrote: Quoting Stefan Berger (stef...@linux.vnet.ibm.com): On 06/23/2017 12:16 PM, Casey Schaufler wrote: On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: Quoting Amir Goldstein (amir7...@gmail.com): On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger

Re: [PATCH 0/3] Enable namespaced file capabilities

On 06/23/2017 02:35 PM, Serge E. Hallyn wrote: Quoting Stefan Berger (stef...@linux.vnet.ibm.com): On 06/23/2017 12:16 PM, Casey Schaufler wrote: On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: Quoting Amir Goldstein (amir7...@gmail.com): On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger wrote:

[GIT PULL] Please pull powerpc/linux.git powerpc-4.12-7 tag

Hi Linus, Please pull some more powerpc fixes for 4.12. Most of these actually came in last week but got held up for some more testing. The following changes since commit a093c92dc7f96a15de98ec8cfe38e6f7610a5969: powerpc/debug: Add missing warn flag to WARN_ON's non-builtin path (2017-06-16

[GIT PULL] Please pull powerpc/linux.git powerpc-4.12-7 tag

Hi Linus, Please pull some more powerpc fixes for 4.12. Most of these actually came in last week but got held up for some more testing. The following changes since commit a093c92dc7f96a15de98ec8cfe38e6f7610a5969: powerpc/debug: Add missing warn flag to WARN_ON's non-builtin path (2017-06-16

Re: New NTB API Issue

On 23/06/17 04:06 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> But any translation can be >> programmed by any peer. > > That doesn't seem safe. Even though it can be done as you say, would it not > be better to have each specific translation under the control of exactly one > driver? >

Re: New NTB API Issue

On 23/06/17 04:06 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> But any translation can be >> programmed by any peer. > > That doesn't seem safe. Even though it can be done as you say, would it not > be better to have each specific translation under the control of exactly one > driver? >

[PATCH] iio: dac: DS4424: add Maxim DS4422/DS4424 DAC driver support

From: "Ismail H. Kose" Add iio driver for DS4422/DS4424 chips that support two/four channel 7-bit Sink/Source Current DAC. The driver supports device tree and platfrom files for the configurations. Datasheet publicly available at:

[PATCH] iio: dac: DS4424: add Maxim DS4422/DS4424 DAC driver support

From: "Ismail H. Kose" Add iio driver for DS4422/DS4424 chips that support two/four channel 7-bit Sink/Source Current DAC. The driver supports device tree and platfrom files for the configurations. Datasheet publicly available at: https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 11:59:36PM +0800, Greg KH wrote: > On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote: > > You may argue that *one* upstream users is not sufficient to introduce a new > > feature for, but I disagree given we have had new full *API* added for a new > >

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 11:59:36PM +0800, Greg KH wrote: > On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote: > > You may argue that *one* upstream users is not sufficient to introduce a new > > feature for, but I disagree given we have had new full *API* added for a new > >

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 11:51:23PM +0800, Greg KH wrote: > On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote: > > > I agree, that's what I'm saying here. I just do not see that happening > > > with your patch set at all. It's adding more code, a more complex way > > > to interact

Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Fri, Jun 23, 2017 at 11:51:23PM +0800, Greg KH wrote: > On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote: > > > I agree, that's what I'm saying here. I just do not see that happening > > > with your patch set at all. It's adding more code, a more complex way > > > to interact

Re: [PATCH] Staging: wlan-ng: hfa384x_usb: Fixed sparse warning cast to restricted __le16

On Fri, Jun 16, 2017 at 12:05 PM, Jaya Durga wrote: > when building with make C=1 CF=-D__CHECK_ENDIAN__ > > drivers/staging/wlan-ng/hfa384x_usb.c:3383:36: warning: cast to restricted > __le16 > > fixed by using the le16_to_cpus function. > > Signed-off-by: Jaya Durga

Re: [PATCH] Staging: wlan-ng: hfa384x_usb: Fixed sparse warning cast to restricted __le16

On Fri, Jun 16, 2017 at 12:05 PM, Jaya Durga wrote: > when building with make C=1 CF=-D__CHECK_ENDIAN__ > > drivers/staging/wlan-ng/hfa384x_usb.c:3383:36: warning: cast to restricted > __le16 > > fixed by using the le16_to_cpus function. > > Signed-off-by: Jaya Durga > --- >

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

On Sat, Jun 24, 2017 at 12:12:49AM +0200, Thomas Gleixner wrote: > On Fri, 23 Jun 2017, Brian Norris wrote: > > > This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18. > > > > It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1: > > > > [ 7226.716713] BUG: sleeping

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

On Sat, Jun 24, 2017 at 12:12:49AM +0200, Thomas Gleixner wrote: > On Fri, 23 Jun 2017, Brian Norris wrote: > > > This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18. > > > > It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1: > > > > [ 7226.716713] BUG: sleeping

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Russell,Daniel and Kees, I am attaching the latest patch with this mail. It included support for BPF_CALL | BPF_JMP tested with and without constant blinding on ARMv7 machine. Due to the limitation on my machine I can't test the tail call. It would be a great help if any of you could help me

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Russell,Daniel and Kees, I am attaching the latest patch with this mail. It included support for BPF_CALL | BPF_JMP tested with and without constant blinding on ARMv7 machine. Due to the limitation on my machine I can't test the tail call. It would be a great help if any of you could help me

[PATCH] i2c: tvp5150: remove useless variable assignment in tvp5150_set_vbi()

Value assigned to variable _type_ at line 678 is overwritten at line 688 before it can be used. This makes such variable assignment useless. Remove this variable assignment and fix some coding style issues. Addresses-Coverity-ID: 1226968 Signed-off-by: Gustavo A. R. Silva

[PATCH] i2c: tvp5150: remove useless variable assignment in tvp5150_set_vbi()

Value assigned to variable _type_ at line 678 is overwritten at line 688 before it can be used. This makes such variable assignment useless. Remove this variable assignment and fix some coding style issues. Addresses-Coverity-ID: 1226968 Signed-off-by: Gustavo A. R. Silva ---

Re: [PATCH v2 0/3] rtc: make st-lpc robust against y2038/2106 bug

Hi Alexandre, On 06/23/2017 04:09 PM, Alexandre Belloni wrote: > On 23/06/2017 at 13:40:41 -0600, Shuah Khan wrote: >> On 06/19/2017 03:36 AM, Benjamin Gaignard wrote: >>> On 32bits platforms "struct timeval" or "time_t" are using u32 to code the >>> date, this cause tools like "date" or

Re: [PATCH v2 0/3] rtc: make st-lpc robust against y2038/2106 bug

Hi Alexandre, On 06/23/2017 04:09 PM, Alexandre Belloni wrote: > On 23/06/2017 at 13:40:41 -0600, Shuah Khan wrote: >> On 06/19/2017 03:36 AM, Benjamin Gaignard wrote: >>> On 32bits platforms "struct timeval" or "time_t" are using u32 to code the >>> date, this cause tools like "date" or

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 2:36 PM, Andreas Dilger wrote: > On Jun 23, 2017, at 6:26 AM, Theodore Ts'o wrote: >> >> The problem is that if we continue, successive reads may all take >> seconds or minutes to fail, thus tieing up the process for a long >> time. > >

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

On Fri, Jun 23, 2017 at 2:36 PM, Andreas Dilger wrote: > On Jun 23, 2017, at 6:26 AM, Theodore Ts'o wrote: >> >> The problem is that if we continue, successive reads may all take >> seconds or minutes to fail, thus tieing up the process for a long >> time. > > Sorry, I don't understand where the

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

Hm. For some reason the great mail filtering scheme decided to push this past my inbox :-/ On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: >> The header field in struct pd_message is declared as an __le16 type. The

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

Hm. For some reason the great mail filtering scheme decided to push this past my inbox :-/ On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches wrote: > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote: >> The header field in struct pd_message is declared as an __le16 type. The >> data in the

Re: [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On Fri, Jun 23, 2017 at 06:03:37PM +0100, James Morse wrote: > Hi Yury, > > On 04/06/17 13:00, Yury Norov wrote: > > ILP32 has context-related structures different from both aarch32 and > > aarch64/lp64. In this patch compat_arch_ptrace() renamed to > > compat_a32_ptrace(), and

Re: [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On Fri, Jun 23, 2017 at 06:03:37PM +0100, James Morse wrote: > Hi Yury, > > On 04/06/17 13:00, Yury Norov wrote: > > ILP32 has context-related structures different from both aarch32 and > > aarch64/lp64. In this patch compat_arch_ptrace() renamed to > > compat_a32_ptrace(), and

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/23/2017 01:59 PM, H. Nikolaus Schaller wrote: > Hi Suman, > >> Am 23.06.2017 um 20:05 schrieb Suman Anna : >> > > Or does it just mean that it defines the property name? Please read the documentation link I sent - it's in the very bottom and should have

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/23/2017 01:59 PM, H. Nikolaus Schaller wrote: > Hi Suman, > >> Am 23.06.2017 um 20:05 schrieb Suman Anna : >> > > Or does it just mean that it defines the property name? Please read the documentation link I sent - it's in the very bottom and should have an example.

Re: [PATCH RESEND 13/13] platform/chrome: cros_ec_lightbar - Avoid I2C xfer to EC during suspend

Hi Enric, On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Jeffery Yu > > A Mutex lock in cros_ec_cmd_xfer which may be held by frozen > Userspace thread during system suspending. So should not > call this routine in suspend thread. > > Signed-off-by: Jeffery

Re: [PATCH RESEND 13/13] platform/chrome: cros_ec_lightbar - Avoid I2C xfer to EC during suspend

Hi Enric, On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Jeffery Yu > > A Mutex lock in cros_ec_cmd_xfer which may be held by frozen > Userspace thread during system suspending. So should not > call this routine in suspend thread. > > Signed-off-by: Jeffery Yu > Signed-off-by:

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > + if (set_memory_np(decoy_addr, 1)) > > > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", Another concept to consider is mapping the page as UC rather than completely unmapping it. The uncorrectable error scope could be smaller than a page size, like: * memory ECC width

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > + if (set_memory_np(decoy_addr, 1)) > > > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", Another concept to consider is mapping the page as UC rather than completely unmapping it. The uncorrectable error scope could be smaller than a page size, like: * memory ECC width

Re: [PATCH v2 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation

On Wed, Jun 21, 2017 at 03:23:03PM +0800, Baolin Wang wrote: > This patch adds the binding documentation for Spreadtrum I2C > controller device. > > Signed-off-by: Baolin Wang > --- > Changes since v1: > - No updates. > --- >

Re: [PATCH v2 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation

On Wed, Jun 21, 2017 at 03:23:03PM +0800, Baolin Wang wrote: > This patch adds the binding documentation for Spreadtrum I2C > controller device. > > Signed-off-by: Baolin Wang > --- > Changes since v1: > - No updates. > --- > Documentation/devicetree/bindings/i2c/i2c-sprd.txt | 31 >

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

On Fri, 23 Jun 2017, Brian Norris wrote: > This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18. > > It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1: > > [ 7226.716713] BUG: sleeping function called from invalid context at > kernel/locking/mutex.c:238 > [

Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"

On Fri, 23 Jun 2017, Brian Norris wrote: > This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18. > > It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1: > > [ 7226.716713] BUG: sleeping function called from invalid context at > kernel/locking/mutex.c:238 > [

Re: [PATCH RESEND 12/13] platform/chrome: cros_ec_lightbar - Add userspace lightbar control bit to EC

Hi Enric, Looks good. On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Eric Caruso > > Some devices might want to turn off the lightbar if e.g. the > system turns the screen off due to idleness. This prevents the > kernel from going through its normal

Re: [PATCH RESEND 12/13] platform/chrome: cros_ec_lightbar - Add userspace lightbar control bit to EC

Hi Enric, Looks good. On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Eric Caruso > > Some devices might want to turn off the lightbar if e.g. the > system turns the screen off due to idleness. This prevents the > kernel from going through its normal suspend/resume pathways. > >

[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

We wanted to add RISC-V to the list of architectures that used the generic PCI setup-irq.o inside the Makefile and it was suggested that instead we define a Kconfig entry and use that. I've done very minimal testing on this: I just checked to see that an aarch64 defconfig still build setup-irq.o

[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

We wanted to add RISC-V to the list of architectures that used the generic PCI setup-irq.o inside the Makefile and it was suggested that instead we define a Kconfig entry and use that. I've done very minimal testing on this: I just checked to see that an aarch64 defconfig still build setup-irq.o

Re: [PATCH v2 0/3] rtc: make st-lpc robust against y2038/2106 bug

On 23/06/2017 at 13:40:41 -0600, Shuah Khan wrote: > On 06/19/2017 03:36 AM, Benjamin Gaignard wrote: > > On 32bits platforms "struct timeval" or "time_t" are using u32 to code the > > date, this cause tools like "date" or "hwclock" failed even before setting > > the RTC device if the date is

Re: [PATCH v2 0/3] rtc: make st-lpc robust against y2038/2106 bug

On 23/06/2017 at 13:40:41 -0600, Shuah Khan wrote: > On 06/19/2017 03:36 AM, Benjamin Gaignard wrote: > > On 32bits platforms "struct timeval" or "time_t" are using u32 to code the > > date, this cause tools like "date" or "hwclock" failed even before setting > > the RTC device if the date is

Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

On Fri, 23 Jun 2017 15:01:04 PDT (-0700), james.ho...@imgtec.com wrote: > On Fri, Jun 23, 2017 at 02:45:38PM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 4c1a35f15838..86872246951c 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -96,6

Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

On Fri, 23 Jun 2017 15:01:04 PDT (-0700), james.ho...@imgtec.com wrote: > On Fri, Jun 23, 2017 at 02:45:38PM -0700, Palmer Dabbelt wrote: >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 4c1a35f15838..86872246951c 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -96,6

Re: [PATCH RESEND 11/13] platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar sequence

Hi Enric, On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Eric Caruso > > Don't let EC control suspend/resume sequence. If the EC controls the > lightbar and sets the sequence when it notices the chipset transitioning > between states, we can't make

Re: [PATCH RESEND 11/13] platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar sequence

Hi Enric, On 05/16/2017 09:13 AM, Enric Balletbo i Serra wrote: > From: Eric Caruso > > Don't let EC control suspend/resume sequence. If the EC controls the > lightbar and sets the sequence when it notices the chipset transitioning > between states, we can't make exceptions for cases where we

RE: New NTB API Issue

From: Logan Gunthorpe > But any translation can be > programmed by any peer. That doesn't seem safe. Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver? If drivers can reach across and set the translation of

RE: New NTB API Issue

From: Logan Gunthorpe > But any translation can be > programmed by any peer. That doesn't seem safe. Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver? If drivers can reach across and set the translation of

Re: [PATCH] qla2xxx: Protect access to qpair members with qpair->qp_lock

hub.com/0day-ci/linux/commits/Johannes-Thumshirn/qla2xxx-Protec >t-access-to-qpair-members-with-qpair-qp_lock/20170623-123844 >base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git >for-next >:: branch date: 3 hours ago >:: commit date: 3 hours ago > >>&g

Re: [PATCH] qla2xxx: Protect access to qpair members with qpair->qp_lock

NG on scsi/for-next] >[also build test WARNING on v4.12-rc6 next-20170622] >[if your patch is applied to the wrong git tree, please drop us a note to >help improve the system] > >url: >https://github.com/0day-ci/linux/commits/Johannes-Thumshirn/qla2xxx-Protec >t-access-to-qpair-membe

mmotm 2017-06-23-15-03 uploaded

The mm-of-the-moment snapshot 2017-06-23-15-03 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2017-06-23-15-03 uploaded

The mm-of-the-moment snapshot 2017-06-23-15-03 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

RE: New NTB API Issue

From: Logan Gunthorpe > Hey, > > Thanks Serge for the detailed explanation. This is pretty much exactly > as I had thought it should be interpreted. My only problem remains that > my hardware can't provide ntb_mw_get_align until the port it is asking > about has configured itself. The easiest way

RE: New NTB API Issue

From: Logan Gunthorpe > Hey, > > Thanks Serge for the detailed explanation. This is pretty much exactly > as I had thought it should be interpreted. My only problem remains that > my hardware can't provide ntb_mw_get_align until the port it is asking > about has configured itself. The easiest way

<    1   2   3   4   5   6   7   8   9   10   >