[PATCH 3/4] staging: android/ion: Align comment mark

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h index 3c3b324..00d8b53 100644 ---

[PATCH 3/4] staging: android/ion: Align comment mark

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h index 3c3b324..00d8b53 100644 ---

Re: [PATCH resend] swiotlb: ensure that page-sized mappings are page-aligned

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH resend] swiotlb: ensure that page-sized mappings are page-aligned

Looks good, Reviewed-by: Christoph Hellwig

[PATCH 2/4] staging: android/ion: Don't use return in void function

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_of.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c index 46b2bb9..7791c70 100644 ---

[PATCH 2/4] staging: android/ion: Don't use return in void function

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_of.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c index 46b2bb9..7791c70 100644 --- a/drivers/staging/android/ion/ion_of.c +++

[PATCH 4/4] staging: android/ion: Use variable names in header

Populate header function signatures with variable names as well, not just variable types. Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_priv.h | 38 +- 1 file changed, 19 insertions(+), 19 deletions(-) diff

[PATCH 1/4] staging: android/ion: Fix line over 80 characters

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion-ioctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index 7e7431d..e28fffb 100644 ---

[PATCH 4/4] staging: android/ion: Use variable names in header

Populate header function signatures with variable names as well, not just variable types. Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion_priv.h | 38 +- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git

[PATCH 1/4] staging: android/ion: Fix line over 80 characters

Signed-off-by: Bogdan Purcareata --- drivers/staging/android/ion/ion-ioctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index 7e7431d..e28fffb 100644 ---

Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role

Hi, Baolin Wang writes: >> Baolin Wang writes: >>> When dwc3 controller acts as host role with attaching slow speed device >>> (like mouse or keypad). Then if we plugged out the slow speed device, >>> it will timeout to run the deconfiguration

Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role

Hi, Baolin Wang writes: >> Baolin Wang writes: >>> When dwc3 controller acts as host role with attaching slow speed device >>> (like mouse or keypad). Then if we plugged out the slow speed device, >>> it will timeout to run the deconfiguration endpoint command to drop the >>> endpoint's

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu wrote: > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: >> >> I'm pretty sure we have random asm code that may not maintain a >> 16-byte stack alignment when it calls other code (including, in some >>

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

On Wed, Jan 11, 2017 at 11:47 PM, Herbert Xu wrote: > Andy Lutomirski wrote: >> There are some hashes (e.g. sha224) that have some internal trickery >> to make sure that only the correct number of output bytes are >> generated. If something goes

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu wrote: > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: >> >> I'm pretty sure we have random asm code that may not maintain a >> 16-byte stack alignment when it calls other code (including, in some >> cases, calling C code). >> >> So

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

On Wed, Jan 11, 2017 at 11:47 PM, Herbert Xu wrote: > Andy Lutomirski wrote: >> There are some hashes (e.g. sha224) that have some internal trickery >> to make sure that only the correct number of output bytes are >> generated. If something goes wrong, they could potentially overrun >> the

Re: [PATCH] pinctrl: amd: avoid maybe-uninitalized warning

On Wed, Jan 11, 2017 at 3:36 PM, Arnd Bergmann wrote: > Since gpio_dev->hwbank_num is now a variable, the compiler cannot > figure out if pin_num is initialized at all: > > drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show': > drivers/pinctrl/pinctrl-amd.c:210:3:

Re: [PATCH] pinctrl: amd: avoid maybe-uninitalized warning

On Wed, Jan 11, 2017 at 3:36 PM, Arnd Bergmann wrote: > Since gpio_dev->hwbank_num is now a variable, the compiler cannot > figure out if pin_num is initialized at all: > > drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show': > drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num'

Re: [PATCH] tty_port: checkpatch: Refactored file to linux style guides

On Wed, Jan 11, 2017 at 10:39:22PM +0100, Fabian Arnold wrote: > The tty_port.c file is now accordingly to the linux style guidelines. That's the vaguest changelog text ever :( Please describe what you did here, and why you did it. And if you fixed more than one "type" of style issue, you need

Re: [PATCH] tty_port: checkpatch: Refactored file to linux style guides

On Wed, Jan 11, 2017 at 10:39:22PM +0100, Fabian Arnold wrote: > The tty_port.c file is now accordingly to the linux style guidelines. That's the vaguest changelog text ever :( Please describe what you did here, and why you did it. And if you fixed more than one "type" of style issue, you need

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

Andy Lutomirski wrote: > There are some hashes (e.g. sha224) that have some internal trickery > to make sure that only the correct number of output bytes are > generated. If something goes wrong, they could potentially overrun > the output buffer. > > Make the test more robust

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

Andy Lutomirski wrote: > There are some hashes (e.g. sha224) that have some internal trickery > to make sure that only the correct number of output bytes are > generated. If something goes wrong, they could potentially overrun > the output buffer. > > Make the test more robust by allocating

Re: [PATCH v2 1/1] platform/x86: Remove PMIC GPIO block support

* Andy Shevchenko wrote: > On Wed, 2017-01-11 at 19:24 +0200, Andy Shevchenko wrote: > > The Moorestown support was removed by commit 1a8359e411eb ("x86/mid: > > Remove > > Intel Moorestown"). > > > > Remove this leftover. > > > > +Cc: Ingo > > Ingo, this

Re: [PATCH v2 1/1] platform/x86: Remove PMIC GPIO block support

* Andy Shevchenko wrote: > On Wed, 2017-01-11 at 19:24 +0200, Andy Shevchenko wrote: > > The Moorestown support was removed by commit 1a8359e411eb ("x86/mid: > > Remove > > Intel Moorestown"). > > > > Remove this leftover. > > > > +Cc: Ingo > > Ingo, this is the driver we would like to

Re: x86-64: Maintain 16-byte stack alignment

* Herbert Xu wrote: > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > > > I'm pretty sure we have random asm code that may not maintain a > > 16-byte stack alignment when it calls other code (including, in some > > cases, calling C code). > > >

Re: x86-64: Maintain 16-byte stack alignment

* Herbert Xu wrote: > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > > > I'm pretty sure we have random asm code that may not maintain a > > 16-byte stack alignment when it calls other code (including, in some > > cases, calling C code). > > > > So I'm not at all convinced

Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts

On Wednesday 11 January 2017 09:55 PM, David Lechner wrote: >>> + { >>> +status = "okay"; >>> +pinctrl-names = "default"; >>> +pinctrl-0 = <_pins>, <_cs0_pin>, <_cs3_pin>; >>> + >>> +flash@0 { >>> +compatible = "n25q128a13", "jedec,spi-nor"; >>> +reg = <0>; >>> +

[PATCH] hwmon: occ: fix err_cast.cocci warnings

drivers/hwmon/occ/occ_sysfs.c:265:9-16: WARNING: ERR_CAST can be used with hwmon -> dev Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)) Generated by: scripts/coccinelle/api/err_cast.cocci CC: Edward A. James Signed-off-by: Fengguang Wu

[PATCH] hwmon: occ: fix err_cast.cocci warnings

drivers/hwmon/occ/occ_sysfs.c:265:9-16: WARNING: ERR_CAST can be used with hwmon -> dev Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)) Generated by: scripts/coccinelle/api/err_cast.cocci CC: Edward A. James Signed-off-by: Fengguang Wu --- occ_sysfs.c |2 +- 1 file

Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts

On Wednesday 11 January 2017 09:55 PM, David Lechner wrote: >>> + { >>> +status = "okay"; >>> +pinctrl-names = "default"; >>> +pinctrl-0 = <_pins>, <_cs0_pin>, <_cs3_pin>; >>> + >>> +flash@0 { >>> +compatible = "n25q128a13", "jedec,spi-nor"; >>> +reg = <0>; >>> +

Re: x86-64: Maintain 16-byte stack alignment

* Andy Lutomirski wrote: > I find it rather annoying that gcc before 4.8 malfunctions when it > sees __aligned__(16) on x86_64 kernels. Sigh. Ran into this when writing silly FPU in-kernel testcases a couple of months ago... Thanks, Ingo

Re: x86-64: Maintain 16-byte stack alignment

* Andy Lutomirski wrote: > I find it rather annoying that gcc before 4.8 malfunctions when it > sees __aligned__(16) on x86_64 kernels. Sigh. Ran into this when writing silly FPU in-kernel testcases a couple of months ago... Thanks, Ingo

Re: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Bharat, On 12/01/2017 04:59, Bharat Bhushan wrote: > > >> -Original Message- >> From: Eric Auger [mailto:eric.au...@redhat.com] >> Sent: Wednesday, January 11, 2017 3:12 PM >> To: eric.au...@redhat.com; eric.auger@gmail.com; >> christoffer.d...@linaro.org; marc.zyng...@arm.com; >>

Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface

Hi Edward, [auto build test WARNING on hwmon/hwmon-next] [also build test WARNING on v4.10-rc3 next-20170111] [cannot apply to linux/master] [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

Re: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Hi Bharat, On 12/01/2017 04:59, Bharat Bhushan wrote: > > >> -Original Message- >> From: Eric Auger [mailto:eric.au...@redhat.com] >> Sent: Wednesday, January 11, 2017 3:12 PM >> To: eric.au...@redhat.com; eric.auger@gmail.com; >> christoffer.d...@linaro.org; marc.zyng...@arm.com; >>

Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface

Hi Edward, [auto build test WARNING on hwmon/hwmon-next] [also build test WARNING on v4.10-rc3 next-20170111] [cannot apply to linux/master] [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

Re: [PATCH] staging: android/ion: Fix coding style issues

On Wed, Jan 11, 2017 at 11:20:39PM +0200, Bogdan Purcareata wrote: > Fix following checkpatch warnings: > - Lines over 80 characters > - void function with return statement > - Unaligned comment mark > - Header function prototypes missing variable names That's a lot of different things to be

Re: [PATCH] staging: android/ion: Fix coding style issues

On Wed, Jan 11, 2017 at 11:20:39PM +0200, Bogdan Purcareata wrote: > Fix following checkpatch warnings: > - Lines over 80 characters > - void function with return statement > - Unaligned comment mark > - Header function prototypes missing variable names That's a lot of different things to be

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote: > On Tue, Jan 10, 2017 at 03:23:27PM -0600, l...@pengaru.com wrote: > > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote: > > > > Hello, this

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote: > On Tue, Jan 10, 2017 at 03:23:27PM -0600, l...@pengaru.com wrote: > > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote: > > > > Hello, this

Re: [PATCH] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()

Hi, Shuah Khan writes: > During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from > xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding > the platform device. > > dwc3_host_init() was changed to not configure DMA with the change

Re: [PATCH] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()

Hi, Shuah Khan writes: > During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from > xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding > the platform device. > > dwc3_host_init() was changed to not configure DMA with the change to use > bus->sysdev for

Re: [PATCH] serial: fsl_lpuart: Remove the alias node dependence

On Thu, Jan 12, 2017 at 02:27:45AM +, Yao Yuan wrote: > On Wed, Jan 11, 2016 at 04:33:32PM +0800, Greg KH wrote: > > On Wed, Dec 14, 2016 at 04:33:32PM +0800, Yuan Yao wrote: > > > From: Yuan Yao > > > > > > Numbering the ttyLPn space should not depend on the generic name >

Re: [PATCH] serial: fsl_lpuart: Remove the alias node dependence

On Thu, Jan 12, 2017 at 02:27:45AM +, Yao Yuan wrote: > On Wed, Jan 11, 2016 at 04:33:32PM +0800, Greg KH wrote: > > On Wed, Dec 14, 2016 at 04:33:32PM +0800, Yuan Yao wrote: > > > From: Yuan Yao > > > > > > Numbering the ttyLPn space should not depend on the generic name > > > "serial". > >

Re: [PATCH v3] staging: greybus: checkpatch: Change parameter type unsigned to unsigned int

On Wed, Jan 11, 2017 at 04:00:35PM +0100, Roman Sommer wrote: > Note that this patch does not fix all checkpatch warnings for the > affected files. > A lot of ways that display git commits put the changelog and the summary far apart. The changelog is pretty useless by itself in this case.

Re: [PATCH v3] staging: greybus: checkpatch: Change parameter type unsigned to unsigned int

On Wed, Jan 11, 2017 at 04:00:35PM +0100, Roman Sommer wrote: > Note that this patch does not fix all checkpatch warnings for the > affected files. > A lot of ways that display git commits put the changelog and the summary far apart. The changelog is pretty useless by itself in this case.

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > I'm pretty sure we have random asm code that may not maintain a > 16-byte stack alignment when it calls other code (including, in some > cases, calling C code). > > So I'm not at all convinced that this is a good idea. We

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > I'm pretty sure we have random asm code that may not maintain a > 16-byte stack alignment when it calls other code (including, in some > cases, calling C code). > > So I'm not at all convinced that this is a good idea. We

Re: [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

On 3 January 2017 at 13:54, Baolin Wang wrote: > Hi Kison and Heiko, > > On 21 December 2016 at 16:12, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >>

Re: [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set

On 3 January 2017 at 13:54, Baolin Wang wrote: > Hi Kison and Heiko, > > On 21 December 2016 at 16:12, Baolin Wang wrote: >> According to the documentation, we should set the EXTCON_USB when >> one SDP charger connector was reported. >> >> Signed-off-by: Baolin Wang >> Reviewed-by: Chanwoo Choi

Re: [PATCH 1/2] capability: export has_capability

On Wed, Jan 11, 2017 at 01:47:01PM -0500, Alex Williamson wrote: > On Thu, 22 Dec 2016 00:10:15 +0800 > Jike Song wrote: > > > has_capability() is sometimes needed by modules to test capability > > for specified task other than current, so export it. > > > > Cc: Alex

Re: [PATCH 1/2] capability: export has_capability

On Wed, Jan 11, 2017 at 01:47:01PM -0500, Alex Williamson wrote: > On Thu, 22 Dec 2016 00:10:15 +0800 > Jike Song wrote: > > > has_capability() is sometimes needed by modules to test capability > > for specified task other than current, so export it. > > > > Cc: Alex Williamson > > Cc: Kirti

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

On 11.01.2017 13:19, Robin Murphy wrote: On 11/01/17 11:51, Tomasz Nowicki wrote: The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing

Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

On 11.01.2017 13:19, Robin Murphy wrote: On 11/01/17 11:51, Tomasz Nowicki wrote: The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems. Currently, the workaround code partitions ASIDs and VMIDs by increasing

[PATCH] can: Fix kernel panic at security_sock_rcv_skb

From: Zhang Yanmin The patch is for fix the below kernel panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: [] security_sock_rcv_skb+0x4c/0x60 [] sk_filter+0x41/0x210 []

[PATCH] can: Fix kernel panic at security_sock_rcv_skb

From: Zhang Yanmin The patch is for fix the below kernel panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: [] security_sock_rcv_skb+0x4c/0x60 [] sk_filter+0x41/0x210 [] sock_queue_rcv_skb+0x53/0x3a0 []

Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433

On Wed, Jan 11, 2017 at 11:22 PM, Chanwoo Choi wrote: > 2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski : >> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote: >>> This patch replaces the small letter of base address, offset and hex value >>> with the

Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433

On Wed, Jan 11, 2017 at 11:22 PM, Chanwoo Choi wrote: > 2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski : >> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote: >>> This patch replaces the small letter of base address, offset and hex value >>> with the capital letter to keep the

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

12.01.2017 08:52, Nikita Yushchenko wrote: >>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> index 5ac373c..480b644 100644 >>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> @@ -540,7

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

12.01.2017 08:52, Nikita Yushchenko wrote: >>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> index 5ac373c..480b644 100644 >>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> @@ -540,7

Re: [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

On Tuesday 10 January 2017 11:13 PM, Mark Rutland wrote: Hi, On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote: ToDo: 1) The counter overflow handling is currently unsupported in this patch series. From a quick scan of the patches, I see mention of an interrupt in a comment the

Re: [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters

On Tuesday 10 January 2017 11:13 PM, Mark Rutland wrote: Hi, On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote: ToDo: 1) The counter overflow handling is currently unsupported in this patch series. From a quick scan of the patches, I see mention of an interrupt in a comment the

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote: > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu > wrote: >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote: >>> >>> That said, I do think that the "don't assume stack

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote: > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu > wrote: >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote: >>> >>> That said, I do think that the "don't assume stack alignment, do it by >>> hand" may be the safer thing.

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote: > > Apologies for introducing this breakage. It seemed like an obvious and > simple cleanup, so I didn't even bother to mention it in the commit > log, but if the kernel does not guarantee 16 byte alignment, I guess > we should revert

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote: > > Apologies for introducing this breakage. It seemed like an obvious and > simple cleanup, so I didn't even bother to mention it in the commit > log, but if the kernel does not guarantee 16 byte alignment, I guess > we should revert

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/01/17 18:08, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >> With kernel 4.10rc3 running as Xen dm0 I get at each boot: >> >> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell >> [1431], reason: Hang on render ring, action: reset >> [

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/01/17 18:08, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >> With kernel 4.10rc3 running as Xen dm0 I get at each boot: >> >> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell >> [1431], reason: Hang on render ring, action: reset >> [

Re: [lkp-developer] [ACPICA] 174cc7187e: kmsg.ACPI_Error:Mutex[ACPI_MTX_Tables]already_acquired_by_this_thread[#](#/utmutex-#)

Hi, Lv On 01/12, Zheng, Lv wrote: >Hi, Xiaolong > >I noticed the tested version in your the test dmesg: Linux version 4.9.0-rc5 >While the commit bisected should be in v4.10-rc1. >Does that mean your test tree doesn't contain some basic lock fixes? The reported kernel version is Linux version

Re: [lkp-developer] [ACPICA] 174cc7187e: kmsg.ACPI_Error:Mutex[ACPI_MTX_Tables]already_acquired_by_this_thread[#](#/utmutex-#)

Hi, Lv On 01/12, Zheng, Lv wrote: >Hi, Xiaolong > >I noticed the tested version in your the test dmesg: Linux version 4.9.0-rc5 >While the commit bisected should be in v4.10-rc1. >Does that mean your test tree doesn't contain some basic lock fixes? The reported kernel version is Linux version

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> index 5ac373c..480b644 100644 >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> index 5ac373c..480b644 100644 >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 >> dma_base, u64 size, >> if (!dev->archdata.dma_ops) >> dev->archdata.dma_ops = _dma_ops; >> >> + /* >> +* Whatever the parent bus can set. A device must not set >> +* a DMA

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 >> dma_base, u64 size, >> if (!dev->archdata.dma_ops) >> dev->archdata.dma_ops = _dma_ops; >> >> + /* >> +* Whatever the parent bus can set. A device must not set >> +* a DMA

Re: [PATCH v3 04/10] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

On Tuesday 10 January 2017 11:25 PM, Mark Rutland wrote: On Mon, Jan 02, 2017 at 01:49:37AM -0500, Anurup M wrote: +The Hisilicon SoC HiP05/06/07 chips consist of various independent system +device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN). +These PMU devices are independent and

Re: [PATCH v3 04/10] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

On Tuesday 10 January 2017 11:25 PM, Mark Rutland wrote: On Mon, Jan 02, 2017 at 01:49:37AM -0500, Anurup M wrote: +The Hisilicon SoC HiP05/06/07 chips consist of various independent system +device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN). +These PMU devices are independent and

[GIT PULL] xfs: updates for 4.10-rc4

[Resend from the correct email account... sorry for the noise] Hi Linus, As promised last week, here's some stability fixes from Christoph and Jan Kara. I think they fall within the guidelines for non-merge window patches. Could you please pull the changes? --Darrick The following changes

[GIT PULL] xfs: updates for 4.10-rc4

[Resend from the correct email account... sorry for the noise] Hi Linus, As promised last week, here's some stability fixes from Christoph and Jan Kara. I think they fall within the guidelines for non-merge window patches. Could you please pull the changes? --Darrick The following changes

[GIT PULL] xfs: updates for 4.10-rc4

Hi Linus, As promised last week, here's some stability fixes from Christoph and Jan Kara. I think they fall within the guidelines for non-merge window patches. Could you please pull the changes? --Darrick The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux

[GIT PULL] xfs: updates for 4.10-rc4

Hi Linus, As promised last week, here's some stability fixes from Christoph and Jan Kara. I think they fall within the guidelines for non-merge window patches. Could you please pull the changes? --Darrick The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: > > > On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > > >> Make a generic API for all of this and you'd have my vote.. >> >> >> IMHO, you must support basic pinning semantics - that is necessary to >> support generic short lived DMA (eg

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: > > > On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > > >> Make a generic API for all of this and you'd have my vote.. >> >> >> IMHO, you must support basic pinning semantics - that is necessary to >> support generic short lived DMA (eg

[PATCH] [PATCH]thermal/intel_powerclamp:fix sched_setscheduler fail

From: "Liu, Xinwu" The schedule policy of thread "kidle_inject" is SCHED_NORMAL: [ 772.796284] intel_powerclamp: Start idle injection to reduce power [ 772.825757] [ cut here ] [ 772.825877] WARNING: CPU: 0 PID: 2140 at

[PATCH] [PATCH]thermal/intel_powerclamp:fix sched_setscheduler fail

From: "Liu, Xinwu" The schedule policy of thread "kidle_inject" is SCHED_NORMAL: [ 772.796284] intel_powerclamp: Start idle injection to reduce power [ 772.825757] [ cut here ] [ 772.825877] WARNING: CPU: 0 PID: 2140 at

RE: [lkp-developer] [ACPICA] 174cc7187e: kmsg.ACPI_Error:Mutex[ACPI_MTX_Tables]already_acquired_by_this_thread[#](#/utmutex-#)

Hi, Xiaolong I noticed the tested version in your the test dmesg: Linux version 4.9.0-rc5 While the commit bisected should be in v4.10-rc1. Does that mean your test tree doesn't contain some basic lock fixes? Thanks and best regards Lv > From: lkp-developer-requ...@eclists.intel.com >

RE: [lkp-developer] [ACPICA] 174cc7187e: kmsg.ACPI_Error:Mutex[ACPI_MTX_Tables]already_acquired_by_this_thread[#](#/utmutex-#)

Hi, Xiaolong I noticed the tested version in your the test dmesg: Linux version 4.9.0-rc5 While the commit bisected should be in v4.10-rc1. Does that mean your test tree doesn't contain some basic lock fixes? Thanks and best regards Lv > From: lkp-developer-requ...@eclists.intel.com >

Re: [PATCH v2 0/3] PCI: designware/dra7xx: misc fixes and cleanups

Hi Bjorn, On Thursday 12 January 2017 02:51 AM, Bjorn Helgaas wrote: > On Fri, Dec 30, 2016 at 03:26:11PM +0530, Kishon Vijay Abraham I wrote: >> This series contains >> *) a patch to cleanup dra7xx probe >> *) a patch to force DRA7xx controller to work in GEN1 mode >> *)

Re: [PATCH v2 0/3] PCI: designware/dra7xx: misc fixes and cleanups

Hi Bjorn, On Thursday 12 January 2017 02:51 AM, Bjorn Helgaas wrote: > On Fri, Dec 30, 2016 at 03:26:11PM +0530, Kishon Vijay Abraham I wrote: >> This series contains >> *) a patch to cleanup dra7xx probe >> *) a patch to force DRA7xx controller to work in GEN1 mode >> *)

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

Hello, On Wed, Jan 11, 2017 at 04:52:39PM +0100, Michal Hocko wrote: > On Wed 11-01-17 08:52:50, Minchan Kim wrote: > [...] > > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct > > > if (!file && !total_swap_pages) > > > return false; > > > > > > - inactive =

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

Hello, On Wed, Jan 11, 2017 at 04:52:39PM +0100, Michal Hocko wrote: > On Wed 11-01-17 08:52:50, Minchan Kim wrote: > [...] > > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct > > > if (!file && !total_swap_pages) > > > return false; > > > > > > - inactive =

Re: linux-next: build failure after merge of the akpm-current tree

Hi Stephen, Thanks for your report and the fix for it. The 0-day project has reported several days ago, but this patch set is still in discussion, so I am waiting for more days to see if other developers have any other questions. I am confused that how to deal with your patch if I need to

Re: linux-next: build failure after merge of the akpm-current tree

Hi Stephen, Thanks for your report and the fix for it. The 0-day project has reported several days ago, but this patch set is still in discussion, so I am waiting for more days to see if other developers have any other questions. I am confused that how to deal with your patch if I need to

[PATCH RESEND] Staging: greybus: style fix, permissions as octal

Changed permissions to be in octal style. Found by checkpatch. Signed-off-by: Derek Robson --- drivers/staging/greybus/camera.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c

[PATCH RESEND] Staging: greybus: style fix, permissions as octal

Changed permissions to be in octal style. Found by checkpatch. Signed-off-by: Derek Robson --- drivers/staging/greybus/camera.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c index

Re: [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support

Hi Matthias, (Trying again to send plain text email)... On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh wrote: > To support HDMI 4K resolution, mmsys need clcok > mm_sel to be 400MHz. > > The board .dts file should override the clock rate > property with the higher

Re: [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support

Hi Matthias, (Trying again to send plain text email)... On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh wrote: > To support HDMI 4K resolution, mmsys need clcok > mm_sel to be 400MHz. > > The board .dts file should override the clock rate > property with the higher VENCPLL frequency the board >

Re: [greybus-dev] [PATCH v3] staging: greybus: checkpatch: Change parameter type unsigned to unsigned int

On 11-01-17, 16:00, Roman Sommer wrote: > Note that this patch does not fix all checkpatch warnings for the > affected files. > > Signed-off-by: Christian Bewermeyer > Signed-off-by: Roman Sommer > > --- > drivers/staging/greybus/gpio.c |

Re: [greybus-dev] [PATCH v3] staging: greybus: checkpatch: Change parameter type unsigned to unsigned int

On 11-01-17, 16:00, Roman Sommer wrote: > Note that this patch does not fix all checkpatch warnings for the > affected files. > > Signed-off-by: Christian Bewermeyer > Signed-off-by: Roman Sommer > > --- > drivers/staging/greybus/gpio.c | 24 >

Re: net/atm: warning in alloc_tx/__might_sleep

On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko wrote: > On Wed 11-01-17 20:45:25, Michal Hocko wrote: >> On Wed 11-01-17 09:37:06, Chas Williams wrote: >> > On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote: >> > > Hi! >> > > >> > > I've got the following error report

Re: net/atm: warning in alloc_tx/__might_sleep

On Wed, Jan 11, 2017 at 11:46 AM, Michal Hocko wrote: > On Wed 11-01-17 20:45:25, Michal Hocko wrote: >> On Wed 11-01-17 09:37:06, Chas Williams wrote: >> > On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote: >> > > Hi! >> > > >> > > I've got the following error report while running the

  1   2   3   4   5   6   7   8   9   10   >