Re: [PATCH] arm64: do not set dma masks that device connection can't handle

Hello! On 1/6/2017 5:45 PM, Nikita Yushchenko wrote: It is possible that device is capable of 64-bit DMA addresses, and device driver tries to set wide DMA mask, but bridge or bus used to connect device to the system can't handle wide addresses. With swiotlb, memory above 4G still can be used

Re: [PATCH] arm64: do not set dma masks that device connection can't handle

Hello! On 1/6/2017 5:45 PM, Nikita Yushchenko wrote: It is possible that device is capable of 64-bit DMA addresses, and device driver tries to set wide DMA mask, but bridge or bus used to connect device to the system can't handle wide addresses. With swiotlb, memory above 4G still can be used

Re: [PATCH] mm: stop leaking PageTables

Hugh Dickins writes: > 4.10-rc loadtest (even on x86, even without THPCache) fails with > "fork: Cannot allocate memory" or some such; and /proc/meminfo > shows PageTables growing. > > rc1 removed the freeing of an unused preallocated pagetable after > do_fault_around() has

Re: [PATCH] mm: stop leaking PageTables

Hugh Dickins writes: > 4.10-rc loadtest (even on x86, even without THPCache) fails with > "fork: Cannot allocate memory" or some such; and /proc/meminfo > shows PageTables growing. > > rc1 removed the freeing of an unused preallocated pagetable after > do_fault_around() has called map_pages():

Re: [PATCH v2 2/4] linux/const.h: move UL() macro to include/linux/const.h

Hi. 2017-01-06 19:45 GMT+09:00 David Howells : > Masahiro Yamada wrote: > >> diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h >> index c872bfd..76fb0f9 100644 >> --- a/include/uapi/linux/const.h >> +++

Re: [PATCH v2 2/4] linux/const.h: move UL() macro to include/linux/const.h

Hi. 2017-01-06 19:45 GMT+09:00 David Howells : > Masahiro Yamada wrote: > >> diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h >> index c872bfd..76fb0f9 100644 >> --- a/include/uapi/linux/const.h >> +++ b/include/uapi/linux/const.h >> @@ -1,7 +1,7 @@ >> /* const.h: Macros for

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Chanwoo, > >> >> >>> + touchkey@20 { > >> >> >>> + compatible = "samsung,tm2-touchkey"; > >> >> >>> + reg = <0x20>; > >> >> >>> + interrupt-parent = <>; > >> >> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; > >> >> >>> +

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Chanwoo, > >> >> >>> + touchkey@20 { > >> >> >>> + compatible = "samsung,tm2-touchkey"; > >> >> >>> + reg = <0x20>; > >> >> >>> + interrupt-parent = <>; > >> >> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; > >> >> >>> +

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Andi, 2017-01-08 14:45 GMT+09:00 Andi Shyti : > Hi Chanwoo, > >> >> >>> + touchkey@20 { >> >> >>> + compatible = "samsung,tm2-touchkey"; >> >> >>> + reg = <0x20>; >> >> >>> + interrupt-parent = <>; >> >> >>> +

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Andi, 2017-01-08 14:45 GMT+09:00 Andi Shyti : > Hi Chanwoo, > >> >> >>> + touchkey@20 { >> >> >>> + compatible = "samsung,tm2-touchkey"; >> >> >>> + reg = <0x20>; >> >> >>> + interrupt-parent = <>; >> >> >>> + interrupts = <2

Re: [V9fs-developer] 9pfs hangs since 4.7

On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote: > On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote: > > > released) simply trigger virtio_queue_notify_vq() again? It *is* a bug > > (if we get a burst filling a previously empty queue all at once, there won't > > be any slots

Re: [V9fs-developer] 9pfs hangs since 4.7

On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote: > On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote: > > > released) simply trigger virtio_queue_notify_vq() again? It *is* a bug > > (if we get a burst filling a previously empty queue all at once, there won't > > be any slots

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Chanwoo, > >> >>> + touchkey@20 { > >> >>> + compatible = "samsung,tm2-touchkey"; > >> >>> + reg = <0x20>; > >> >>> + interrupt-parent = <>; > >> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; > >> >>> + vcc-supply =

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Chanwoo, > >> >>> + touchkey@20 { > >> >>> + compatible = "samsung,tm2-touchkey"; > >> >>> + reg = <0x20>; > >> >>> + interrupt-parent = <>; > >> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; > >> >>> + vcc-supply =

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Andi, 2017-01-07 21:40 GMT+09:00 Andi Shyti : > Hi Chanwoo, > >> >>> + touchkey@20 { >> >>> + compatible = "samsung,tm2-touchkey"; >> >>> + reg = <0x20>; >> >>> + interrupt-parent = <>; >> >>> + interrupts = <2

Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node

Hi Andi, 2017-01-07 21:40 GMT+09:00 Andi Shyti : > Hi Chanwoo, > >> >>> + touchkey@20 { >> >>> + compatible = "samsung,tm2-touchkey"; >> >>> + reg = <0x20>; >> >>> + interrupt-parent = <>; >> >>> + interrupts = <2

Re: [f2fs-dev] [PATCH 3/5] f2fs: check in-memory block bitmap

Hi Chao, On 01/07, Chao Yu wrote: > This patch adds a mirror for valid block bitmap, and use it to detect > in-memory bitmap corruption which may be caused by bit-transition of > cache or memory overflow. > > Signed-off-by: Chao Yu > --- > fs/f2fs/segment.c | 30

Re: [f2fs-dev] [PATCH 3/5] f2fs: check in-memory block bitmap

Hi Chao, On 01/07, Chao Yu wrote: > This patch adds a mirror for valid block bitmap, and use it to detect > in-memory bitmap corruption which may be caused by bit-transition of > cache or memory overflow. > > Signed-off-by: Chao Yu > --- > fs/f2fs/segment.c | 30 --

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

On Sat, Jan 07, 2017 at 08:39:45AM +0100, Greg KH wrote: > On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote: > > Changed file permission to octal style, > > Found using checkpatch > > Typo in your subject line :( > > > > > Signed-off-by: Derek Robson > > --- > >

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

On Sat, Jan 07, 2017 at 08:39:45AM +0100, Greg KH wrote: > On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote: > > Changed file permission to octal style, > > Found using checkpatch > > Typo in your subject line :( > > > > > Signed-off-by: Derek Robson > > --- > >

Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots as kernel text area

On Wed, 4 Jan 2017 11:01:02 +0100 Peter Zijlstra wrote: > On Wed, Jan 04, 2017 at 02:06:04PM +0900, Masami Hiramatsu wrote: > > On Tue, 3 Jan 2017 11:54:02 +0100 > > Peter Zijlstra wrote: > > > > How many entries should one expect on that list? I

Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots as kernel text area

On Wed, 4 Jan 2017 11:01:02 +0100 Peter Zijlstra wrote: > On Wed, Jan 04, 2017 at 02:06:04PM +0900, Masami Hiramatsu wrote: > > On Tue, 3 Jan 2017 11:54:02 +0100 > > Peter Zijlstra wrote: > > > > How many entries should one expect on that list? I spend quite a bit of > > > time reducing the

Re: [PATCH net-next] net: dsa: move HWMON support to its own file

From: Vivien Didelot Date: Fri, 6 Jan 2017 16:42:00 -0500 > Isolate the HWMON support in DSA in its own file. Currently only the > legacy DSA code is concerned. > > Signed-off-by: Vivien Didelot Applied.

Re: [PATCH net-next] net: dsa: move HWMON support to its own file

From: Vivien Didelot Date: Fri, 6 Jan 2017 16:42:00 -0500 > Isolate the HWMON support in DSA in its own file. Currently only the > legacy DSA code is concerned. > > Signed-off-by: Vivien Didelot Applied.

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber wrote: > Just remuxed GPIO signals to these pads, applied your two patches and > used rts-gpios in the DT but I still see the same problem :/ > > When transmit something, I get doubled characters, then zeros

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Clemens, On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber wrote: > Just remuxed GPIO signals to these pads, applied your two patches and > used rts-gpios in the DT but I still see the same problem :/ > > When transmit something, I get doubled characters, then zeros and at the > end garbled

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 2:45 AM, Rafael J. Wysocki wrote: > On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov wrote: >> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: >>> So we get the table, but apparently we crash when we attempt to put it.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 2:45 AM, Rafael J. Wysocki wrote: > On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov wrote: >> On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: >>> So we get the table, but apparently we crash when we attempt to put it. >> >> Right, except on 4.10-rc2 we

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Sat, Jan 7, 2017 at 6:02 PM, Johannes Weiner wrote: > > Linus? Andrew? Looks fine to me. Will apply. Linus

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Sat, Jan 7, 2017 at 6:02 PM, Johannes Weiner wrote: > > Linus? Andrew? Looks fine to me. Will apply. Linus

Re: [net-next v1 0/8] netcp: enhancements and minor fixes

From: Murali Karicheri Date: Fri, 6 Jan 2017 15:37:38 -0500 > This series is for net-next. This propagates enhancements and minor > bug fixes from internal version of the driver to keep the upstream > in sync. Please review and apply if this looks good. > > Tested on all of

Re: [net-next v1 0/8] netcp: enhancements and minor fixes

From: Murali Karicheri Date: Fri, 6 Jan 2017 15:37:38 -0500 > This series is for net-next. This propagates enhancements and minor > bug fixes from internal version of the driver to keep the upstream > in sync. Please review and apply if this looks good. > > Tested on all of K2HK/E/L boards with

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Tue, Jan 03, 2017 at 01:28:25PM +0100, Jan Kara wrote: > On Mon 02-01-17 16:11:36, Johannes Weiner wrote: > > On Fri, Dec 23, 2016 at 03:33:29AM -0500, Johannes Weiner wrote: > > > On Fri, Dec 23, 2016 at 02:32:41AM -0500, Johannes Weiner wrote: > > > > On Thu, Dec 22, 2016 at 12:22:27PM -0800,

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Tue, Jan 03, 2017 at 01:28:25PM +0100, Jan Kara wrote: > On Mon 02-01-17 16:11:36, Johannes Weiner wrote: > > On Fri, Dec 23, 2016 at 03:33:29AM -0500, Johannes Weiner wrote: > > > On Fri, Dec 23, 2016 at 02:32:41AM -0500, Johannes Weiner wrote: > > > > On Thu, Dec 22, 2016 at 12:22:27PM -0800,

Re: [PATCH v2 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR

From: Grygorii Strashko Date: Fri, 6 Jan 2017 14:07:28 -0600 > This series intended to add support for placing CPDMA descriptors into DDR by > introducing new module parameter "descs_pool_size" to specify size of > descriptor's > pool. The "descs_pool_size" defines

Re: [PATCH v2 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR

From: Grygorii Strashko Date: Fri, 6 Jan 2017 14:07:28 -0600 > This series intended to add support for placing CPDMA descriptors into DDR by > introducing new module parameter "descs_pool_size" to specify size of > descriptor's > pool. The "descs_pool_size" defines total number of CPDMA > CPPI

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: >> So we get the table, but apparently we crash when we attempt to put it. > > Right, except on 4.10-rc2 we don't crash but we freeze early. These are > the

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 2:01 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: >> So we get the table, but apparently we crash when we attempt to put it. > > Right, except on 4.10-rc2 we don't crash but we freeze early. These are > the last lines: > >

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

From: Eric Biggers Date: Sat, 7 Jan 2017 14:09:11 -0800 > Well, except those instructions aren't actually used in these > places. Although x86_64 SHA1-NI accelerated SHA-1 is available in > the Linux crypto API, it seems that in kernel code it remains > impractical to use

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

From: Eric Biggers Date: Sat, 7 Jan 2017 14:09:11 -0800 > Well, except those instructions aren't actually used in these > places. Although x86_64 SHA1-NI accelerated SHA-1 is available in > the Linux crypto API, it seems that in kernel code it remains > impractical to use these instructions on

[PATCH] media: fix dm1105.c build error

From: Randy Dunlap Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by: Randy Dunlap

[PATCH] media: fix dm1105.c build error

From: Randy Dunlap Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Javier Martinez

Re: [PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

On Sat, Jan 7, 2017 at 11:32 AM, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > There is no checking valid value of maxmtu when getting it from > device tree. This resolution added the checking condition to > ensure the assignment is

Re: [PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

On Sat, Jan 7, 2017 at 11:32 AM, Kweh, Hock Leong wrote: > From: "Kweh, Hock Leong" > > There is no checking valid value of maxmtu when getting it from > device tree. This resolution added the checking condition to > ensure the assignment is made within a valid range. FWIW: Reviewed-by: Andy

Re: [PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

On Sun, Jan 8, 2017 at 1:57 AM, Sudip Mukherjee wrote: > Add the serial driver for the exar chips. And also register the > platform device for the exar gpio. Did you ignore some comments? IIRC I recommended to use proper vendor name like Exar (or how is it spelled?).

Re: [PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

On Sun, Jan 8, 2017 at 1:57 AM, Sudip Mukherjee wrote: > Add the serial driver for the exar chips. And also register the > platform device for the exar gpio. Did you ignore some comments? IIRC I recommended to use proper vendor name like Exar (or how is it spelled?). > Headers, if arranged in

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: > So we get the table, but apparently we crash when we attempt to put it. Right, except on 4.10-rc2 we don't crash but we freeze early. These are the last lines: ... [0.004778] mce: CPU supports 7 MCE banks [0.004861] LVT

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 01:52:50AM +0100, Rafael J. Wysocki wrote: > So we get the table, but apparently we crash when we attempt to put it. Right, except on 4.10-rc2 we don't crash but we freeze early. These are the last lines: ... [0.004778] mce: CPU supports 7 MCE banks [0.004861] LVT

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 1:37 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote: >> Is an IVRS table actually present on this machine? > > Like this? > > [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA > 0001

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 1:37 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote: >> Is an IVRS table actually present on this machine? > > Like this? > > [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA > 0001 AMD )

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote: > Is an IVRS table actually present on this machine? Like this? [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA 0001 AMD ) -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 01:22:55AM +0100, Rafael J. Wysocki wrote: > Is an IVRS table actually present on this machine? Like this? [0.00] ACPI: IVRS 0x9CFD6000 D0 (v02 AMDAGESA 0001 AMD ) -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

Ard Biesheuvel writes: > On 6 January 2017 at 17:46, Nicolai Stange wrote: >> Ard Biesheuvel writes: >> >>> On 6 January 2017 at 13:02, Nicolai Stange wrote: Ard Biesheuvel

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

Ard Biesheuvel writes: > On 6 January 2017 at 17:46, Nicolai Stange wrote: >> Ard Biesheuvel writes: >> >>> On 6 January 2017 at 13:02, Nicolai Stange wrote: Ard Biesheuvel writes: > On 5 January 2017 at 12:51, Nicolai Stange wrote: >> Before invoking the arch specific

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 1:07 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote: >> Please check if this helps: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d > >

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 8, 2017 at 1:07 AM, Borislav Petkov wrote: > On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote: >> Please check if this helps: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d > > Unfortunately

Re: stack unwinder warning.

On Fri, Jan 06, 2017 at 10:50:32AM -0600, Josh Poimboeuf wrote: > > WARNING: kernel stack frame pointer at c90001443f30 in > > kworker/u8:8:30468 has bad value (null) > > unwind stack type:0 next_sp: (null) mask:6 graph_idx:0 > > This is actually a separate issue.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote: > Please check if this helps: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d Unfortunately no, still same early freeze. :-\ The splat happens when booting

Re: stack unwinder warning.

On Fri, Jan 06, 2017 at 10:50:32AM -0600, Josh Poimboeuf wrote: > > WARNING: kernel stack frame pointer at c90001443f30 in > > kworker/u8:8:30468 has bad value (null) > > unwind stack type:0 next_sp: (null) mask:6 graph_idx:0 > > This is actually a separate issue.

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Sun, Jan 08, 2017 at 12:30:27AM +0100, Rafael J. Wysocki wrote: > Please check if this helps: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=696c7f8e0373026e8bfb29b2d9ff2d0a92059d4d Unfortunately no, still same early freeze. :-\ The splat happens when booting

[PATCH v7 3/3] serial: 8250_pci: remove exar code

Remove the exar specific codes from 8250_pci and blacklist those chips so that the exar serial binds to the devices. Signed-off-by: Sudip Mukherjee --- drivers/tty/serial/8250/8250_pci.c | 336 + 1 file changed, 3

[PATCH v7 3/3] serial: 8250_pci: remove exar code

Remove the exar specific codes from 8250_pci and blacklist those chips so that the exar serial binds to the devices. Signed-off-by: Sudip Mukherjee --- drivers/tty/serial/8250/8250_pci.c | 336 + 1 file changed, 3 insertions(+), 333 deletions(-) diff --git

[PATCH v7 0/3] add gpio support to exar

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which can be controlled using gpio interface. v5 was sent in January, 2016 and after reviews it was suggested to split the exar code out of 8250_pci and make its own driver. For reference it is at

[PATCH v7 0/3] add gpio support to exar

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which can be controlled using gpio interface. v5 was sent in January, 2016 and after reviews it was suggested to split the exar code out of 8250_pci and make its own driver. For reference it is at

[PATCH v7 1/3] gpio: exar: add gpio for exar cards

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which can be controlled using gpio interface. Add the gpio specific code. Signed-off-by: Sudip Mukherjee --- drivers/gpio/Kconfig | 7 ++ drivers/gpio/Makefile| 1 +

[PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

Add the serial driver for the exar chips. And also register the platform device for the exar gpio. Signed-off-by: Sudip Mukherjee --- Hi Andy, Headers, if arranged in alphabetical order, will give a build warning. And thanks for revewing that v6. I think those

[PATCH v7 1/3] gpio: exar: add gpio for exar cards

Exar XR17V352/354/358 chips have 16 multi-purpose inputs/outputs which can be controlled using gpio interface. Add the gpio specific code. Signed-off-by: Sudip Mukherjee --- drivers/gpio/Kconfig | 7 ++ drivers/gpio/Makefile| 1 + drivers/gpio/gpio-exar.c | 238

[PATCH v7 2/3] serial: exar: split out the exar code from 8250_pci

Add the serial driver for the exar chips. And also register the platform device for the exar gpio. Signed-off-by: Sudip Mukherjee --- Hi Andy, Headers, if arranged in alphabetical order, will give a build warning. And thanks for revewing that v6. I think those were the worst patch I have ever

[PATCH] mm: stop leaking PageTables

4.10-rc loadtest (even on x86, even without THPCache) fails with "fork: Cannot allocate memory" or some such; and /proc/meminfo shows PageTables growing. rc1 removed the freeing of an unused preallocated pagetable after do_fault_around() has called map_pages(): which is usually a good

[PATCH] mm: stop leaking PageTables

4.10-rc loadtest (even on x86, even without THPCache) fails with "fork: Cannot allocate memory" or some such; and /proc/meminfo shows PageTables growing. rc1 removed the freeing of an unused preallocated pagetable after do_fault_around() has called map_pages(): which is usually a good

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On 1/7/2017 9:42 PM, Borislav Petkov wrote: Hi, I'm bisecting a boot freeze with 4.10-rc2 on a laptop and the commit in $Subject is introducing a breakage, see attached splat. Unfortunately, it is not complete as I don't have any other means of logging dmesg on a laptop. A temporary workaround

Re: 174cc7187e6f ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On 1/7/2017 9:42 PM, Borislav Petkov wrote: Hi, I'm bisecting a boot freeze with 4.10-rc2 on a laptop and the commit in $Subject is introducing a breakage, see attached splat. Unfortunately, it is not complete as I don't have any other means of logging dmesg on a laptop. A temporary workaround

Re: [PATCH] usb: storage: ene_ub6250: remove unused variable

On Thursday 05 January 2017 06:36 PM, Greg Kroah-Hartman wrote: On Sun, Dec 18, 2016 at 10:34:31PM +, Sudip Mukherjee wrote: The variable Newblk was only being assigned some value but was never used after that. Signed-off-by: Sudip Mukherjee ---

Re: [PATCH] usb: storage: ene_ub6250: remove unused variable

On Thursday 05 January 2017 06:36 PM, Greg Kroah-Hartman wrote: On Sun, Dec 18, 2016 at 10:34:31PM +, Sudip Mukherjee wrote: The variable Newblk was only being assigned some value but was never used after that. Signed-off-by: Sudip Mukherjee --- drivers/usb/storage/ene_ub6250.c | 2 --

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Fabio, On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote: > Hi Clemens, > > On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber > wrote: > > > Great! > > > > Did you observe the same effect I described, with the doubling of > > characters in the front and

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Fabio, On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote: > Hi Clemens, > > On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber > wrote: > > > Great! > > > > Did you observe the same effect I described, with the doubling of > > characters in the front and the leftovers from previous

Re: [PATCH v2] fscrypt: Factor out bio specific functions

Ted, Am 07.01.2017 um 20:24 schrieb Theodore Ts'o: > On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote: >> >> I thought you're supposed to be able to build the kernel no matter how it's >> configured. If this patch is really too large for 4.10 then perhaps we >> should >> make

Re: [PATCH v2] fscrypt: Factor out bio specific functions

Ted, Am 07.01.2017 um 20:24 schrieb Theodore Ts'o: > On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote: >> >> I thought you're supposed to be able to build the kernel no matter how it's >> configured. If this patch is really too large for 4.10 then perhaps we >> should >> make

Re: [RFC PATCH] intel: Use upper_32_bits and lower_32_bits

On Sat, 7 Jan 2017, Joe Perches wrote: > Shifting and masking various types can be made a bit > simpler to read by using the available kernel macros. It looks much nicer to me, especially in the lower case, where there are multiple ways to express the same thing. julia > > Signed-off-by: Joe

Re: [RFC PATCH] intel: Use upper_32_bits and lower_32_bits

On Sat, 7 Jan 2017, Joe Perches wrote: > Shifting and masking various types can be made a bit > simpler to read by using the available kernel macros. It looks much nicer to me, especially in the lower case, where there are multiple ways to express the same thing. julia > > Signed-off-by: Joe

[PATCH] net: intel: e100: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/intel/e100.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH] net: intel: e100: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/intel/e100.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/e100.c

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

Hi David, On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote: > From: "Jason A. Donenfeld" > Date: Sat, 7 Jan 2017 15:40:56 +0100 > > > This gives a clear speed and security improvement. Siphash is both > > faster and is more solid crypto than the aging MD5. [snip] >

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

Hi David, On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote: > From: "Jason A. Donenfeld" > Date: Sat, 7 Jan 2017 15:40:56 +0100 > > > This gives a clear speed and security improvement. Siphash is both > > faster and is more solid crypto than the aging MD5. [snip] > > This and the

[PATCH v2 1/2] Staging: unisys: visorbus: visorbus_main.c: fixed style

Changed file permissions to octal sytle. Found using checkpatch. Acked-by: David Kershner Signed-off-by: Derek Robson --- Version 1 had duplicated subject/commit message, fixed in v2 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++--- 1

[PATCH v2 1/2] Staging: unisys: visorbus: visorbus_main.c: fixed style

Changed file permissions to octal sytle. Found using checkpatch. Acked-by: David Kershner Signed-off-by: Derek Robson --- Version 1 had duplicated subject/commit message, fixed in v2 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

[PATCH v2 2/2] Staging: unisys: visorbus: visorchipset.c: style fix

Changed file permissions to octal sytle. Found using checkpatch. Acked-by: David Kershner Signed-off-by: Derek Robson --- Version 1 had duplicated subject/commit message, fixed in v2 drivers/staging/unisys/visorbus/visorchipset.c | 2 +- 1 file

[PATCH v2 2/2] Staging: unisys: visorbus: visorchipset.c: style fix

Changed file permissions to octal sytle. Found using checkpatch. Acked-by: David Kershner Signed-off-by: Derek Robson --- Version 1 had duplicated subject/commit message, fixed in v2 drivers/staging/unisys/visorbus/visorchipset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v2 0/2] Staging: unisys: visorbus: style fix

Two files change in style fix, changes are octal file permiss ions. version 2: first verion has duplicated subject/commit messages Derek Robson (2): Staging: unisys: visorbus: visorbus_main.c: fixed style Staging: unisys: visorbus: visorchipset.c: style fix

[PATCH v2 0/2] Staging: unisys: visorbus: style fix

Two files change in style fix, changes are octal file permiss ions. version 2: first verion has duplicated subject/commit messages Derek Robson (2): Staging: unisys: visorbus: visorbus_main.c: fixed style Staging: unisys: visorbus: visorchipset.c: style fix

Re: [PATCH v6 2/3] serial: exar: split out the exar code from 8250_pci

/20170107-005654 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: x86_64-randconfig-s2-01080418 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: # save the attached .config to linux build tree make ARCH=x86_64

Re: [PATCH v6 2/3] serial: exar: split out the exar code from 8250_pci

/20170107-005654 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: x86_64-randconfig-s2-01080418 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: # save the attached .config to linux build tree make ARCH=x86_64

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Clemens, On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber wrote: > Great! > > Did you observe the same effect I described, with the doubling of > characters in the front and the leftovers from previous transmissions at > the end? No, I don't observe these errors

Re: imx: RS-485 problems during TX, maybe DMA related

Hi Clemens, On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber wrote: > Great! > > Did you observe the same effect I described, with the doubling of > characters in the front and the leftovers from previous transmissions at > the end? No, I don't observe these errors when I use 'rts-gpios' in the

Re: [PATCH] i2c: print correct device invalid address

On 01/06/2017 01:02 PM, John Garry wrote: > In of_i2c_register_device(), when the check for > device address validity fails we print the info.addr, > which has not been assigned properly. > > Fix this by printing the actual invalid address. > > Signed-off-by: John Garry >

Re: [PATCH] i2c: print correct device invalid address

On 01/06/2017 01:02 PM, John Garry wrote: > In of_i2c_register_device(), when the check for > device address validity fails we print the info.addr, > which has not been assigned properly. > > Fix this by printing the actual invalid address. > > Signed-off-by: John Garry > > diff --git

[PATCH] net: ibm: ibmvnic: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/ibm/ibmvnic.c | 31 ++- 1 files changed, 18 insertions(+), 13 deletions(-) diff

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

From: "Jason A. Donenfeld" Date: Sat, 7 Jan 2017 15:40:56 +0100 > This gives a clear speed and security improvement. Siphash is both > faster and is more solid crypto than the aging MD5. > > Rather than manually filling MD5 buffers, for IPv6, we simply create > a layout by a

[PATCH] net: ibm: ibmvnic: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/ibm/ibmvnic.c | 31 ++- 1 files changed, 18 insertions(+), 13 deletions(-) diff --git

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

From: "Jason A. Donenfeld" Date: Sat, 7 Jan 2017 15:40:56 +0100 > This gives a clear speed and security improvement. Siphash is both > faster and is more solid crypto than the aging MD5. > > Rather than manually filling MD5 buffers, for IPv6, we simply create > a layout by a simple anonymous

  1   2   3   4   >