Re: [PATCH v8 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: > From: Cyrille Pitchen > > This patch introduces support to Double Transfer Rate (DTR) SPI protocols. > DTR is used only for Fast Read operations. > > According to manufacturer datasheets, whatever the number of I/O

Re: [PATCH v8 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: > From: Cyrille Pitchen > > This patch introduces support to Double Transfer Rate (DTR) SPI protocols. > DTR is used only for Fast Read operations. > > According to manufacturer datasheets, whatever the number of I/O lines > used during instruction

Re: [PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: > From: Cyrille Pitchen > > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware

Re: [PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

On 04/25/2017 10:08 PM, Cyrille Pitchen wrote: > From: Cyrille Pitchen > > This patch changes the prototype of spi_nor_scan(): its 3rd parameter > is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor > framework about the actual hardware capabilities supported by the SPI >

Re: [v4.9-rt PATCH v2] ARM: mm: remove tasklist locking from update_sections_early()

On 04/21/2017 06:11 PM, Kees Cook wrote: On Wed, Apr 19, 2017 at 5:36 PM, Laura Abbott wrote: On 04/19/2017 01:10 PM, Grygorii Strashko wrote: The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA option enabled: BUG: sleeping function called

Re: [v4.9-rt PATCH v2] ARM: mm: remove tasklist locking from update_sections_early()

On 04/21/2017 06:11 PM, Kees Cook wrote: On Wed, Apr 19, 2017 at 5:36 PM, Laura Abbott wrote: On 04/19/2017 01:10 PM, Grygorii Strashko wrote: The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA option enabled: BUG: sleeping function called from invalid context at

[PATCH 0/3] SCSI-UFSHCD: Fine-tuning for two function implementations

From: Markus Elfring Date: Tue, 25 Apr 2017 22:20:02 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Use devm_kcalloc() in ufshcd_memory_alloc() Delete an error message for a failed memory allocation

[PATCH 0/3] SCSI-UFSHCD: Fine-tuning for two function implementations

From: Markus Elfring Date: Tue, 25 Apr 2017 22:20:02 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Use devm_kcalloc() in ufshcd_memory_alloc() Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing platform WPQ (write-pending-queue) buffers when power is removed. The nvdimm_flush() mechanism performs that same function on-demand. When a pmem namespace is

[PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing platform WPQ (write-pending-queue) buffers when power is removed. The nvdimm_flush() mechanism performs that same function on-demand. When a pmem namespace is

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 12:58:36PM -0700, Moritz Fischer wrote: > On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote: > > > Ah, I missed the "n" in various #ifndef statements. > > > > I can't really comment on how to solve that; I simply don't know. > > Also, even with a dt property,

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 12:58:36PM -0700, Moritz Fischer wrote: > On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote: > > > Ah, I missed the "n" in various #ifndef statements. > > > > I can't really comment on how to solve that; I simply don't know. > > Also, even with a dt property,

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > So the whole thing we're doing right now is

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > So the whole thing we're doing right now is

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

Hi David, On 04/25/2017 05:05 AM, David Lin wrote: > Hi Jacek, > > On Mon, Apr 24, 2017 at 12:59 PM, Jacek Anaszewski > wrote: >> >> Hi David, >> >> Thanks for the patch. >> >> Unfortunately we cannot switch to using hr timers just like that >> without introducing

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

Hi David, On 04/25/2017 05:05 AM, David Lin wrote: > Hi Jacek, > > On Mon, Apr 24, 2017 at 12:59 PM, Jacek Anaszewski > wrote: >> >> Hi David, >> >> Thanks for the patch. >> >> Unfortunately we cannot switch to using hr timers just like that >> without introducing side effects for many devices.

[PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

From: Cyrille Pitchen This patch changes the prototype of spi_nor_scan(): its 3rd parameter is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor framework about the actual hardware capabilities supported by the SPI controller and its driver.

[PATCH v8 1/4] mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols

From: Cyrille Pitchen This patch changes the prototype of spi_nor_scan(): its 3rd parameter is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor framework about the actual hardware capabilities supported by the SPI controller and its driver. Besides, this patch also

[PATCH v8 0/4] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

Hi all, based on git-hub/spi-nor. The 4 patches have passed the checkpatch test. DISCLAIMER: despite what the subjet claims, I've removed the SFDP patches from this version since they are still RFC/WIP. However I've chosen not to change the subjet line so it's easier to make the link between

[PATCH v8 0/4] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

Hi all, based on git-hub/spi-nor. The 4 patches have passed the checkpatch test. DISCLAIMER: despite what the subjet claims, I've removed the SFDP patches from this version since they are still RFC/WIP. However I've chosen not to change the subjet line so it's easier to make the link between

kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

I hit this RCU warning while running mkfs.ext4 on a PMEM namespace with an unmodified v4.11-rc8 (passed through kasan_symbolize.py): === [ ERR: suspicious RCU usage. ] 4.11.0-rc8 #1 Not tainted --- kernel/rcu/tree.c:1031 rcu_irq_enter()

kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

I hit this RCU warning while running mkfs.ext4 on a PMEM namespace with an unmodified v4.11-rc8 (passed through kasan_symbolize.py): === [ ERR: suspicious RCU usage. ] 4.11.0-rc8 #1 Not tainted --- kernel/rcu/tree.c:1031 rcu_irq_enter()

[PATCH v8 4/4] mtd: spi-nor: introduce Octo SPI protocols

From: Cyrille Pitchen This patch starts adding support to Octo SPI protocols (SPI x-y-8). Op codes for Fast Read and/or Page Program operations using Octo SPI protocols are not known yet (no JEDEC specification has defined them yet) but we'd rather introduce the Octo

[PATCH v8 4/4] mtd: spi-nor: introduce Octo SPI protocols

From: Cyrille Pitchen This patch starts adding support to Octo SPI protocols (SPI x-y-8). Op codes for Fast Read and/or Page Program operations using Octo SPI protocols are not known yet (no JEDEC specification has defined them yet) but we'd rather introduce the Octo SPI protocols now so it's

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

Hi Daniel and David, On Tue, Apr 25, 2017 at 04:41:00PM +0200, David Gstir wrote: > @@ -147,17 +148,28 @@ int fscrypt_do_page_crypto(const struct inode *inode, > fscrypt_direction_t rw, > { > struct { > __le64 index; > - u8 padding[FS_XTS_TWEAK_SIZE -

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

Hi Daniel and David, On Tue, Apr 25, 2017 at 04:41:00PM +0200, David Gstir wrote: > @@ -147,17 +148,28 @@ int fscrypt_do_page_crypto(const struct inode *inode, > fscrypt_direction_t rw, > { > struct { > __le64 index; > - u8 padding[FS_XTS_TWEAK_SIZE -

[PATCH v8 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

From: Cyrille Pitchen This patch introduces support to Double Transfer Rate (DTR) SPI protocols. DTR is used only for Fast Read operations. According to manufacturer datasheets, whatever the number of I/O lines used during instruction (x) and address/mode/dummy (y)

[PATCH v8 3/4] mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols

From: Cyrille Pitchen This patch introduces support to Double Transfer Rate (DTR) SPI protocols. DTR is used only for Fast Read operations. According to manufacturer datasheets, whatever the number of I/O lines used during instruction (x) and address/mode/dummy (y) clock cycles, DTR is used

Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt

Hi, On 25/04/2017 at 18:25:30 +0300, Alexander Kochetkov wrote: > Hello David! > > > 25 апр. 2017 г., в 17:36, David Miller написал(а): > > > > So... what are we doing here? > > > > My understanding is that this should fix the same problem that commit > >

Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt

Hi, On 25/04/2017 at 18:25:30 +0300, Alexander Kochetkov wrote: > Hello David! > > > 25 апр. 2017 г., в 17:36, David Miller написал(а): > > > > So... what are we doing here? > > > > My understanding is that this should fix the same problem that commit > >

Re: [PATCH v2] tags: honor COMPILED_SOURCE with apart output directory

Masahiro Yamada writes: > Hi Robert, >> diff --git a/scripts/tags.sh b/scripts/tags.sh >> index a2ff3388e5ea..35cb64d5211c 100755 >> --- a/scripts/tags.sh >> +++ b/scripts/tags.sh >> @@ -106,7 +106,8 @@ all_compiled_sources() >> case "$i" in >>

Re: [PATCH v2] tags: honor COMPILED_SOURCE with apart output directory

Masahiro Yamada writes: > Hi Robert, >> diff --git a/scripts/tags.sh b/scripts/tags.sh >> index a2ff3388e5ea..35cb64d5211c 100755 >> --- a/scripts/tags.sh >> +++ b/scripts/tags.sh >> @@ -106,7 +106,8 @@ all_compiled_sources() >> case "$i" in >> *.[cS]) >>

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 25, 2017 at 9:30 PM, One Thousand Gnomes wrote: > On Tue, 25 Apr 2017 15:56:32 +0200 > Jann Horn wrote: > >> On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: >> >> There could be a few user programs that would

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, Apr 25, 2017 at 9:30 PM, One Thousand Gnomes wrote: > On Tue, 25 Apr 2017 15:56:32 +0200 > Jann Horn wrote: > >> On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: >> >> There could be a few user programs that would be effected by this >> >> change. >> >> See:

Re: Revised statx(2) man page for review

On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: [...] >The file timestamps are structures of the following type: > >struct statx_timestamp { >__s64 tv_sec;/* Seconds since the Epoch (UNIX time) */ >__s32 tv_nsec;

Re: Revised statx(2) man page for review

On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: [...] >The file timestamps are structures of the following type: > >struct statx_timestamp { >__s64 tv_sec;/* Seconds since the Epoch (UNIX time) */ >__s32 tv_nsec;

[PATCH] usb: musb: don't mark of_dev_auxdata as initdata

The probe function is not __init since it can be called for deferred probing or when unbinding/rebinding the device, and therefore it must not reference objects in __initdata, as pointed out by this link time warning: WARNING: drivers/usb/musb/da8xx.o(.text+0x9d4): Section mismatch in reference

[PATCH] usb: musb: don't mark of_dev_auxdata as initdata

The probe function is not __init since it can be called for deferred probing or when unbinding/rebinding the device, and therefore it must not reference objects in __initdata, as pointed out by this link time warning: WARNING: drivers/usb/musb/da8xx.o(.text+0x9d4): Section mismatch in reference

Re: next build: 1 warnings 1 failures (next/next-20170424)

On Mon, Apr 24, 2017 at 11:58 AM, Olof's autobuilder wrote: > --- > > Errors: > > arm.allmodconfig: > ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/arm/mali-dp.ko] undefined! patch sent. > >

Re: next build: 1 warnings 1 failures (next/next-20170424)

On Mon, Apr 24, 2017 at 11:58 AM, Olof's autobuilder wrote: > --- > > Errors: > > arm.allmodconfig: > ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/arm/mali-dp.ko] undefined! patch sent. > > Warnings: > > 1

Re: [PATCH 0/4] MMC support for Octeon platforms.

On 25 April 2017 at 21:54, Ralf Baechle wrote: > On Mon, Apr 24, 2017 at 09:56:42PM +0200, Ulf Hansson wrote: > >> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer, >> unless I get an ack for it. > > Here's the Ack for patch 4: > > Acked-by: Ralf Baechle

Re: [PATCH 0/4] MMC support for Octeon platforms.

On 25 April 2017 at 21:54, Ralf Baechle wrote: > On Mon, Apr 24, 2017 at 09:56:42PM +0200, Ulf Hansson wrote: > >> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer, >> unless I get an ack for it. > > Here's the Ack for patch 4: > > Acked-by: Ralf Baechle > > Ralf Thanks,

[PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) ...and the table being unavailable until the next reboot. Add

[PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) ...and the table being unavailable until the next reboot. Add

Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6

On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote: > Hi, > I have just experienced X being shut down once with 4.11-rc2 and 2 times > with 4.11-rc6 kernel. I do not remember seeing something like this > before but it is quite possible I was just lucky to not trigger this > issue

Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6

On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote: > Hi, > I have just experienced X being shut down once with 4.11-rc2 and 2 times > with 4.11-rc6 kernel. I do not remember seeing something like this > before but it is quite possible I was just lucky to not trigger this > issue

Re: [PATCH 00/16] Intel FPGA Device Drivers

> That is where we disagree. I do not see bitstream as firmware. For instance > now you can run OpenCL on some FPGA, so this is exactly like GPU we should > request open source stack from OpenCL down to bitstream. It's an accelerator with a bunch of firmwares where you load the right one. We've

Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Tue, Apr 25, 2017 at 12:47 PM, Arnd Bergmann wrote: > > There is one global option that I want to see, and that is for completely > disabling all components that are known to be broken in y2038. I really don't see the point. Don't do it. Make it some local hack, I'm not taking

Re: [PATCH 00/16] Intel FPGA Device Drivers

> That is where we disagree. I do not see bitstream as firmware. For instance > now you can run OpenCL on some FPGA, so this is exactly like GPU we should > request open source stack from OpenCL down to bitstream. It's an accelerator with a bunch of firmwares where you load the right one. We've

Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Tue, Apr 25, 2017 at 12:47 PM, Arnd Bergmann wrote: > > There is one global option that I want to see, and that is for completely > disabling all components that are known to be broken in y2038. I really don't see the point. Don't do it. Make it some local hack, I'm not taking crazy patches.

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote: > Ah, I missed the "n" in various #ifndef statements. > > I can't really comment on how to solve that; I simply don't know. > Also, even with a dt property, it still would be necessary to have > a non-DT means to configure one or the

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote: > Ah, I missed the "n" in various #ifndef statements. > > I can't really comment on how to solve that; I simply don't know. > Also, even with a dt property, it still would be necessary to have > a non-DT means to configure one or the

Re: next-20170424 build: 1 failures 0 warnings (next-20170424)

On Mon, Apr 24, 2017 at 1:54 PM, Build bot for Mark Brown wrote: > Tree/Branch: next-20170424 > Git describe: next-20170424 > Commit: ee91aaf669 Add linux-next specific files for 20170424 > > Build Time: 116 min 41 sec > > Passed:9 / 10 ( 90.00 %) > Failed:1 / 10 (

Re: next-20170424 build: 1 failures 0 warnings (next-20170424)

On Mon, Apr 24, 2017 at 1:54 PM, Build bot for Mark Brown wrote: > Tree/Branch: next-20170424 > Git describe: next-20170424 > Commit: ee91aaf669 Add linux-next specific files for 20170424 > > Build Time: 116 min 41 sec > > Passed:9 / 10 ( 90.00 %) > Failed:1 / 10 ( 10.00 %) > >

[PATCH] drm: mali-dp: use div_u64 for expensive 64-bit divisions

On 32-bit machines, we can't divide 64-bit integers: drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check': malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod' malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined

[PATCH] drm: mali-dp: use div_u64 for expensive 64-bit divisions

On 32-bit machines, we can't divide 64-bit integers: drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check': malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod' malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined

Re: [PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

On Tue, Apr 25, 2017 at 09:02:48PM +0200, Ilia Sergachev wrote: > Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c You're going to have to split this into multiple patches. > > Signed-off-by: Ilia Sergachev > Ugh...

Re: [PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

On Tue, Apr 25, 2017 at 09:02:48PM +0200, Ilia Sergachev wrote: > Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c You're going to have to split this into multiple patches. > > Signed-off-by: Ilia Sergachev > Ugh... What kind of email address is that? > Cc:

Re: [PATCH 0/4] MMC support for Octeon platforms.

On Mon, Apr 24, 2017 at 09:56:42PM +0200, Ulf Hansson wrote: > Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer, > unless I get an ack for it. Here's the Ack for patch 4: Acked-by: Ralf Baechle Ralf

Re: [PATCH 0/4] MMC support for Octeon platforms.

On Mon, Apr 24, 2017 at 09:56:42PM +0200, Ulf Hansson wrote: > Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer, > unless I get an ack for it. Here's the Ack for patch 4: Acked-by: Ralf Baechle Ralf

[PATCH v3] usb: misc: legousbtower: Fix buffers on stack

Allocate buffers on HEAP instead of STACK for local structures that are to be received using usb_control_msg(). Signed-off-by: Maksim Salau --- Changes in v3: * rebased against usb-next; * removed Tested-by: Alfredo Rafael Vicente Boix ; *

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Tue, Apr 25, 2017 at 2:47 AM, Ryan Chen wrote: > Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as > well please ? > > About ASPEED_I2CD_M_HIGH_SPEED_EN, it is support for I2C specification "High > speed transfer". And also device need

[PATCH v3] usb: misc: legousbtower: Fix buffers on stack

Allocate buffers on HEAP instead of STACK for local structures that are to be received using usb_control_msg(). Signed-off-by: Maksim Salau --- Changes in v3: * rebased against usb-next; * removed Tested-by: Alfredo Rafael Vicente Boix ; * removed Cc: sta...@vger.kernel.org

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Tue, Apr 25, 2017 at 2:47 AM, Ryan Chen wrote: > Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as > well please ? > > About ASPEED_I2CD_M_HIGH_SPEED_EN, it is support for I2C specification "High > speed transfer". And also device need support it. > If you just

Re: [PATCH 1/2] x86/mm/ident_map: Add PUD level 1GB page support

On Tue, Apr 25, 2017 at 2:13 AM, Xunlei Pang wrote: > The current kernel_ident_mapping_init() creates the identity > mapping using 2MB page(PMD level), this patch adds the 1GB > page(PUD level) support. > > This is useful on large machines to save some reserved memory > (as

Re: [PATCH 1/2] x86/mm/ident_map: Add PUD level 1GB page support

On Tue, Apr 25, 2017 at 2:13 AM, Xunlei Pang wrote: > The current kernel_ident_mapping_init() creates the identity > mapping using 2MB page(PMD level), this patch adds the 1GB > page(PUD level) support. > > This is useful on large machines to save some reserved memory > (as paging structures) in

Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Sun, Apr 9, 2017 at 4:58 AM, Deepa Dinamani wrote: >>> Allow read only mounts for filesystems that do not >>> have maximum timestamps beyond the y2038 expiry >>> timestamp. >> >> This option seems arbitrary and pointless. >> >> Nobody sane should ever enable it except

Re: [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Sun, Apr 9, 2017 at 4:58 AM, Deepa Dinamani wrote: >>> Allow read only mounts for filesystems that do not >>> have maximum timestamps beyond the y2038 expiry >>> timestamp. >> >> This option seems arbitrary and pointless. >> >> Nobody sane should ever enable it except for testing, but for

[PATCH] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) ...and the table being unavailable until the next reboot. Add

[PATCH] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service

Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) ...and the table being unavailable until the next reboot. Add

Re: [PATCH] RFC: serial: core: Dynamic minor support

> Furthermore some other drivers rely upon the usage of a dynamic major > e.g. the tegra serial port driver. However as there is only a block of > 20 major numbers reserved for dynamic assignment that isn't going to > scale either for multiplatform kernels (I can already easily build 18 >

Re: [PATCH] RFC: serial: core: Dynamic minor support

> Furthermore some other drivers rely upon the usage of a dynamic major > e.g. the tegra serial port driver. However as there is only a block of > 20 major numbers reserved for dynamic assignment that isn't going to > scale either for multiplatform kernels (I can already easily build 18 >

Re: Revised statx(2) man page for review

Hello Silvan, On 04/25/2017 08:50 PM, Silvan Jegen wrote: > Hi Michael > > On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: >> >> [...] >> >> Could you please carefully review the text below, in case >> I added any errors. > > Just a few comments below. > > >>

Re: Revised statx(2) man page for review

Hello Silvan, On 04/25/2017 08:50 PM, Silvan Jegen wrote: > Hi Michael > > On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: >> >> [...] >> >> Could you please carefully review the text below, in case >> I added any errors. > > Just a few comments below. > > >>

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, Apr 24, 2017 at 04:35:07PM +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? Applied this with Jakub's

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, Apr 24, 2017 at 04:35:07PM +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? Applied this with Jakub's tested-by and Doug's ack to

Re: [PATCH] arm64: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()

On 04/25/2017 11:22 AM, Catalin Marinas wrote: > The dma_common_pages_remap() function allocates a vm_struct object and > initialises the pages pointer to value passed as argument. However, when > this function is called dma_common_contiguous_remap(), the pages array > is only temporarily

Re: [PATCH] arm64: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()

On 04/25/2017 11:22 AM, Catalin Marinas wrote: > The dma_common_pages_remap() function allocates a vm_struct object and > initialises the pages pointer to value passed as argument. However, when > this function is called dma_common_contiguous_remap(), the pages array > is only temporarily

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, Apr 25, 2017 at 03:29:06PM -0400, Rik van Riel wrote: > On Tue, 2017-04-25 at 10:57 -0300, Marcelo Tosatti wrote: > > The per-CPU vmstat worker is a problem on -RT workloads (because > > ideally the CPU is entirely reserved for the -RT app, without > > interference). The worker transfers

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, Apr 25, 2017 at 03:29:06PM -0400, Rik van Riel wrote: > On Tue, 2017-04-25 at 10:57 -0300, Marcelo Tosatti wrote: > > The per-CPU vmstat worker is a problem on -RT workloads (because > > ideally the CPU is entirely reserved for the -RT app, without > > interference). The worker transfers

Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains

On 25 April 2017 at 13:13, Jon Hunter wrote: > > On 28/03/17 15:13, Jon Hunter wrote: >> The current generic PM domain framework (GenDP) only allows a single >> PM domain to be associated with a given device. There are several >> use-cases for various system-on-chip devices

Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains

On 25 April 2017 at 13:13, Jon Hunter wrote: > > On 28/03/17 15:13, Jon Hunter wrote: >> The current generic PM domain framework (GenDP) only allows a single >> PM domain to be associated with a given device. There are several >> use-cases for various system-on-chip devices where it is necessary

[PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c Signed-off-by: Ilia Sergachev Cc: de...@driverdev.osuosl.org,linux-kernel@vger.kernel.org --- drivers/staging/ks7010/ks_wlan_net.c | 81

[PATCH] staging: ks7010: fix few checkpatch warnings in ks_wlan_net.c

Fixes few warnings and checks in drivers/staging/ks7010/ks_wlan_net.c Signed-off-by: Ilia Sergachev Cc: de...@driverdev.osuosl.org,linux-kernel@vger.kernel.org --- drivers/staging/ks7010/ks_wlan_net.c | 81 ++-- 1 file changed, 49 insertions(+), 32 deletions(-)

Re: [PATCH 1/1 linux-next] scripts/coccinelle/misc: Warn about NULL check on kmap()

On Tue, 25 Apr 2017, Fabian Frederick wrote: > This script removes NULL check on kmap() and all process involved > (OOM message ...) > > Thanks to Jan Kara for explanations. > > Signed-off-by: Fabian Frederick Acked-by: Julia Lawall > --- >

Re: [PATCH 1/1 linux-next] scripts/coccinelle/misc: Warn about NULL check on kmap()

On Tue, 25 Apr 2017, Fabian Frederick wrote: > This script removes NULL check on kmap() and all process involved > (OOM message ...) > > Thanks to Jan Kara for explanations. > > Signed-off-by: Fabian Frederick Acked-by: Julia Lawall > --- > scripts/coccinelle/misc/kmap.cocci | 43 >

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 25 Apr 2017 15:56:32 +0200 Jann Horn wrote: > On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: > >> There could be a few user programs that would be effected by this > >> change. > >> See:

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 25 Apr 2017 15:56:32 +0200 Jann Horn wrote: > On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: > >> There could be a few user programs that would be effected by this > >> change. > >> See: > >> notable programs are: agetty,

Re: [PATCH 1/1] PCI: check return value of pci_find_ext_capability

On Mon, Apr 24, 2017 at 01:36:58PM +0300, Mika Westerberg wrote: > On Sun, Apr 23, 2017 at 10:00:20PM +0800, Pan Bian wrote: > > From: Pan Bian > > > > Function pci_find_ext_capability() will returns 0 on failure, and its > > return value should be checked before it is used.

Re: [PATCH 1/1] PCI: check return value of pci_find_ext_capability

On Mon, Apr 24, 2017 at 01:36:58PM +0300, Mika Westerberg wrote: > On Sun, Apr 23, 2017 at 10:00:20PM +0800, Pan Bian wrote: > > From: Pan Bian > > > > Function pci_find_ext_capability() will returns 0 on failure, and its > > return value should be checked before it is used. However, in function

Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

Hi Rob, On 18 April 2017 at 13:17, Markus Mayer wrote: > From: Markus Mayer > > Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). Would you be able to have a look at this binding? The driver won't be upstreamed as hwmon driver (as per

Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

Hi Rob, On 18 April 2017 at 13:17, Markus Mayer wrote: > From: Markus Mayer > > Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). Would you be able to have a look at this binding? The driver won't be upstreamed as hwmon driver (as per Guenter's comments). I am currently

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 2017-04-25 at 10:57 -0300, Marcelo Tosatti wrote: > The per-CPU vmstat worker is a problem on -RT workloads (because > ideally the CPU is entirely reserved for the -RT app, without > interference). The worker transfers accumulated per-CPU  > vmstat counters to global counters. > > To

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 2017-04-25 at 10:57 -0300, Marcelo Tosatti wrote: > The per-CPU vmstat worker is a problem on -RT workloads (because > ideally the CPU is entirely reserved for the -RT app, without > interference). The worker transfers accumulated per-CPU  > vmstat counters to global counters. > > To

Re: [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"

On Tue, 2017-04-25 at 14:04 -0500, Bjorn Helgaas wrote: > On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote: > > From: Colin Ian King > > > > trivial fix to spelling mistake in dev_err message > > > > Signed-off-by: Colin Ian King >

Re: [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"

On Tue, 2017-04-25 at 14:04 -0500, Bjorn Helgaas wrote: > On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote: > > From: Colin Ian King > > > > trivial fix to spelling mistake in dev_err message > > > > Signed-off-by: Colin Ian King > > Applied with Richard's ack to pci/host-imx6 for

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

El Tue, Apr 25, 2017 at 07:06:30PM +0100 Ard Biesheuvel ha dit: > On 25 April 2017 at 18:39, Matthias Kaehlcke wrote: > > Hi, > > > > El Tue, Apr 18, 2017 at 04:35:02PM +0100 Ard Biesheuvel ha dit: > > > >> On 18 April 2017 at 15:47, Paul Gortmaker

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

El Tue, Apr 25, 2017 at 07:06:30PM +0100 Ard Biesheuvel ha dit: > On 25 April 2017 at 18:39, Matthias Kaehlcke wrote: > > Hi, > > > > El Tue, Apr 18, 2017 at 04:35:02PM +0100 Ard Biesheuvel ha dit: > > > >> On 18 April 2017 at 15:47, Paul Gortmaker > >> wrote: > >> > On Wed, Apr 5, 2017 at

Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings

On Sun, 2017-03-26 at 10:45 +0200, Geert Uytterhoeven wrote: > Hi Doug, > > On Sat, Mar 25, 2017 at 3:40 AM, Doug Ledford > wrote: > > > > On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote: > > > > > > Submitters of device tree binding documentation may forget to

Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings

On Sun, 2017-03-26 at 10:45 +0200, Geert Uytterhoeven wrote: > Hi Doug, > > On Sat, Mar 25, 2017 at 3:40 AM, Doug Ledford > wrote: > > > > On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote: > > > > > > Submitters of device tree binding documentation may forget to CC > > > the

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