Re: [PATCH 3/5] s390/pci: Move three assignments for the variable "rc" in clp_normal_command()

Le 21/01/2017 à 19:12, SF Markus Elfring a écrit : @@ -541,9 +543,8 @@ static int clp_normal_command(struct clp_req *req) if (rc) goto out_free; - rc = -EFAULT; if (copy_to_user(uptr, lpcb, PAGE_SIZE) != 0) - goto out_free; + rc =

Re: [PATCH 3/5] s390/pci: Move three assignments for the variable "rc" in clp_normal_command()

Le 21/01/2017 à 19:12, SF Markus Elfring a écrit : @@ -541,9 +543,8 @@ static int clp_normal_command(struct clp_req *req) if (rc) goto out_free; - rc = -EFAULT; if (copy_to_user(uptr, lpcb, PAGE_SIZE) != 0) - goto out_free; + rc =

Re: [PATCH] net/mlx4: use rb_entry()

On Fri, Jan 20, 2017 at 10:36:57PM +0800, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang > --- > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 > 1 file

Re: [PATCH] net/mlx4: use rb_entry()

On Fri, Jan 20, 2017 at 10:36:57PM +0800, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang > --- > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 > 1 file changed, 4 insertions(+),

Re: [PATCH] PCI: rockchip: mark PM functions as __maybe_unused

Hi Arnd, On 2017/1/21 0:24, Arnd Bergmann wrote: When CONFIG_PM_SLEEP is disabled, we get harmless build warnings: host/pcie-rockchip.c:1267:12: error: 'rockchip_pcie_resume_noirq' defined but not used [-Werror=unused-function] host/pcie-rockchip.c:1240:12: error:

Re: [PATCH] PCI: rockchip: mark PM functions as __maybe_unused

Hi Arnd, On 2017/1/21 0:24, Arnd Bergmann wrote: When CONFIG_PM_SLEEP is disabled, we get harmless build warnings: host/pcie-rockchip.c:1267:12: error: 'rockchip_pcie_resume_noirq' defined but not used [-Werror=unused-function] host/pcie-rockchip.c:1240:12: error:

[PATCH v3] vfio error recovery: kernel support

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously.

[PATCH v3] vfio error recovery: kernel support

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously.

[PATCH] Input: max11801_ts - drop call to input_set_drvdata()

Nobody calls input_get_drvdata() so setting it is not required. Signed-off-by: Dmitry Torokhov --- drivers/input/touchscreen/max11801_ts.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/input/touchscreen/max11801_ts.c

[PATCH] Input: max11801_ts - drop call to input_set_drvdata()

Nobody calls input_get_drvdata() so setting it is not required. Signed-off-by: Dmitry Torokhov --- drivers/input/touchscreen/max11801_ts.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/input/touchscreen/max11801_ts.c b/drivers/input/touchscreen/max11801_ts.c index

[PULL] vhost/virtio: cleanups and fixes

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5: Linux 4.10-rc4 (2017-01-15 16:21:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to

[PULL] vhost/virtio: cleanups and fixes

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5: Linux 4.10-rc4 (2017-01-15 16:21:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to

[PATCH] sched: Documentation: sched-rt-group: fix example error

I feel that the example given in the document to show the possibility of task starvation of configurable period is wrong. The example says group A and B both have 50% bandwidth, and a while (1) loop in A will run for the full period of B and can starve B's tasks. So I think the runtime of group

[PATCH] sched: Documentation: sched-rt-group: fix example error

I feel that the example given in the document to show the possibility of task starvation of configurable period is wrong. The example says group A and B both have 50% bandwidth, and a while (1) loop in A will run for the full period of B and can starve B's tasks. So I think the runtime of group

Re: [PATCH v2] vfio error recovery: kernel support

Hi Michael, [auto build test ERROR on vfio/next] [also build test ERROR on v4.10-rc4 next-20170120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2] vfio error recovery: kernel support

Hi Michael, [auto build test ERROR on vfio/next] [also build test ERROR on v4.10-rc4 next-20170120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: Instead of always sending commands in LP mode, respect the MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also request acks if MIPI_DSI_MSG_REQ_ACK is set. Signed-off-by: John

Re: [PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: Instead of always sending commands in LP mode, respect the MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also request acks if MIPI_DSI_MSG_REQ_ACK is set. Signed-off-by: John Keeping --- Unchanged

Re: [PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As an aid to debugging. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As an aid to debugging. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As a side-effect of this, encode the endianness explicitly rather than casting a u16. Signed-off-by: John Keeping --- Unchanged in v2 ---

Re: [PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As a side-effect of this, encode the endianness explicitly rather than casting a u16. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++-- 1 file changed, 7

Re: [PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits are set so we can't just check "val & mask" because that will be true if either bit is set. According to DW mipi dsi

Re: [PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits are set so we can't just check "val & mask" because that will be true if either bit is set. According to DW mipi dsi controller databook, you are

[PATCH v6 1/4] usb: dbc: early driver for xhci debug capability

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. xHCI specification describes DbC in section 7.6. This patch introduces the code to probe and

[PATCH v6 1/4] usb: dbc: early driver for xhci debug capability

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. xHCI specification describes DbC in section 7.6. This patch introduces the code to probe and

[PATCH v6 3/4] usb: serial: add dbc debug device support to usb_debug

This patch adds dbc debug device support to the usb_debug driver. Signed-off-by: Lu Baolu Acked-by: Johan Hovold --- drivers/usb/serial/usb_debug.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git

[PATCH v6 3/4] usb: serial: add dbc debug device support to usb_debug

This patch adds dbc debug device support to the usb_debug driver. Signed-off-by: Lu Baolu Acked-by: Johan Hovold --- drivers/usb/serial/usb_debug.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/usb/serial/usb_debug.c

[PATCH v6 4/4] usb: doc: add document for USB3 debug port usage

Add Documentation/usb/usb3-debug-port.rst. This document includes the user guide for USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 98 +++ 1 file changed, 98

[PATCH v6 4/4] usb: doc: add document for USB3 debug port usage

Add Documentation/usb/usb3-debug-port.rst. This document includes the user guide for USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 98 +++ 1 file changed, 98 insertions(+) create mode 100644

[PATCH v6 2/4] x86: add support for earlyprintk via USB3 debug port

Add support for early printk by writing debug messages to the USB3 debug port. Users can use this type of early printk by specifying kernel parameter of "earlyprintk=xdbc". This gives users a chance of providing debug output. The hardware for USB3 debug port requires DMA memory blocks. This

[PATCH v6 2/4] x86: add support for earlyprintk via USB3 debug port

Add support for early printk by writing debug messages to the USB3 debug port. Users can use this type of early printk by specifying kernel parameter of "earlyprintk=xdbc". This gives users a chance of providing debug output. The hardware for USB3 debug port requires DMA memory blocks. This

[PATCH v6 0/4] usb: early: add support for early printk through USB3 debug port

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework

[PATCH v6 0/4] usb: early: add support for early printk through USB3 debug port

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework

Re: [PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This is not needed since we can access the mode via the CRTC from the enable hook. Also remove the "mode" field that is no longer used. Signed-off-by: John Keeping --- New

Re: [PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This is not needed since we can access the mode via the CRTC from the enable hook. Also remove the "mode" field that is no longer used. Signed-off-by: John Keeping --- New in v2 ---

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c497f8d17246720afe680ea1a8fa6e48e75af852 commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a builtin device tree blob in the

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c497f8d17246720afe680ea1a8fa6e48e75af852 commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a builtin device tree blob in the

[PATCH v2] vfio error recovery: kernel support

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously.

[PATCH v2] vfio error recovery: kernel support

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously.

Re: [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Sean, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.10-rc4 next-20170120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC

Hi Sean, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.10-rc4 next-20170120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] Staging: rtl8188eu: os_dep: usb_ops_linux.c - style fix

Fixed comparison, moved the constant to the right side of the test Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] Staging: rtl8188eu: os_dep: usb_ops_linux.c - style fix

Fixed comparison, moved the constant to the right side of the test Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c

Questions about process statistics

Hello, Recently I noticed that in the early versions, the kernel scheduler suffers from such an attack, http://static.usenix.org/event/sec07/tech/full_papers/tsafrir/tsafrir_html/ and it has already been fixed by introducing CFS and nanosecond granularity accounting. However, as to the

Questions about process statistics

Hello, Recently I noticed that in the early versions, the kernel scheduler suffers from such an attack, http://static.usenix.org/event/sec07/tech/full_papers/tsafrir/tsafrir_html/ and it has already been fixed by introducing CFS and nanosecond granularity accounting. However, as to the

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/22/17 10:58), zhouxianrong wrote: > 1. memset is just set a int value but i want to set a long value. ah... ok. because you union it with the handle. > 2. using clear_page rather than memset MAYBE due to in arm64 arch >it is a 64-bytes operations. clear_page() basically does

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/22/17 10:58), zhouxianrong wrote: > 1. memset is just set a int value but i want to set a long value. ah... ok. because you union it with the handle. > 2. using clear_page rather than memset MAYBE due to in arm64 arch >it is a 64-bytes operations. clear_page() basically does

[PATCH] Staging: greybus: gpio.c - style fix

Fixed bare use of 'unsigned', Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/greybus/gpio.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c

[PATCH] Staging: greybus: gpio.c - style fix

Fixed bare use of 'unsigned', Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/greybus/gpio.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c index

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

On Sun, Jan 22, 2017 at 10:41:22AM +0800, Jason Wang wrote: > > > On 2017年01月21日 00:45, Michael S. Tsirkin wrote: > > On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote: > > > Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on > > > xmit") in fact disables

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

On Sun, Jan 22, 2017 at 10:41:22AM +0800, Jason Wang wrote: > > > On 2017年01月21日 00:45, Michael S. Tsirkin wrote: > > On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote: > > > Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on > > > xmit") in fact disables

Re: [PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This shows that we only use the mode from the enable function and prepares us to remove the "mode" field and the mode_set hook in the next commit. Signed-off-by: John Keeping

Re: [PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This shows that we only use the mode from the enable function and prepares us to remove the "mode" field and the mode_set hook in the next commit. Signed-off-by: John Keeping --- New in v2 ---

Re: [PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the commit function (or even the enable function, but switching from commit to enable is left for a future

Re: [PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the commit function (or even the enable function, but switching from commit to enable is left for a future

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4c9eff7af69c61749b9eb09141f18f35edbf2210 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4c9eff7af69c61749b9eb09141f18f35edbf2210 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

Hi, On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote: > On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote: > > You can use > > > > cpuid_feature_extract(CPUID_EXT_PFR1, 4) > > > > and add a comment explaining what we are looking for and why. W.r.t comments,

Re: [PATCH 2/4] ARM: nommu: dynamic exception base address setting

Hi, On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote: > On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote: > > You can use > > > > cpuid_feature_extract(CPUID_EXT_PFR1, 4) > > > > and add a comment explaining what we are looking for and why. W.r.t comments,

Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases

On 01/20/2017 09:16 PM, Ulf Hansson wrote: On 20 January 2017 at 03:21, Elaine Zhang wrote: If a PM domain is powered off before system suspend, we hope do nothing in system runtime suspend noirq phase and system runtime resume noirq phase. One can hope, but that

Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases

On 01/20/2017 09:16 PM, Ulf Hansson wrote: On 20 January 2017 at 03:21, Elaine Zhang wrote: If a PM domain is powered off before system suspend, we hope do nothing in system runtime suspend noirq phase and system runtime resume noirq phase. One can hope, but that isn't good enough. :-)

[PATCH] iio: trigger: close race condition in acquiring trigger reference

In iio_trigger_write_current() we find the trigger we want while holding mutex on the list of triggers, but we don't actually do a get on it while holding mutex. We wait until further validations are completed and we're sure it's the one we want. Race condition is that it could be freed by the

[PATCH] iio: trigger: close race condition in acquiring trigger reference

In iio_trigger_write_current() we find the trigger we want while holding mutex on the list of triggers, but we don't actually do a get on it while holding mutex. We wait until further validations are completed and we're sure it's the one we want. Race condition is that it could be freed by the

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

Hi, On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote: > On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote: > > +#define VECTORS_BASE 0x > > This should be UL(0x) This has been taken care in v2. Regards afzal

Re: [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

Hi, On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote: > On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote: > > +#define VECTORS_BASE 0x > > This should be UL(0x) This has been taken care in v2. Regards afzal

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed --- arch/arm/kernel/head-nommu.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/kernel/head-nommu.S

[PATCH v2 4/4] ARM: nommu: remove Hivecs configuration is asm

Now that exception based address is handled dynamically for processors with CP15, remove Hivecs configuration in assembly. Signed-off-by: afzal mohammed --- arch/arm/kernel/head-nommu.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/kernel/head-nommu.S

[PATCH v2 3/4] ARM: nommu: display vectors base

The exception base address is now dynamically estimated for no-MMU, display it. As it is the case, now limit VECTORS_BASE usage to MMU scenario. Signed-off-by: afzal mohammed --- v2: A change to accomodate bisectability resolution on patch 1/4

[PATCH v2 3/4] ARM: nommu: display vectors base

The exception base address is now dynamically estimated for no-MMU, display it. As it is the case, now limit VECTORS_BASE usage to MMU scenario. Signed-off-by: afzal mohammed --- v2: A change to accomodate bisectability resolution on patch 1/4 arch/arm/include/asm/memory.h | 4 ++--

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

No-MMU dynamic exception base address configuration on CP15 processors. In the case of low vectors, decision based on whether security extensions are enabled & whether remap vectors to RAM CONFIG option is selected. For no-MMU without CP15, current default value of 0x0 is retained.

[PATCH v2 2/4] ARM: nommu: dynamic exception base address setting

No-MMU dynamic exception base address configuration on CP15 processors. In the case of low vectors, decision based on whether security extensions are enabled & whether remap vectors to RAM CONFIG option is selected. For no-MMU without CP15, current default value of 0x0 is retained.

[PATCH v2 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

For MMU configurations, VECTORS_BASE is always 0x, a macro definition will suffice. For no-MMU, exception base address is dynamically determined in subsequent patches. To preserve bisectability, now make the macro applicable for no-MMU scenario too. Thanks to 0-DAY kernel test

[PATCH v2 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig

For MMU configurations, VECTORS_BASE is always 0x, a macro definition will suffice. For no-MMU, exception base address is dynamically determined in subsequent patches. To preserve bisectability, now make the macro applicable for no-MMU scenario too. Thanks to 0-DAY kernel test

[PATCH v2 0/4] ARM: v7-A !MMU support, prepare CONFIG_VECTORS_BASE removal

Hi, ARM core changes to support !MMU Kernel on v7-A MMU processors. This series also does the preparation for CONFIG_VECTORS_BASE removal. Based on the feedback from Russell, it was decided to handle vector base dynamically in C for no-MMU & work towards the the goal of removing VECTORS_BASE

[PATCH v2 0/4] ARM: v7-A !MMU support, prepare CONFIG_VECTORS_BASE removal

Hi, ARM core changes to support !MMU Kernel on v7-A MMU processors. This series also does the preparation for CONFIG_VECTORS_BASE removal. Based on the feedback from Russell, it was decided to handle vector base dynamically in C for no-MMU & work towards the the goal of removing VECTORS_BASE

Re: [PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: I haven't found any method for getting the length of a response, so this just uses the requested rx_len Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54

Re: [PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: I haven't found any method for getting the length of a response, so this just uses the requested rx_len Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++ 1

[PATCH] serial: hp300: mask the warning for people just doing build coverage

Currently this warning is triggered for allmodconfig on m68k. It is well intentioned, in that if you are building the driver but not enabling one of the platforms where the hardware exists, you get a warning. The warning dates back to pre-git days, and now we have COMPILE_TEST so we can use that

[PATCH] serial: hp300: mask the warning for people just doing build coverage

Currently this warning is triggered for allmodconfig on m68k. It is well intentioned, in that if you are building the driver but not enabling one of the platforms where the hardware exists, you get a warning. The warning dates back to pre-git days, and now we have COMPILE_TEST so we can use that

[GIT PULL] Thermal management updates for v4.10-rc5

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.10-rc5 with top-most commit bad94f8068122b6342a73a218dad7d41e6ea907b:   Merge branches 'thermal-core' and 'thermal-soc' into for-rc

[GIT PULL] Thermal management updates for v4.10-rc5

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.10-rc5 with top-most commit bad94f8068122b6342a73a218dad7d41e6ea907b:   Merge branches 'thermal-core' and 'thermal-soc' into for-rc

Re: [PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

On 01/22/2017 12:31 AM, John Keeping wrote: These values are specified as constant time periods but the PHY configuration is in terms of the current lane byte clock so using constant values guarantees that the timings will be outside the specification with some display configurations. Derive

Re: [PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

On 01/22/2017 12:31 AM, John Keeping wrote: These values are specified as constant time periods but the PHY configuration is in terms of the current lane byte clock so using constant values guarantees that the timings will be outside the specification with some display configurations. Derive

Re: [PATCH] mm: extend zero pages to same element pages for zram

1. memset is just set a int value but i want to set a long value. 2. using clear_page rather than memset MAYBE due to in arm64 arch it is a 64-bytes operations. 6.6.4. Data Cache Zero The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC ZVA) instruction. This enables

Re: [PATCH] mm: extend zero pages to same element pages for zram

1. memset is just set a int value but i want to set a long value. 2. using clear_page rather than memset MAYBE due to in arm64 arch it is a 64-bytes operations. 6.6.4. Data Cache Zero The ARMv8-A architecture introduces a Data Cache Zero by Virtual Address (DC ZVA) instruction. This enables

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote: > On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote: > > add a new compatible string for "mt2712", and a new reference clock > > for SuperSpeed analog phy; > > > > Signed-off-by: Chunfeng Yun > > --- > >

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote: > On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote: > > add a new compatible string for "mt2712", and a new reference clock > > for SuperSpeed analog phy; > > > > Signed-off-by: Chunfeng Yun > > --- > >

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

On 2017年01月21日 00:45, Michael S. Tsirkin wrote: On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote: Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

On 2017年01月21日 00:45, Michael S. Tsirkin wrote: On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote: Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

Hi, On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote: > On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon > > One last question and I'm done: is something like that acceptable? > > > > compatible = ",",","; > > > > This can happen when someone adds support for an unsupported feature > >

Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

Hi, On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote: > On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon > > One last question and I'm done: is something like that acceptable? > > > > compatible = ",",","; > > > > This can happen when someone adds support for an unsupported feature > >

[PATCH] locking/rwsem: Reinit wake_q after use

In __rwsem_down_write_failed_common(), the same wake_q variable name is defined twice, with the inner wake_q hiding the one in outer scope. We can either use different names for the two wake_q's. Even better, we can use the same wake_q twice, if necessary. To enable the latter change, we need to

[PATCH] locking/rwsem: Reinit wake_q after use

In __rwsem_down_write_failed_common(), the same wake_q variable name is defined twice, with the inner wake_q hiding the one in outer scope. We can either use different names for the two wake_q's. Even better, we can use the same wake_q twice, if necessary. To enable the latter change, we need to

Re:Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

I'm sorry. My patch is error. But I just want to get the git version when we use git as SCM. No matter what .git directory where. Thanks. At 2017-01-22 04:54:54, "Nico Schottelius" wrote: > >Hello Xufeng, > >why do you think redirecting *all*

Re:Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

I'm sorry. My patch is error. But I just want to get the git version when we use git as SCM. No matter what .git directory where. Thanks. At 2017-01-22 04:54:54, "Nico Schottelius" wrote: > >Hello Xufeng, > >why do you think redirecting *all* output to /dev/null is the right >thing todo? >

Re: [PATCH v11 2/8] power: add power sequence library

On Fri, Jan 20, 2017 at 11:21:27AM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 20, 2017 at 8:52 AM, Peter Chen wrote: > > On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote: > >> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote: > >> > On Thu,

Re: [PATCH v11 2/8] power: add power sequence library

On Fri, Jan 20, 2017 at 11:21:27AM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 20, 2017 at 8:52 AM, Peter Chen wrote: > > On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote: > >> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote: > >> > On Thu, Jan 05, 2017 at

Re: [PATCH v7 2/5] usb: chipidea: msm: Configure phy for appropriate mode

On Fri, Jan 20, 2017 at 10:50:54AM -0800, Stephen Boyd wrote: > When the qcom chipidea controller is used with an extcon, we need > to signal device mode or host mode to the phy so it can configure > itself for the correct mode. This should be done after the phy is > powered up, so that the

Re: [PATCH v7 2/5] usb: chipidea: msm: Configure phy for appropriate mode

On Fri, Jan 20, 2017 at 10:50:54AM -0800, Stephen Boyd wrote: > When the qcom chipidea controller is used with an extcon, we need > to signal device mode or host mode to the phy so it can configure > itself for the correct mode. This should be done after the phy is > powered up, so that the

  1   2   3   4   5   6   >