Re: fsl-dcu not works on latest "drm-next"

On 2016-05-26 02:11, Alexander Stein wrote: > On Thursday 26 May 2016 08:23:42, Meng Yi wrote: >> Hi Mark, >> >> > You've not specifically described the problem here - what are the >> > endiannesses of both the CPU and the device you're talking to? What >> > specifically is the endianess problem

Re: fsl-dcu not works on latest "drm-next"

On 2016-05-26 02:11, Alexander Stein wrote: > On Thursday 26 May 2016 08:23:42, Meng Yi wrote: >> Hi Mark, >> >> > You've not specifically described the problem here - what are the >> > endiannesses of both the CPU and the device you're talking to? What >> > specifically is the endianess problem

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > From: Yury Norov > Date: Tue, 24 May 2016 03:04:30 +0300 > > > +To clear that top halves, automatic wrappers are introduced. They clear all > > +required registers before passing control to regular syscall

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > From: Yury Norov > Date: Tue, 24 May 2016 03:04:30 +0300 > > > +To clear that top halves, automatic wrappers are introduced. They clear all > > +required registers before passing control to regular syscall handler. > > Why have one

Re: [PATCH v7 2/4] CMDQ: Mediatek CMDQ driver

Hi CK, Reply in line. On Thu, 2016-05-26 at 15:28 +0800, CK Hu wrote: > Hi, HS: > > Replay inline. > > On Tue, 2016-05-24 at 20:27 +0800, Horng-Shyang Liao wrote: > > Hi CK, > > > > Reply in line. > > > > On Tue, 2016-05-24 at 11:05 +0800, CK Hu wrote: > > > Hi, HS: > > > > > > Some

Re: [PATCH v7 2/4] CMDQ: Mediatek CMDQ driver

Hi CK, Reply in line. On Thu, 2016-05-26 at 15:28 +0800, CK Hu wrote: > Hi, HS: > > Replay inline. > > On Tue, 2016-05-24 at 20:27 +0800, Horng-Shyang Liao wrote: > > Hi CK, > > > > Reply in line. > > > > On Tue, 2016-05-24 at 11:05 +0800, CK Hu wrote: > > > Hi, HS: > > > > > > Some

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

2016-05-26 10:53 GMT+08:00 Steve Muckle : > The slow-path frequency transition path is relatively expensive as it > requires waking up a thread to do work. Should support be added for > remote CPU cpufreq updates that is also expensive since it requires an > IPI. These

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

2016-05-26 10:53 GMT+08:00 Steve Muckle : > The slow-path frequency transition path is relatively expensive as it > requires waking up a thread to do work. Should support be added for > remote CPU cpufreq updates that is also expensive since it requires an > IPI. These activities should be avoided

Re: [PATCH v3 5/6] mm/cma: remove MIGRATE_CMA

On Fri, May 27, 2016 at 09:42:24AM +0800, Chen Feng wrote: > Hi Joonsoo, > > -/* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > > +/* Free whole pageblock and set its migration type to MIGRATE_MOVABLE. */ > > void __init init_cma_reserved_pageblock(struct page *page) > > {

Re: [PATCH v3 5/6] mm/cma: remove MIGRATE_CMA

On Fri, May 27, 2016 at 09:42:24AM +0800, Chen Feng wrote: > Hi Joonsoo, > > -/* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > > +/* Free whole pageblock and set its migration type to MIGRATE_MOVABLE. */ > > void __init init_cma_reserved_pageblock(struct page *page) > > {

Re: [PATCH v3 0/6] Introduce ZONE_CMA

On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote: > On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote: > > From: Joonsoo Kim > > Hi Joonsoo, > > Nice work! Thanks! > > FYI, there is another attempt [3] trying to solve this problem in lkml. > >

Re: [PATCH v3 0/6] Introduce ZONE_CMA

On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote: > On Thu, May 26, 2016 at 02:22:22PM +0800, js1...@gmail.com wrote: > > From: Joonsoo Kim > > Hi Joonsoo, > > Nice work! Thanks! > > FYI, there is another attempt [3] trying to solve this problem in lkml. > > And, as far as I know,

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Thu, May 26, 2016 at 1:33 PM, Michal Marek wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild This pull results in new warnings. I get new "may be uninitialized" warnings now for me allmodconfig build, and while I didn't look at them all, the

Re: [GIT PULL] kbuild updates for v4.7-rc1

On Thu, May 26, 2016 at 1:33 PM, Michal Marek wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild This pull results in new warnings. I get new "may be uninitialized" warnings now for me allmodconfig build, and while I didn't look at them all, the one I looked at

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: > On 5/25/2016 5:37 PM, Minchan Kim wrote: > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: > >>>Per the discussion with Joonsoo Kim [1], we need check the return

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: > On 5/25/2016 5:37 PM, Minchan Kim wrote: > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: > >>>Per the discussion with Joonsoo Kim [1], we need check the return

RE: [PATCH v4] extcon: gpio: Add the support for Device tree bindings

Hi Choi, Sorry for changing author, will update author field with your name. Regarding Rob Herring comments, You had already replied. I felt separate compatible for each external connector is not required, as client driver can detect the type of external cable(sdp,dcp, microphone) on receiving

RE: [PATCH v4] extcon: gpio: Add the support for Device tree bindings

Hi Choi, Sorry for changing author, will update author field with your name. Regarding Rob Herring comments, You had already replied. I felt separate compatible for each external connector is not required, as client driver can detect the type of external cable(sdp,dcp, microphone) on receiving

Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On 27 May 2016 at 05:41, Peter Chen wrote: > On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: >> Hello, >> >> I was updating my config by make oldconfig for a while and noticed that my >> USB >> OTG controller is not working. Apparently it grew dependency

Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On 27 May 2016 at 05:41, Peter Chen wrote: > On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: >> Hello, >> >> I was updating my config by make oldconfig for a while and noticed that my >> USB >> OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV >> over

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

Hi Michal, On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek wrote: > On 27 May 2016 at 04:05, Julian Calaby wrote: >> Hi Michal, >> >> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: >>> The trasfer timeout is fixed at

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

Hi Michal, On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek wrote: > On 27 May 2016 at 04:05, Julian Calaby wrote: >> Hi Michal, >> >> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: >>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over >>> 1MHz SPI bus takes way

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

On 27 May 2016 at 04:05, Julian Calaby wrote: > Hi Michal, > > On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: >> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over >> 1MHz SPI bus takes way longer than that. Calculate the

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

On 27 May 2016 at 04:05, Julian Calaby wrote: > Hi Michal, > > On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: >> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over >> 1MHz SPI bus takes way longer than that. Calculate the timeout from the >> actual time the transfer is

Re: [PATCH 5/7] zram: use crypto api to check alg availability

Hello Sergey, I want to know more how it works so below questions goes. On Wed, May 25, 2016 at 11:30:04PM +0900, Sergey Senozhatsky wrote: > There is no way to get a string with all the crypto comp > algorithms supported by the crypto comp engine, so we need > to maintain our own backends list.

Re: [PATCH 5/7] zram: use crypto api to check alg availability

Hello Sergey, I want to know more how it works so below questions goes. On Wed, May 25, 2016 at 11:30:04PM +0900, Sergey Senozhatsky wrote: > There is no way to get a string with all the crypto comp > algorithms supported by the crypto comp engine, so we need > to maintain our own backends list.

Re: [f2fs-dev] [PATCH 1/4] f2fs: propagate error given by f2fs_find_entry

On 2016/5/27 8:25, Jaegeuk Kim wrote: If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away. Otherwise, for example, we can get duplicate directory entry by ->chash and ->clevel. Signed-off-by: Jaegeuk Kim --- fs/f2fs/dir.c| 23 ---

Re: [f2fs-dev] [PATCH 1/4] f2fs: propagate error given by f2fs_find_entry

On 2016/5/27 8:25, Jaegeuk Kim wrote: If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away. Otherwise, for example, we can get duplicate directory entry by ->chash and ->clevel. Signed-off-by: Jaegeuk Kim --- fs/f2fs/dir.c| 23 --- fs/f2fs/inline.c |

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 05:18, Darrick J. Wong wrote: > > It's possible that the pvscsi device advertised WRITE SAME, but if the device > sends back ILLEGAL REQUEST then the SCSI disk driver will set > write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue

Re: BLKZEROOUT not zeroing md dev on VMDK

On 27 May 2016 at 05:18, Darrick J. Wong wrote: > > It's possible that the pvscsi device advertised WRITE SAME, but if the device > sends back ILLEGAL REQUEST then the SCSI disk driver will set > write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue writes > of zeroes to the

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: > On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: >> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: >>> One problem with seccomp was that ptrace could be used to

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 7:41 PM, Kees Cook wrote: > On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: >> On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: >>> One problem with seccomp was that ptrace could be used to change a >>> syscall after seccomp filtering had completed. This was a

Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: > There is a double free problem in the usb driver. Which driver? > This is caused by delayed deregister for scsi device. > <*> at Insert USB Storage > - USB bus #1 register > usb_create_hcd (primary-kref==1) > *

Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: > There is a double free problem in the usb driver. Which driver? > This is caused by delayed deregister for scsi device. > <*> at Insert USB Storage > - USB bus #1 register > usb_create_hcd (primary-kref==1) > *

Re: [PATCH 4/7] zram: align zcomp interface to crypto comp API

On Wed, May 25, 2016 at 11:30:03PM +0900, Sergey Senozhatsky wrote: > A cosmetic change: use the same datatypes as crypto API does. > > Signed-off-by: Sergey Senozhatsky > Cc: Minchan Kim > Cc: Joonsoo Kim > --- >

Re: [PATCH 4/7] zram: align zcomp interface to crypto comp API

On Wed, May 25, 2016 at 11:30:03PM +0900, Sergey Senozhatsky wrote: > A cosmetic change: use the same datatypes as crypto API does. > > Signed-off-by: Sergey Senozhatsky > Cc: Minchan Kim > Cc: Joonsoo Kim > --- > drivers/block/zram/zcomp.c| 5 ++--- > drivers/block/zram/zcomp.h| 5

Re: [PATCH v2 1/2] dt: binding: Add Qualcomm WCNSS control binding

On Thu 26 May 20:58 PDT 2016, Rob Herring wrote: > +dt list > > On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson > wrote: [..] > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt > > b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt

Re: [PATCH v2 1/2] dt: binding: Add Qualcomm WCNSS control binding

On Thu 26 May 20:58 PDT 2016, Rob Herring wrote: > +dt list > > On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson > wrote: [..] > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt > > b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt > > new file mode 100644 > >

Re: [PATCH 3/7] zram: drop zcomp param from compress/decompress

On Wed, May 25, 2016 at 11:30:02PM +0900, Sergey Senozhatsky wrote: > We don't need to supply a zcomp pointer to compress/decompress > functions, drop it. > > Signed-off-by: Sergey Senozhatsky > Cc: Minchan Kim > Cc: Joonsoo Kim

Re: [PATCH 3/7] zram: drop zcomp param from compress/decompress

On Wed, May 25, 2016 at 11:30:02PM +0900, Sergey Senozhatsky wrote: > We don't need to supply a zcomp pointer to compress/decompress > functions, drop it. > > Signed-off-by: Sergey Senozhatsky > Cc: Minchan Kim > Cc: Joonsoo Kim Could you fold this patch into previous one? > --- >

Re: [PATCH 2/7] zram: switch to crypto compress API

On Wed, May 25, 2016 at 11:30:01PM +0900, Sergey Senozhatsky wrote: > We don't have an idle zstreams list anymore and our write path > now works absolutely differently, preventing preemption during > compression. This removes possibilities of read paths preempting > writes at wrong places (which

Re: [PATCH 2/7] zram: switch to crypto compress API

On Wed, May 25, 2016 at 11:30:01PM +0900, Sergey Senozhatsky wrote: > We don't have an idle zstreams list anymore and our write path > now works absolutely differently, preventing preemption during > compression. This removes possibilities of read paths preempting > writes at wrong places (which

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown) wrote: > > > On 2016/5/26 21:13, Rob Herring wrote: >> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >>> For a normal memory@ devicetree node, its reg property can contains more >>> memory blocks. >>>

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown) wrote: > > > On 2016/5/26 21:13, Rob Herring wrote: >> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >>> For a normal memory@ devicetree node, its reg property can contains more >>> memory blocks. >>> >>> Because we don't known

RE: [PATCH] Use the correct size to set block max sectors

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Thursday, May 26, 2016 7:19 PM > To: Long Li ; James E.J. Bottomley > ; Martin K. Petersen > > Cc: KY Srinivasan

RE: [PATCH] Use the correct size to set block max sectors

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Thursday, May 26, 2016 7:19 PM > To: Long Li ; James E.J. Bottomley > ; Martin K. Petersen > > Cc: KY Srinivasan ; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH]

Re: BLKZEROOUT not zeroing md dev on VMDK

On Wed, May 18, 2016 at 11:39:30PM +0100, Sitsofe Wheeler wrote: > Hi, > > With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23 > 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the > BLKZEROOUT syscall can malfunction and not zero data. > > When BLKZEROOUT is issued to an MD device

Re: BLKZEROOUT not zeroing md dev on VMDK

On Wed, May 18, 2016 at 11:39:30PM +0100, Sitsofe Wheeler wrote: > Hi, > > With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23 > 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the > BLKZEROOUT syscall can malfunction and not zero data. > > When BLKZEROOUT is issued to an MD device

Re: [PATCH 2/2] mmc: dw_mmc: check card present before starting request

在 2016/5/27 11:46, Jaehoon Chung 写道: Hi Shawn, On 05/27/2016 12:02 PM, Shawn Lin wrote: The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for

Re: [PATCH 2/2] mmc: dw_mmc: check card present before starting request

在 2016/5/27 11:46, Jaehoon Chung 写道: Hi Shawn, On 05/27/2016 12:02 PM, Shawn Lin wrote: The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for

Re: [PATCH 1/1] net: nps_enet: Disable interrupts before napi reschedule

Hi Elad, Noam, On Thursday 26 May 2016 11:23 PM, Alexey Brodkin wrote: > > We just bumped into the same problem (data exchange hangs on the very first > "ping") > with released Linux v4.6 and linux-next on our nSIM OSCI virtual platform. > > I believe it was commit 05c00d82f4d1 ("net:

Re: [PATCH 1/1] net: nps_enet: Disable interrupts before napi reschedule

Hi Elad, Noam, On Thursday 26 May 2016 11:23 PM, Alexey Brodkin wrote: > > We just bumped into the same problem (data exchange hangs on the very first > "ping") > with released Linux v4.6 and linux-next on our nSIM OSCI virtual platform. > > I believe it was commit 05c00d82f4d1 ("net:

Re: [PATCH v2 1/2] dt: binding: Add Qualcomm WCNSS control binding

+dt list On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson wrote: > This binding describes the control interface for the Qualcomm WCNSS. > > Signed-off-by: Bjorn Andersson > --- > > Changes since v1: > - Introduce reference to wcnss block

Re: [PATCH v2 1/2] dt: binding: Add Qualcomm WCNSS control binding

+dt list On Thu, May 12, 2016 at 6:17 PM, Bjorn Andersson wrote: > This binding describes the control interface for the Qualcomm WCNSS. > > Signed-off-by: Bjorn Andersson > --- > > Changes since v1: > - Introduce reference to wcnss block node for register block definition > - Use wcnss block

RE: [PATCH] ACPICA / hardware: Fix address check in acpi_hw_get_access_bit_width()

Hi, Boris Can you help to confirm if this can fix all of the issues you saw in the older qemu. Thanks and best regards -Lv > From: Zheng, Lv > Subject: [PATCH] ACPICA / hardware: Fix address check in > acpi_hw_get_access_bit_width() > > The address check in acpi_hw_get_access_bit_width()

RE: [PATCH] ACPICA / hardware: Fix address check in acpi_hw_get_access_bit_width()

Hi, Boris Can you help to confirm if this can fix all of the issues you saw in the older qemu. Thanks and best regards -Lv > From: Zheng, Lv > Subject: [PATCH] ACPICA / hardware: Fix address check in > acpi_hw_get_access_bit_width() > > The address check in acpi_hw_get_access_bit_width()

Re: [PATCH] perf script: Fix display inconsitency when call-graph config is used

ping.. 在 2016/5/16 12:51, He Kuang 写道: There's a display inconsistency when 'call-graph' config event appears in different position. The problem can be reproduced like this: We record signal_deliver with call-graph and signal_generate without it. $ perf record -g -a -e

Re: [PATCH] perf script: Fix display inconsitency when call-graph config is used

ping.. 在 2016/5/16 12:51, He Kuang 写道: There's a display inconsistency when 'call-graph' config event appears in different position. The problem can be reproduced like this: We record signal_deliver with call-graph and signal_generate without it. $ perf record -g -a -e

Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: > Hello, > > I was updating my config by make oldconfig for a while and noticed that my USB > OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV > over time. > > Looking through defconfigs some have it

Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: > Hello, > > I was updating my config by make oldconfig for a while and noticed that my USB > OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV > over time. > > Looking through defconfigs some have it

Re: [PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Shawn, On 05/27/2016 12:02 PM, Shawn Lin wrote: > The main reason to add this check is to avoid unnecessary > mmc_request like the on-going cmd and the corresponding sbc > if the card is removed. Although we have already checked this in > dw_mci_handle_cd for runtime usage of sd card and

Re: [PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Shawn, On 05/27/2016 12:02 PM, Shawn Lin wrote: > The main reason to add this check is to avoid unnecessary > mmc_request like the on-going cmd and the corresponding sbc > if the card is removed. Although we have already checked this in > dw_mci_handle_cd for runtime usage of sd card and

Re: [PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

Hi Vincent, On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote: > On 26 May 2016 at 03:14, Yuyang Du wrote: > > Vincent reported that the first task to a new task group's cfs_rq will > > be attached in attach_task_cfs_rq() and once more when it is enqueued > >

Re: [PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task

Hi Vincent, On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote: > On 26 May 2016 at 03:14, Yuyang Du wrote: > > Vincent reported that the first task to a new task group's cfs_rq will > > be attached in attach_task_cfs_rq() and once more when it is enqueued > > (see

[PATCH] ACPICA / hardware: Fix address check in acpi_hw_get_access_bit_width()

The address check in acpi_hw_get_access_bit_width() should be byte size based, not bit width based. This patch fixes this mistake. Reported-by: Boris Ostrovsky Suggested-by: Jan Beulich Signed-off-by: Lv Zheng ---

[PATCH] ACPICA / hardware: Fix address check in acpi_hw_get_access_bit_width()

The address check in acpi_hw_get_access_bit_width() should be byte size based, not bit width based. This patch fixes this mistake. Reported-by: Boris Ostrovsky Suggested-by: Jan Beulich Signed-off-by: Lv Zheng --- drivers/acpi/acpica/hwregs.c |2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On 2016/5/26 21:13, Rob Herring wrote: > On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >> from index=0,

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On 2016/5/26 21:13, Rob Herring wrote: > On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >> from index=0,

Re: [RFC 4/5] ARM: tegra: Enable UDC on Dalmore

On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Override the compatible string of the first USB controller to enable > device mode. > > Signed-off-by: Thierry Reding > --- >

linux-next: Tree for May 27

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160526: My fixes tree contains this: mm/cma: silence warnings due to max() usage Non-merge commits (relative to Linus' tree): 883 837 files

Re: [RFC 4/5] ARM: tegra: Enable UDC on Dalmore

On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Override the compatible string of the first USB controller to enable > device mode. > > Signed-off-by: Thierry Reding > --- > arch/arm/boot/dts/tegra114-dalmore.dts | 11 +++ > 1 file changed,

linux-next: Tree for May 27

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160526: My fixes tree contains this: mm/cma: silence warnings due to max() usage Non-merge commits (relative to Linus' tree): 883 837 files

RE: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Friday, May 27, 2016 12:56 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access > bit width support > > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky

RE: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Friday, May 27, 2016 12:56 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access > bit width support > > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky 05/25/16 9:17 > PM >>> > >> On

Re: [PATCH v2] ARM: avoid duplicated "Kernel: arch/arm/boot/*Image is ready" log

Hi. Assuming no objection to this patch, I will put it into Russell's patch tracker after v4.7-rc1 is out. 2016-04-04 11:29 GMT+09:00 Masahiro Yamada : > Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not > generate invalid images") fixed bad

Re: [PATCH v2] ARM: avoid duplicated "Kernel: arch/arm/boot/*Image is ready" log

Hi. Assuming no objection to this patch, I will put it into Russell's patch tracker after v4.7-rc1 is out. 2016-04-04 11:29 GMT+09:00 Masahiro Yamada : > Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not > generate invalid images") fixed bad image generation in case of >

Re: [RFC 0/5] usb: chipidea: Add support for Tegra20 through Tegra124

On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote: > From: Thierry Reding > > All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea > USB device controller. This set of patches adds very rudimentary support > for it to the existing ChipIdea

Re: [RFC 0/5] usb: chipidea: Add support for Tegra20 through Tegra124

On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote: > From: Thierry Reding > > All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea > USB device controller. This set of patches adds very rudimentary support > for it to the existing ChipIdea driver and enables them

RE: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky > Sent: Thursday, May 26, 2016 3:17 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit > width support > > On 05/05/2016 12:58 AM, Lv Zheng wrote: > >

RE: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky > Sent: Thursday, May 26, 2016 3:17 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit > width support > > On 05/05/2016 12:58 AM, Lv Zheng wrote: > >

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

Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: mm/oom_kill.c: In function '__oom_reap_task': mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized] mmput_async(mm); ^

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

Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: mm/oom_kill.c: In function '__oom_reap_task': mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized] mmput_async(mm); ^

[PATCH 2/2] mmc: dw_mmc: check card present before starting request

The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing

[PATCH 2/2] mmc: dw_mmc: check card present before starting request

The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing

[PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

dw_mci_get_cd have already dealt with these for both of internal card-detect and gpio card-detect. Signed-off-by: Shawn Lin --- drivers/mmc/host/dw_mmc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c

[PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

dw_mci_get_cd have already dealt with these for both of internal card-detect and gpio card-detect. Signed-off-by: Shawn Lin --- drivers/mmc/host/dw_mmc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index

Re: [PATCH] Use the correct size to set block max sectors

On 05/26/16 17:08, Long Li wrote: The block sector size should be in unit of 512 bytes, not in bytes. Signed-off-by: Long Li --- drivers/scsi/sd.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Re: [PATCH] Use the correct size to set block max sectors

On 05/26/16 17:08, Long Li wrote: The block sector size should be in unit of 512 bytes, not in bytes. Signed-off-by: Long Li --- drivers/scsi/sd.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 428c03e..4bce17e 100644 ---

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: > On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: >> One problem with seccomp was that ptrace could be used to change a >> syscall after seccomp filtering had completed. This was a well

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski wrote: > On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: >> One problem with seccomp was that ptrace could be used to change a >> syscall after seccomp filtering had completed. This was a well documented >> limitation, and it was recommended to

Re: [PATCH 3/3] arm64/numa: fix type info

On 2016/5/27 1:12, David Daney wrote: > The current patch to correct this problem is here: > > https://lkml.org/lkml/2016/5/24/679 > > Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next > as soon as the current merge window ends, further simplifications of the >

Re: [PATCH 3/3] arm64/numa: fix type info

On 2016/5/27 1:12, David Daney wrote: > The current patch to correct this problem is here: > > https://lkml.org/lkml/2016/5/24/679 > > Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next > as soon as the current merge window ends, further simplifications of the >

Re: [RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Jaehoon, On 2016/5/27 8:53, Jaehoon Chung wrote: Hi Shawn, On 05/26/2016 12:08 PM, Shawn Lin wrote: The main reason to add this check is to avoid unnecessary mmc_request if the card is removed. Although we have already check this in dw_mci_handle_cd for runtime usage of sd card and

Re: [RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Jaehoon, On 2016/5/27 8:53, Jaehoon Chung wrote: Hi Shawn, On 05/26/2016 12:08 PM, Shawn Lin wrote: The main reason to add this check is to avoid unnecessary mmc_request if the card is removed. Although we have already check this in dw_mci_handle_cd for runtime usage of sd card and

Re: [RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

在 2016/5/27 8:53, Jaehoon Chung 写道: Hi Shawn, On 05/26/2016 12:07 PM, Shawn Lin wrote: dw_mci_get_cd have already dealed with these for both of internal card-detect and gpio card-detect. s/dealed/dealt This patch looks good to me. Could you resend the patch? not RFC. Ok. Best Regards,

Re: [RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

在 2016/5/27 8:53, Jaehoon Chung 写道: Hi Shawn, On 05/26/2016 12:07 PM, Shawn Lin wrote: dw_mci_get_cd have already dealed with these for both of internal card-detect and gpio card-detect. s/dealed/dealt This patch looks good to me. Could you resend the patch? not RFC. Ok. Best Regards,

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 2:46 PM, Sage Weil wrote: > > One point of clarification, though: in the past I've squashed down fixes > discovered during testing if the branch hasn't hit a stable tree yet > (e.g., your tree). AIUI this is(was?) standard procedure for things in >

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 2:46 PM, Sage Weil wrote: > > One point of clarification, though: in the past I've squashed down fixes > discovered during testing if the branch hasn't hit a stable tree yet > (e.g., your tree). AIUI this is(was?) standard procedure for things in > -next. Yes, rebasing

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: > One problem with seccomp was that ptrace could be used to change a > syscall after seccomp filtering had completed. This was a well documented > limitation, and it was recommended to block ptrace when defining a filter >

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 2:04 PM, Kees Cook wrote: > One problem with seccomp was that ptrace could be used to change a > syscall after seccomp filtering had completed. This was a well documented > limitation, and it was recommended to block ptrace when defining a filter > to avoid this problem.

  1   2   3   4   5   6   7   8   9   >