Re: [PATCH v2] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On 2016/5/11 23:10, Bjorn Helgaas wrote: On Wed, May 11, 2016 at 07:34:19PM +0800, Yongji Xie wrote: Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. This will cause some performance issues when

Re: [PATCH v2] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On 2016/5/11 23:10, Bjorn Helgaas wrote: On Wed, May 11, 2016 at 07:34:19PM +0800, Yongji Xie wrote: Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. This will cause some performance issues when

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

> -Original Message- > From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com] > Sent: 2016年5月12日 11:53 > To: Yang, Wenyou > Cc: Alan Stern ; Greg Kroah-Hartman > ; Ferre, Nicolas

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

> -Original Message- > From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com] > Sent: 2016年5月12日 11:53 > To: Yang, Wenyou > Cc: Alan Stern ; Greg Kroah-Hartman > ; Ferre, Nicolas ; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- >

linux-next: Tree for May 12

Hi all, Changes since 20160511: The net-next tree gained a conflict against the net tree. The sound-asoc tree lost its build failure. The tip tree gained conflicts against the arc and amr64 trees. The kvm tree gained conflicts against the tip tree. The pinctrl tree gained a build failure so

linux-next: Tree for May 12

Hi all, Changes since 20160511: The net-next tree gained a conflict against the net tree. The sound-asoc tree lost its build failure. The tip tree gained conflicts against the arc and amr64 trees. The kvm tree gained conflicts against the tip tree. The pinctrl tree gained a build failure so

[PATCH] genirq: export __irq_set_affinity symbol

__irq_set_affinity is declared in include/linux/interrupt.h, but not been exported. We export it now, so we could use __irq_set_affinity, irq_set_affinity and irq_force_affinity in kernel modules. Cc: Li Bin Cc: Yijing Wang Signed-off-by: Xie

[PATCH] genirq: export __irq_set_affinity symbol

__irq_set_affinity is declared in include/linux/interrupt.h, but not been exported. We export it now, so we could use __irq_set_affinity, irq_set_affinity and irq_force_affinity in kernel modules. Cc: Li Bin Cc: Yijing Wang Signed-off-by: Xie XiuQi --- kernel/irq/manage.c | 1 + 1 file

Re: [PATCH v2 1/1] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

On Tue, May 10, 2016 at 08:43:34PM +0300, Andy Shevchenko wrote: > When check for capabilities recognize slave support by either DMA_SLAVE or > DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked > DMA support for engines that doesn't have one of the mentioned bits set.

Re: [PATCH v2 1/1] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

On Tue, May 10, 2016 at 08:43:34PM +0300, Andy Shevchenko wrote: > When check for capabilities recognize slave support by either DMA_SLAVE or > DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked > DMA support for engines that doesn't have one of the mentioned bits set.

Re: [PATCH 04/18] dmaengine: st_fdma: Add xp70 firmware loading mechanism.

On Wed, May 11, 2016 at 08:57:40AM +0100, Peter Griffin wrote: > > Above two seem to be generic code and should be moved to core, this way > > other drivers using ELF firmware binaries can reuse... > > Do you mean add to dmaengine.c? Nope this is not specfic to dmaengine. Perhaps drivers/base/..

Re: [PATCH 04/18] dmaengine: st_fdma: Add xp70 firmware loading mechanism.

On Wed, May 11, 2016 at 08:57:40AM +0100, Peter Griffin wrote: > > Above two seem to be generic code and should be moved to core, this way > > other drivers using ELF firmware binaries can reuse... > > Do you mean add to dmaengine.c? Nope this is not specfic to dmaengine. Perhaps drivers/base/..

Re: Question about request queues in I/O scheduling

Hello, I was trying to use spin_trylock(q->queue_lock) on several queues when q->nr_sorted exceeds the per-defined number to block them and unlock the them later with spin_unlock(q->queue_lock), but I have faced the following problem: my system freezes when I am trying to test it by moving

Re: Question about request queues in I/O scheduling

Hello, I was trying to use spin_trylock(q->queue_lock) on several queues when q->nr_sorted exceeds the per-defined number to block them and unlock the them later with spin_unlock(q->queue_lock), but I have faced the following problem: my system freezes when I am trying to test it by moving

[PATCH] kernfs: kernfs_sop_show_path: don't return 0 after seq_dentry call

Our caller expects 0 on success, not >0. This fixes a bug in the patch cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces where /sys does not show up in mountinfo, breaking criu. Thanks for catching this, Andrei. Reported-by: Andrei Vagin

[PATCH] kernfs: kernfs_sop_show_path: don't return 0 after seq_dentry call

Our caller expects 0 on success, not >0. This fixes a bug in the patch cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces where /sys does not show up in mountinfo, breaking criu. Thanks for catching this, Andrei. Reported-by: Andrei Vagin Signed-off-by:

Re: [PATCH 0.14] oom detection rework v6

On Thu, May 12, 2016 at 11:23:34AM +0900, Joonsoo Kim wrote: > On Tue, May 10, 2016 at 11:43:48AM +0200, Michal Hocko wrote: > > On Tue 10-05-16 15:41:04, Joonsoo Kim wrote: > > > 2016-05-05 3:16 GMT+09:00 Michal Hocko : > > > > On Wed 04-05-16 23:32:31, Joonsoo Kim wrote: > > >

Re: [PATCH 0.14] oom detection rework v6

On Thu, May 12, 2016 at 11:23:34AM +0900, Joonsoo Kim wrote: > On Tue, May 10, 2016 at 11:43:48AM +0200, Michal Hocko wrote: > > On Tue 10-05-16 15:41:04, Joonsoo Kim wrote: > > > 2016-05-05 3:16 GMT+09:00 Michal Hocko : > > > > On Wed 04-05-16 23:32:31, Joonsoo Kim wrote: > > > >> 2016-05-04

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the > >end, when > > there is no error. So would it be fine if we do it there > >unconditionally ? > > > >Regards, > > Sricharan > > RESET the QUP state

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the > >end, when > > there is no error. So would it be fine if we do it there > >unconditionally ? > > > >Regards, > > Sricharan > > RESET the QUP state

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Thu, May 12, 2016 at 12:05:37PM +1000, Michael Neuling wrote: > On Wed, 2016-05-11 at 20:24 +0200, Peter Zijlstra wrote: > > On Wed, May 11, 2016 at 02:33:45PM +0200, Peter Zijlstra wrote: > > > > > > Hmm, PPC folks; what does your topology look like? > > > > > > Currently your

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Thu, May 12, 2016 at 12:05:37PM +1000, Michael Neuling wrote: > On Wed, 2016-05-11 at 20:24 +0200, Peter Zijlstra wrote: > > On Wed, May 11, 2016 at 02:33:45PM +0200, Peter Zijlstra wrote: > > > > > > Hmm, PPC folks; what does your topology look like? > > > > > > Currently your

Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for DMA Mode

On Wed, May 11, 2016 at 06:41:26PM -0700, Stephen Boyd wrote: > On 05/10, Abhishek Sahu wrote: > > From: Charanya > > Was it intentional to only have one name here? > > > > > The Data loss was happening with current QCOM MSM serial driver during > > large file transfer

Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for DMA Mode

On Wed, May 11, 2016 at 06:41:26PM -0700, Stephen Boyd wrote: > On 05/10, Abhishek Sahu wrote: > > From: Charanya > > Was it intentional to only have one name here? > > > > > The Data loss was happening with current QCOM MSM serial driver during > > large file transfer due to simultaneous

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 11, 2016 4:24:09 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 07:15:19AM -0400, Brian Gerst wrote: > >> I think he meant the out of line version would be asm, so you could >> control what registers were clobbered. > >Yeah, it might save a few cycles on the

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 11, 2016 4:24:09 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 07:15:19AM -0400, Brian Gerst wrote: > >> I think he meant the out of line version would be asm, so you could >> control what registers were clobbered. > >Yeah, it might save a few cycles on the call, but given that

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, May 12, 2016 10:21 AM > > On Thu, 12 May 2016 01:19:44 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, May 11, 2016 11:54 PM

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, May 12, 2016 10:21 AM > > On Thu, 12 May 2016 01:19:44 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, May 11, 2016 11:54 PM > > > > > > On Wed, 11

Re: [PATCH] tty: serial: msm: Remove duplicate handling of clocks

On 12 May 2016 at 05:48, Stephen Boyd wrote: > On 05/11, Pramod Gurav wrote: >> msm_serial driver provides a .pm callback to the serial core to enable >> and disable clock resource in suspend/resume path. This function is >> also called before msm_startup. msm_startup also

Re: [PATCH] tty: serial: msm: Remove duplicate handling of clocks

On 12 May 2016 at 05:48, Stephen Boyd wrote: > On 05/11, Pramod Gurav wrote: >> msm_serial driver provides a .pm callback to the serial core to enable >> and disable clock resource in suspend/resume path. This function is >> also called before msm_startup. msm_startup also enables the clocks

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> On Wed, May 11 2016, Felipe Balbi wrote: > > Also, returning -EOVERFLOW is not exactly correct here, because you'd > > violate POSIX specification of read(), right ? > > Maybe we could piggyback on: > >EINVAL fd was created via a call to timerfd_create(2) and the > wrong

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> On Wed, May 11 2016, Felipe Balbi wrote: > > Also, returning -EOVERFLOW is not exactly correct here, because you'd > > violate POSIX specification of read(), right ? > > Maybe we could piggyback on: > >EINVAL fd was created via a call to timerfd_create(2) and the > wrong

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> Hi, > > changbin...@intel.com writes: > > From: "Du, Changbin" > > > > Since the buffer size for req is rounded up to maxpacketsize, > > then we may end up with more data then user space has space > > for. > > only for OUT direction with the controller you're using ;-)

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> Hi, > > changbin...@intel.com writes: > > From: "Du, Changbin" > > > > Since the buffer size for req is rounded up to maxpacketsize, > > then we may end up with more data then user space has space > > for. > > only for OUT direction with the controller you're using ;-) For sure. > > > If it

linux-next: manual merge of the gpio tree with the mips tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: arch/mips/Kconfig between commit: cec47c182286 ("MIPS: Loongson: Add Loongson-3A R2 basic support") from the mips tree and commit: d30a2b47d4c2 ("MIPS: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") from the

linux-next: manual merge of the gpio tree with the mips tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: arch/mips/Kconfig between commit: cec47c182286 ("MIPS: Loongson: Add Loongson-3A R2 basic support") from the mips tree and commit: d30a2b47d4c2 ("MIPS: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") from the

linux-next: build failure after merge of the pinctrl tree

_EXT' DRV_PG_EXT(pg_name, r, 2, 3, 4, 12, 20, 28, 2, 30, 2) ^ drivers/pinctrl/tegra/pinctrl-tegra20.c:2178:2: note: in expansion of macro 'DRV_PG' DRV_PG(ao1,0x868), ^ and many more. I cannot figure out what caused it, but using the pinctrl tree from next-20160511 makes it build a

linux-next: build failure after merge of the pinctrl tree

_EXT' DRV_PG_EXT(pg_name, r, 2, 3, 4, 12, 20, 28, 2, 30, 2) ^ drivers/pinctrl/tegra/pinctrl-tegra20.c:2178:2: note: in expansion of macro 'DRV_PG' DRV_PG(ao1,0x868), ^ and many more. I cannot figure out what caused it, but using the pinctrl tree from next-20160511 makes it build a

RE: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi, > From: Alan Stern > Sent: Wednesday, May 11, 2016 11:47 PM > > On Wed, 11 May 2016, Roger Quadros wrote: > > > > What I mean is if you have 2 EHCI controllers with 2 companion > > > controllers, don't you need to know which companion goes with which EHCI > > > controller? Just like you do

RE: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi, > From: Alan Stern > Sent: Wednesday, May 11, 2016 11:47 PM > > On Wed, 11 May 2016, Roger Quadros wrote: > > > > What I mean is if you have 2 EHCI controllers with 2 companion > > > controllers, don't you need to know which companion goes with which EHCI > > > controller? Just like you do

Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi, On 12/05/2016 at 09:05:34 +0800, Wenyou Yang wrote : > In order to get lower consumption, as a workaround, suspend > the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt > Configuration Register while OHCI USB suspending. > Why is that a workaround? > This suspend operation

Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

Hi, On 12/05/2016 at 09:05:34 +0800, Wenyou Yang wrote : > In order to get lower consumption, as a workaround, suspend > the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt > Configuration Register while OHCI USB suspending. > Why is that a workaround? > This suspend operation

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Hi, Arnd On 2016/5/11 22:50, Arnd Bergmann wrote: On Wednesday 11 May 2016 19:16:44 Zhangjian wrote: Hi, On 2016/5/11 18:12, Zhangjian (Bamvor) wrote: Hi, Arnd On 2016/5/11 16:09, Arnd Bergmann wrote: > On Wednesday 11 May 2016 10:04:16 Zhangjian wrote: >>> I don't remember. It's

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Hi, Arnd On 2016/5/11 22:50, Arnd Bergmann wrote: On Wednesday 11 May 2016 19:16:44 Zhangjian wrote: Hi, On 2016/5/11 18:12, Zhangjian (Bamvor) wrote: Hi, Arnd On 2016/5/11 16:09, Arnd Bergmann wrote: > On Wednesday 11 May 2016 10:04:16 Zhangjian wrote: >>> I don't remember. It's

Re: [linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote: > On 05/10, Priit Laes wrote: > > > > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote: > > > > > > On 05/09, Stephen Boyd wrote: > > > > > > > > > > > > > > > > Ok I applied this one to clk-next. > > > > > > > And I squashed this

Re: [linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote: > On 05/10, Priit Laes wrote: > > > > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote: > > > > > > On 05/09, Stephen Boyd wrote: > > > > > > > > > > > > > > > > Ok I applied this one to clk-next. > > > > > > > And I squashed this

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

On 2016/05/11 at 14:49, Peter Zijlstra wrote: > On Tue, May 10, 2016 at 11:19:44AM -0700, bseg...@google.com wrote: >> Xunlei Pang writes: >> >>> Two minor fixes for cfs_rq_clock_task(). >>> 1) If cfs_rq is currently being throttled, we need to subtract the cfs >>>throttled

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

On 2016/05/11 at 14:49, Peter Zijlstra wrote: > On Tue, May 10, 2016 at 11:19:44AM -0700, bseg...@google.com wrote: >> Xunlei Pang writes: >> >>> Two minor fixes for cfs_rq_clock_task(). >>> 1) If cfs_rq is currently being throttled, we need to subtract the cfs >>>throttled clock time. >>>

Re: [PATCH v2] mmc: dw_mmc: rockchip: Set the drive phase properly

On 2016/5/12 5:40, Douglas Anderson wrote: Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit

Re: [PATCH v2] mmc: dw_mmc: rockchip: Set the drive phase properly

On 2016/5/12 5:40, Douglas Anderson wrote: Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit

Re: [PATCH v2 0/3] input: rmi4: Regulator supply support

On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote: > Hi Bjorn, > > On 05/10/2016 08:49 AM, Bjorn Andersson wrote: [..] > >So either we duplicate the regulator support in spi/i2c or we make them > >optional in the core driver. Sounds like you prefer the prior, i.e. v1 > >of my patch. > > Yes,

Re: [PATCH v2 0/3] input: rmi4: Regulator supply support

On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote: > Hi Bjorn, > > On 05/10/2016 08:49 AM, Bjorn Andersson wrote: [..] > >So either we duplicate the regulator support in spi/i2c or we make them > >optional in the core driver. Sounds like you prefer the prior, i.e. v1 > >of my patch. > > Yes,

Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

在 2016/5/12 5:42, Doug Anderson 写道: Shawn, On Wed, May 11, 2016 at 1:25 AM, Shawn Lin wrote: On 2016/5/11 11:50, Doug Anderson wrote: Hi, On Tue, May 10, 2016 at 7:50 PM, Shawn Lin wrote: maybe. But I think 180(downside) is the better.

Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

在 2016/5/12 5:42, Doug Anderson 写道: Shawn, On Wed, May 11, 2016 at 1:25 AM, Shawn Lin wrote: On 2016/5/11 11:50, Doug Anderson wrote: Hi, On Tue, May 10, 2016 at 7:50 PM, Shawn Lin wrote: maybe. But I think 180(downside) is the better. NAK my previous comments here. Downside is

Re: [PATCH 3/6] mm/page_owner: copy last_migrate_reason in copy_page_owner()

On Tue, May 10, 2016 at 05:13:12PM +0200, Vlastimil Babka wrote: > On 05/03/2016 07:23 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Currently, copy_page_owner() doesn't copy all the owner information. > >It skips last_migrate_reason because copy_page_owner() is

Re: [PATCH 3/6] mm/page_owner: copy last_migrate_reason in copy_page_owner()

On Tue, May 10, 2016 at 05:13:12PM +0200, Vlastimil Babka wrote: > On 05/03/2016 07:23 AM, js1...@gmail.com wrote: > >From: Joonsoo Kim > > > >Currently, copy_page_owner() doesn't copy all the owner information. > >It skips last_migrate_reason because copy_page_owner() is used for > >migration

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote: > On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote: > > Hi, > > > > On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > > > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote: > On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote: > > Hi, > > > > On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > > > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng

linux-next: manual merge of the kvm tree with the tip tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: drivers/irqchip/irq-gic.c between commits: dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails") f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters") d6490461a102 ("irqchip/gic: Add

linux-next: manual merge of the kvm tree with the tip tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: drivers/irqchip/irq-gic.c between commits: dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails") f673b9b5cb54 ("irqchip/gic: Store GIC configuration parameters") d6490461a102 ("irqchip/gic: Add

Re: [PATCH 1/6] mm/compaction: split freepages without holding the zone lock

On Tue, May 10, 2016 at 04:56:45PM +0200, Vlastimil Babka wrote: > On 05/03/2016 07:22 AM, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > We don't need to split freepages with holding the zone lock. It will cause > > more contention on zone lock so not desirable. >

Re: [PATCH 1/6] mm/compaction: split freepages without holding the zone lock

On Tue, May 10, 2016 at 04:56:45PM +0200, Vlastimil Babka wrote: > On 05/03/2016 07:22 AM, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > We don't need to split freepages with holding the zone lock. It will cause > > more contention on zone lock so not desirable. > > Fair enough, I just

RE: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

Hi, > -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Abhishek Sahu > Sent: Wednesday, May 11, 2016 11:04 PM > To: Sricharan > Cc: arch...@codeaurora.org; w...@the-dreams.de; linux-arm- >

RE: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

Hi, > -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Abhishek Sahu > Sent: Wednesday, May 11, 2016 11:04 PM > To: Sricharan > Cc: arch...@codeaurora.org; w...@the-dreams.de; linux-arm- > m...@vger.kernel.org;

Re: [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support

on 2016/5/11 23:33, James Morse wrote: > Hi David, > > On 27/04/16 19:52, David Long wrote: >> From: "David A. Long" >> >> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, >> first seen in October 2013. This version attempts to address concerns

Re: [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support

on 2016/5/11 23:33, James Morse wrote: > Hi David, > > On 27/04/16 19:52, David Long wrote: >> From: "David A. Long" >> >> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, >> first seen in October 2013. This version attempts to address concerns raised >> by >>

Re: [PATCH 0.14] oom detection rework v6

On Tue, May 10, 2016 at 11:43:48AM +0200, Michal Hocko wrote: > On Tue 10-05-16 15:41:04, Joonsoo Kim wrote: > > 2016-05-05 3:16 GMT+09:00 Michal Hocko : > > > On Wed 04-05-16 23:32:31, Joonsoo Kim wrote: > > >> 2016-05-04 17:47 GMT+09:00 Michal Hocko : >

Re: [PATCH 0.14] oom detection rework v6

On Tue, May 10, 2016 at 11:43:48AM +0200, Michal Hocko wrote: > On Tue 10-05-16 15:41:04, Joonsoo Kim wrote: > > 2016-05-05 3:16 GMT+09:00 Michal Hocko : > > > On Wed 04-05-16 23:32:31, Joonsoo Kim wrote: > > >> 2016-05-04 17:47 GMT+09:00 Michal Hocko : > [...] > > >> > progress. What is the usual

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On 2016/5/12 7:24, Matt Fleming wrote: > On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: >>> > > >>> > > Also, why do you need to setup efi.runtime_version here? Isn't that >>> > > done inside uefi_init()? >>> > > >> > I don't see any codes which setup efi.runtime_version in uefi_init(). >

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On 2016/5/12 7:24, Matt Fleming wrote: > On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: >>> > > >>> > > Also, why do you need to setup efi.runtime_version here? Isn't that >>> > > done inside uefi_init()? >>> > > >> > I don't see any codes which setup efi.runtime_version in uefi_init(). >

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Thu, 12 May 2016 01:19:44 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, May 11, 2016 11:54 PM > > > > On Wed, 11 May 2016 06:29:06 + > > "Tian, Kevin" wrote: > > > > > > From:

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Thu, 12 May 2016 01:19:44 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Wednesday, May 11, 2016 11:54 PM > > > > On Wed, 11 May 2016 06:29:06 + > > "Tian, Kevin" wrote: > > > > > > From: Alex Williamson

Re: [PATCH] x86_64: Disabling read-implies-exec when the stack is executable

On Wed, May 11, 2016 at 3:40 PM, Andi Kleen wrote: >> However, I would tend to agree: RIE should only be needed on 32-bit >> since 64-bit started its life knowing about no-exec permissions. > > NX was not in the original AMD K8 chips. Was only added some time later. So we

Re: [PATCH] x86_64: Disabling read-implies-exec when the stack is executable

On Wed, May 11, 2016 at 3:40 PM, Andi Kleen wrote: >> However, I would tend to agree: RIE should only be needed on 32-bit >> since 64-bit started its life knowing about no-exec permissions. > > NX was not in the original AMD K8 chips. Was only added some time later. So we should retain this

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote: > Hi, > > On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun > > > wrote: > > > > > > > the

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote: > Hi, > > On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun > > > wrote: > > > > > > > the default mode of GPIO16 pin is

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Wed, 2016-05-11 at 20:24 +0200, Peter Zijlstra wrote: > On Wed, May 11, 2016 at 02:33:45PM +0200, Peter Zijlstra wrote: > > > > Hmm, PPC folks; what does your topology look like? > > > > Currently your sched_domain_topology, as per arch/powerpc/kernel/smp.c > > seems to suggest your cores do

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Wed, 2016-05-11 at 20:24 +0200, Peter Zijlstra wrote: > On Wed, May 11, 2016 at 02:33:45PM +0200, Peter Zijlstra wrote: > > > > Hmm, PPC folks; what does your topology look like? > > > > Currently your sched_domain_topology, as per arch/powerpc/kernel/smp.c > > seems to suggest your cores do

Re: [PATCH perf/core v7 02/21] perf buildid: Fix to set correct dso name for kallsyms

On Wed, 11 May 2016 12:45:00 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:51:37PM +0900, Masami Hiramatsu escreveu: > > Fix to set correct dso name ("[kernel.kallsyms]") for > > kallsyms, as for vdso does. > > Can you rewrite the above comment and also

Re: [PATCH perf/core v7 02/21] perf buildid: Fix to set correct dso name for kallsyms

On Wed, 11 May 2016 12:45:00 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:51:37PM +0900, Masami Hiramatsu escreveu: > > Fix to set correct dso name ("[kernel.kallsyms]") for > > kallsyms, as for vdso does. > > Can you rewrite the above comment and also break this down in

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/irqchip/irq-gic.c between commit: 25fc11aead38 ("irqchip/gic: Restore CPU interface checking") from the arm64 tree and commit: dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")

linux-next: manual merge of the tip tree with the arm64 tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/irqchip/irq-gic.c between commit: 25fc11aead38 ("irqchip/gic: Restore CPU interface checking") from the arm64 tree and commit: dc9722cc57eb ("irqchip/gic: Return an error if GIC initialisation fails")

linux-next: manual merge of the tip tree with the arc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/irqchip/Kconfig drivers/irqchip/Makefile between commit: 44df427c894a ("irqchip: add nps Internal and external irqchips") from the arc tree and commit: b8f3ebe630a4 ("irqchip: Add Layerscape SCFG MSI

linux-next: manual merge of the tip tree with the arc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: drivers/irqchip/Kconfig drivers/irqchip/Makefile between commit: 44df427c894a ("irqchip: add nps Internal and external irqchips") from the arc tree and commit: b8f3ebe630a4 ("irqchip: Add Layerscape SCFG MSI

[PATCH v2] usb: ehci-platform: add reset controller number in struct ehci_platform_priv

Some ehci compatible controllers have more than one reset signal lines, e.g., Synopsys DWC USB2.0 Host-AHB Controller has two resets hreset_i_n and phy_rst_i_n. Two more resets are added in this patch in order for this kind of controller to use this driver directly. Signed-off-by: Jiancheng Xue

[PATCH v2] usb: ehci-platform: add reset controller number in struct ehci_platform_priv

Some ehci compatible controllers have more than one reset signal lines, e.g., Synopsys DWC USB2.0 Host-AHB Controller has two resets hreset_i_n and phy_rst_i_n. Two more resets are added in this patch in order for this kind of controller to use this driver directly. Signed-off-by: Jiancheng Xue

Re: [PATCH perf/core v7 07/21] perf symbol: Cleanup the code flow of dso__find_kallsyms

On Wed, 11 May 2016 12:55:50 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:52:27PM +0900, Masami Hiramatsu escreveu: > > Cleanup the code flow of dso__find_kallsyms() to remove > > redundant checking code and add some comment for readability. > > > >

Re: [PATCH perf/core v7 07/21] perf symbol: Cleanup the code flow of dso__find_kallsyms

On Wed, 11 May 2016 12:55:50 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:52:27PM +0900, Masami Hiramatsu escreveu: > > Cleanup the code flow of dso__find_kallsyms() to remove > > redundant checking code and add some comment for readability. > > > > Signed-off-by: Masami

Re: [PATCH perf/core v7 01/21] tools/perf: Fix lsdir to set errno correctly

Hi Arnaldo, On Wed, 11 May 2016 10:59:39 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:51:27PM +0900, Masami Hiramatsu escreveu: > > Fix lsdir() to set correct positive error number (ENOMEM). > > Since "errno" must have a positive error number instead of >

Re: [PATCH perf/core v7 01/21] tools/perf: Fix lsdir to set errno correctly

Hi Arnaldo, On Wed, 11 May 2016 10:59:39 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, May 11, 2016 at 10:51:27PM +0900, Masami Hiramatsu escreveu: > > Fix lsdir() to set correct positive error number (ENOMEM). > > Since "errno" must have a positive error number instead of > > negative

Re: [PATCH 3/3] clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent

Stephen Boyd writes: > On 05/09, Eric Anholt wrote: >> If the firmware had set up a clock to source from PLLC, go along with >> it. But if we're looking for a new parent, we don't want to switch it >> to PLLC because the firmware will force PLLC (and thus the AXI bus >>

Re: [PATCH 3/3] clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent

Stephen Boyd writes: > On 05/09, Eric Anholt wrote: >> If the firmware had set up a clock to source from PLLC, go along with >> it. But if we're looking for a new parent, we don't want to switch it >> to PLLC because the firmware will force PLLC (and thus the AXI bus >> clock) to different

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

Hi, On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun > > wrote: > > > > > the default mode of GPIO16 pin is gpio, when set EINT16 to > > >

Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for DMA Mode

On 05/10, Abhishek Sahu wrote: > From: Charanya Was it intentional to only have one name here? > > The Data loss was happening with current QCOM MSM serial driver during > large file transfer due to simultaneous enabling of both UART and > DMA interrupt. When UART

Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode

Hi, On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote: > On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote: > > On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun > > wrote: > > > > > the default mode of GPIO16 pin is gpio, when set EINT16 to > > > IRQ_TYPE_LEVEL_HIGH, no interrupt is

Re: [PATCH] tty: serial: msm: Disable restoring Rx interrupts for DMA Mode

On 05/10, Abhishek Sahu wrote: > From: Charanya Was it intentional to only have one name here? > > The Data loss was happening with current QCOM MSM serial driver during > large file transfer due to simultaneous enabling of both UART and > DMA interrupt. When UART operates in DMA mode, RXLEV

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 11, 2016 11:54 PM > > On Wed, 11 May 2016 06:29:06 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Thursday, May 05, 2016 11:05 PM

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, May 11, 2016 11:54 PM > > On Wed, 11 May 2016 06:29:06 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Thursday, May 05, 2016 11:05 PM > > > > > > On Thu, 5

Re: [PATCH v8 6/8] dt-bindings: i2c: rk3x: add support for rk3399

Hi Doug, 在 2016/5/12 0:35, Doug Anderson 写道: Hi, On Tue, May 10, 2016 at 12:30 PM, David Wu wrote: The bus clock and function clock are separated at rk3399, and others use one clock as the bus clock and function clock. Signed-off-by: David Wu

Re: [PATCH v8 6/8] dt-bindings: i2c: rk3x: add support for rk3399

Hi Doug, 在 2016/5/12 0:35, Doug Anderson 写道: Hi, On Tue, May 10, 2016 at 12:30 PM, David Wu wrote: The bus clock and function clock are separated at rk3399, and others use one clock as the bus clock and function clock. Signed-off-by: David Wu Reviewed-by: Douglas Anderson --- Change in

  1   2   3   4   5   6   7   8   9   10   >