Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

On Wed, Oct 19, 2016 at 4:15 AM, Ayaka wrote: > > > 從我的 iPad 傳送 > >> Krzysztof Kozlowski 於 2016年10月19日 上午1:37 寫道： >> >>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote: >>> The TOPEET itop exynos 4412 have three versions base board. The >>> Elite

Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

On Wed, Oct 19, 2016 at 4:15 AM, Ayaka wrote: > > > 從我的 iPad 傳送 > >> Krzysztof Kozlowski 於 2016年10月19日 上午1:37 寫道： >> >>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote: >>> The TOPEET itop exynos 4412 have three versions base board. The >>> Elite version is the cheap one without too

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

On 18/10/16 18:40, Boris Ostrovsky wrote: > On 10/18/2016 12:08 PM, Juergen Gross wrote: >> On 14/10/16 22:02, Boris Ostrovsky wrote: >>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote: On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote: > On 10/14/2016 03:19 PM, Konrad

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

On 18/10/16 18:40, Boris Ostrovsky wrote: > On 10/18/2016 12:08 PM, Juergen Gross wrote: >> On 14/10/16 22:02, Boris Ostrovsky wrote: >>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote: On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote: > On 10/14/2016 03:19 PM, Konrad

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

On Mon, Oct 17, 2016 at 9:01 PM, Johan Hovold wrote: > On Sun, Oct 16, 2016 at 03:29:14PM +0530, Pankaj Bharadiya wrote: >> gb_audio_manager_module_descriptor's cport field is actually used to >> manage and pass interface id to user space. >> >> Thus rename

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

On Mon, Oct 17, 2016 at 9:01 PM, Johan Hovold wrote: > On Sun, Oct 16, 2016 at 03:29:14PM +0530, Pankaj Bharadiya wrote: >> gb_audio_manager_module_descriptor's cport field is actually used to >> manage and pass interface id to user space. >> >> Thus rename gb_audio_manager_module_descriptor's

Intel H81 Chipset PCIe configuration question

A while back I posted about a motherboard network controller that disappeared when the firmware on a PCIe card was upgraded which converted the card from a 32-bit BAR to a 64-bit BAR. That seems to be a BIOS bug rather than a kernel issue. But, I would really like to be able to upgrade the systems

Intel H81 Chipset PCIe configuration question

A while back I posted about a motherboard network controller that disappeared when the firmware on a PCIe card was upgraded which converted the card from a 32-bit BAR to a 64-bit BAR. That seems to be a BIOS bug rather than a kernel issue. But, I would really like to be able to upgrade the systems

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

Andrew Morton writes: > On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" > wrote: > >> We cannot use the pte value used in set_pte_at for pte_same comparison, >> because archs like ppc64, filter/add new pte flag in set_pte_at.

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

Andrew Morton writes: > On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" > wrote: > >> We cannot use the pte value used in set_pte_at for pte_same comparison, >> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead >> fetch the pte value inside hugetlb_cow. We are

Re: [lkp] [tcp] 3613b3dbd1: netpipe.bigger_5M_Mbps.avg -5.5% regression

On Wed, Oct 19, 2016 at 3:54 AM, kernel test robot wrote: > > FYI, we noticed a -5.5% regression of netpipe.bigger_5M_Mbps.avg due to > commit: > > commit 3613b3dbd1ade9a6a626dae1f608c57638eb5e8a ("tcp: prepare skbs for > better sack shifting") >

Re: [lkp] [tcp] 3613b3dbd1: netpipe.bigger_5M_Mbps.avg -5.5% regression

On Wed, Oct 19, 2016 at 3:54 AM, kernel test robot wrote: > > FYI, we noticed a -5.5% regression of netpipe.bigger_5M_Mbps.avg due to > commit: > > commit 3613b3dbd1ade9a6a626dae1f608c57638eb5e8a ("tcp: prepare skbs for > better sack shifting") >

Re: [PATCH 4/4] i2c: digicolor: Fix module autoload

Hi Javier Martinez Canillas, On Tue, Oct 18, 2016 at 06:01:48PM -0300, Javier Martinez Canillas wrote: > If the driver is built as a module, autoload won't work because the module > alias information is not filled. So user-space can't match the registered > device with the corresponding module. >

Re: [PATCH 4/4] i2c: digicolor: Fix module autoload

Hi Javier Martinez Canillas, On Tue, Oct 18, 2016 at 06:01:48PM -0300, Javier Martinez Canillas wrote: > If the driver is built as a module, autoload won't work because the module > alias information is not filled. So user-space can't match the registered > device with the corresponding module. >

[PATCH 2/5] selftests: ftrace: Fix test cases to enable tracing

Fix some test cases to enable tracing before starting trace test. This can avoid false-positive failure when previous testcase fails while disabling tracing. Signed-off-by: Masami Hiramatsu --- .../selftests/ftrace/test.d/event/event-enable.tc |1 +

[PATCH 5/5] selftests: ftrace: Add a testcase for types of kprobe event

Add a testcase for types of kprobe event. This checks kprobe event can accept and correctly expressed the arguments typed as s32, u32, x32 and bitfield. Here is the test result. - # ./ftracetest test.d/kprobe/kprobe_args_type.tc === Ftrace unit tests === [1] Kprobes event arguments

[PATCH 4/5] selftests: ftrace: Add a testcase for function filter glob match

Add function filter glob matching test case. This checks whether the kernel supports glob matching (front match, end match, middle match, side match, character class and '?'). Here is the test result. - ./ftracetest test.d/ftrace/func-filter-glob.tc === Ftrace unit tests === [1]

[PATCH 2/5] selftests: ftrace: Fix test cases to enable tracing

Fix some test cases to enable tracing before starting trace test. This can avoid false-positive failure when previous testcase fails while disabling tracing. Signed-off-by: Masami Hiramatsu --- .../selftests/ftrace/test.d/event/event-enable.tc |1 +

[PATCH 5/5] selftests: ftrace: Add a testcase for types of kprobe event

Add a testcase for types of kprobe event. This checks kprobe event can accept and correctly expressed the arguments typed as s32, u32, x32 and bitfield. Here is the test result. - # ./ftracetest test.d/kprobe/kprobe_args_type.tc === Ftrace unit tests === [1] Kprobes event arguments

[PATCH 4/5] selftests: ftrace: Add a testcase for function filter glob match

Add function filter glob matching test case. This checks whether the kernel supports glob matching (front match, end match, middle match, side match, character class and '?'). Here is the test result. - ./ftracetest test.d/ftrace/func-filter-glob.tc === Ftrace unit tests === [1]

[PATCH 3/5] selftests: ftrace: Introduce TMPDIR for temporary files

Introduce TMPDIR variable which is removed after each test is done, so that the test script can put their temporary files in that. Signed-off-by: Masami Hiramatsu --- tools/testing/selftests/ftrace/ftracetest |2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/5] ftrace: Support full glob matching

Use glob_match() to support flexible glob wildcards (*,?) and character classes ([) for ftrace. Since the full glob matching is slower than the current partial matching routines(*pat, pat*, *pat*), this leaves those routines and just add MATCH_GLOB for complex glob expression. e.g.

[PATCH 3/5] selftests: ftrace: Introduce TMPDIR for temporary files

Introduce TMPDIR variable which is removed after each test is done, so that the test script can put their temporary files in that. Signed-off-by: Masami Hiramatsu --- tools/testing/selftests/ftrace/ftracetest |2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/5] ftrace: Support full glob matching

Use glob_match() to support flexible glob wildcards (*,?) and character classes ([) for ftrace. Since the full glob matching is slower than the current partial matching routines(*pat, pat*, *pat*), this leaves those routines and just add MATCH_GLOB for complex glob expression. e.g.

[PATCH 0/5] ftrace: selftests: Add full glob matching and update ftracetest

Hi, Here is a series of patches to add full glob matching support in ftrace and update ftracetest to test the glob matching and hexadecimal types. The first patch is same one as I sent before (https://lkml.org/lkml/2016/10/5/149) I've added patches for updating ftracetest to test this feature

[PATCH 0/5] ftrace: selftests: Add full glob matching and update ftracetest

Hi, Here is a series of patches to add full glob matching support in ftrace and update ftracetest to test the glob matching and hexadecimal types. The first patch is same one as I sent before (https://lkml.org/lkml/2016/10/5/149) I've added patches for updating ftracetest to test this feature

Re: tg3 BUG: spinlock lockup suspected

On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos wrote: >> > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will >> > test further. >> >> It gets stranger and stranger - my old 4.7 image worked fine, freshly >> compiled 4.7 exhibits the same problem. >> >>

Re: tg3 BUG: spinlock lockup suspected

On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos wrote: >> > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will >> > test further. >> >> It gets stranger and stranger - my old 4.7 image worked fine, freshly >> compiled 4.7 exhibits the same problem. >> >> Toolchain has not

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

Hi, as discussed before: The root cause for the performance regression is the smp_mb() that was added into the fast path. I see two options: 1) switch to full spin_lock()/spin_unlock() for the rare codepath, then the fast path doesn't need the smp_mb() anymore. 2) confirm that no arch needs

[PATCH 2/2] ipc/sem: Add hysteresis.

sysv sem has two lock modes: One with per-semaphore locks, one lock mode with a single global lock for the whole array. When switching from the per-semaphore locks to the global lock, all per-semaphore locks must be scanned for ongoing operations. The patch adds a hysteresis for switching from

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

Hi, as discussed before: The root cause for the performance regression is the smp_mb() that was added into the fast path. I see two options: 1) switch to full spin_lock()/spin_unlock() for the rare codepath, then the fast path doesn't need the smp_mb() anymore. 2) confirm that no arch needs

[PATCH 2/2] ipc/sem: Add hysteresis.

sysv sem has two lock modes: One with per-semaphore locks, one lock mode with a single global lock for the whole array. When switching from the per-semaphore locks to the global lock, all per-semaphore locks must be scanned for ongoing operations. The patch adds a hysteresis for switching from

[PATCH 1/2] ipc/sem.c: Avoid using spin_unlock_wait()

a) The ACQUIRE in spin_lock() applies to the read, not to the store, at least for powerpc. This forces to add a smp_mb() into the fast path. b) The memory barrier provided by spin_unlock_wait() is right now arch dependent. Therefore: Use spin_lock()/spin_unlock() instead of spin_unlock_wait().

[PATCH 1/2] ipc/sem.c: Avoid using spin_unlock_wait()

a) The ACQUIRE in spin_lock() applies to the read, not to the store, at least for powerpc. This forces to add a smp_mb() into the fast path. b) The memory barrier provided by spin_unlock_wait() is right now arch dependent. Therefore: Use spin_lock()/spin_unlock() instead of spin_unlock_wait().

[PATCH] i2c: uniphier[-f]: fix bool logic calculation

This code is working, but it should not depend on how "bool" is typedef'ed, or the bit position of I2C_M_RD. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier-f.c | 2 +- drivers/i2c/busses/i2c-uniphier.c | 2 +- 2 files changed, 2

[PATCH] i2c: uniphier[-f]: fix bool logic calculation

This code is working, but it should not depend on how "bool" is typedef'ed, or the bit position of I2C_M_RD. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier-f.c | 2 +- drivers/i2c/busses/i2c-uniphier.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls

On (10/19/16 00:40), Sergey Senozhatsky wrote: [..] > Deadlock scenarios that printk_safe can handle: > > a) printk recursion from logbuf_lock spin_lock section in printk() > printk() > raw_spin_lock(_lock); > WARN_ON(1); > raw_spin_unlock(_lock); > > b) printk from sem->lock

Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls

On (10/19/16 00:40), Sergey Senozhatsky wrote: [..] > Deadlock scenarios that printk_safe can handle: > > a) printk recursion from logbuf_lock spin_lock section in printk() > printk() > raw_spin_lock(_lock); > WARN_ON(1); > raw_spin_unlock(_lock); > > b) printk from sem->lock

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

在 2016/10/19 10:45, Rob Herring 写道: > On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue > wrote: >> >> >> 在 2016/10/18 23:58, Rob Herring 写道: >>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

在 2016/10/19 10:45, Rob Herring 写道: > On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue > wrote: >> >> >> 在 2016/10/18 23:58, Rob Herring 写道: >>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset Generator) module generates

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

[ adding Ashok and David for potential iommu comments ] On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates wrote: > This patch follows from an RFC we did earlier this year [1]. This > patchset applies cleanly to v4.9-rc1. > > Updates since RFC > - > Rebased. >

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

[ adding Ashok and David for potential iommu comments ] On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates wrote: > This patch follows from an RFC we did earlier this year [1]. This > patchset applies cleanly to v4.9-rc1. > > Updates since RFC > - > Rebased. > Included the iopmem

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote: > hw_random carefully avoids using a stack buffer except in > add_early_randomness(). This causes a crash in virtio_rng if > CONFIG_VMAP_STACK=y. > > Reported-by: Matt Mullins > Tested-by: Matt Mullins

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote: > hw_random carefully avoids using a stack buffer except in > add_early_randomness(). This causes a crash in virtio_rng if > CONFIG_VMAP_STACK=y. > > Reported-by: Matt Mullins > Tested-by: Matt Mullins > Fixes: d3cc7996473a

[REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees

Adrei Vagin pointed out that time to executue propagate_umount can go non-linear (and take a ludicrious amount of time) when the mount propogation trees of the mounts to be unmunted by a lazy unmount overlap. While investigating the horrible performance I realized that in the case overlapping

[REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees

Adrei Vagin pointed out that time to executue propagate_umount can go non-linear (and take a ludicrious amount of time) when the mount propogation trees of the mounts to be unmunted by a lazy unmount overlap. While investigating the horrible performance I realized that in the case overlapping

[PATCH] tools: hv: clean up code, remove unnecessary header files and link flags

Remove unnecessary header files and netlink related code as the daemons do not use netlink to communicate with the kernel now. Fix a compile warning in snprintf. Pthread is also not needed. Signed-off-by: Weibing Zhang --- tools/hv/Makefile | 3 +--

[PATCH] tools: hv: clean up code, remove unnecessary header files and link flags

Remove unnecessary header files and netlink related code as the daemons do not use netlink to communicate with the kernel now. Fix a compile warning in snprintf. Pthread is also not needed. Signed-off-by: Weibing Zhang --- tools/hv/Makefile | 3 +-- tools/hv/hv_fcopy_daemon.c | 7

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

On 2016-10-18, Paul Kocialkowski wrote: > Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit : >> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski: >> > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit : >> > > >> > > This essentially mimics what was

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

On 2016-10-18, Paul Kocialkowski wrote: > Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit : >> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski: >> > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit : >> > > >> > > This essentially mimics what was

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

Hi Dan, On Fri, Oct 14, 2016 at 10:33:28AM +0300, Dan Carpenter wrote: > We checked that "pdata->chg_params" is non-NULL earlier in this function > so when we add "i" to it, it's still non-NULL. > > Signed-off-by: Dan Carpenter > > diff --git

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

Hi Dan, On Fri, Oct 14, 2016 at 10:33:28AM +0300, Dan Carpenter wrote: > We checked that "pdata->chg_params" is non-NULL earlier in this function > so when we add "i" to it, it's still non-NULL. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/power/supply/lp8788-charger.c >

Re: [PATCH 0/2] power: supply: Fix module autoload for some platform drivers

Hi Javier, On Mon, Oct 17, 2016 at 04:13:34PM -0300, Javier Martinez Canillas wrote: > Hello Sebastian, > > I noticed that module autoload won't be working for some of the power > supply platform drivers. This patch series contains fixes for these. > > Best regards, > Javier > > > Javier

Re: [PATCH 0/2] power: supply: Fix module autoload for some platform drivers

Hi Javier, On Mon, Oct 17, 2016 at 04:13:34PM -0300, Javier Martinez Canillas wrote: > Hello Sebastian, > > I noticed that module autoload won't be working for some of the power > supply platform drivers. This patch series contains fixes for these. > > Best regards, > Javier > > > Javier

Re: [PATCH 0/4] power: reset: Fix module autoload for some platform drivers

Hi Javier, On Mon, Oct 17, 2016 at 03:36:11PM -0300, Javier Martinez Canillas wrote: > I noticed that module autoload won't be working in a some of the reset > platform drivers This patch series contains the fixes for these. > > Best regards, > Javier > > > Javier Martinez Canillas (4): >

Re: [PATCH 0/4] power: reset: Fix module autoload for some platform drivers

Hi Javier, On Mon, Oct 17, 2016 at 03:36:11PM -0300, Javier Martinez Canillas wrote: > I noticed that module autoload won't be working in a some of the reset > platform drivers This patch series contains the fixes for these. > > Best regards, > Javier > > > Javier Martinez Canillas (4): >

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: > > Annoyingly, all this complication with scatterlists etc is for doing > asynchronous crypto via DMA capable crypto accelerators, and the > networking code (ipsec as well as mac80211, afaik) only allow > synchronous in the first

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: > > Annoyingly, all this complication with scatterlists etc is for doing > asynchronous crypto via DMA capable crypto accelerators, and the > networking code (ipsec as well as mac80211, afaik) only allow > synchronous in the first

Re: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

On Tue, Oct 18, 2016 at 11:14:08AM -0700, Dave Jiang wrote: > On 09/15/2016 08:48 AM, Vinod Koul wrote: > > On Wed, Sep 14, 2016 at 08:40:38PM +0300, Eugeniy Paltsev wrote: > >> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for > >> scatter-gather DMA mode") changes default "dmatest"

Re: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

On Tue, Oct 18, 2016 at 11:14:08AM -0700, Dave Jiang wrote: > On 09/15/2016 08:48 AM, Vinod Koul wrote: > > On Wed, Sep 14, 2016 at 08:40:38PM +0300, Eugeniy Paltsev wrote: > >> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for > >> scatter-gather DMA mode") changes default "dmatest"

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

On Tuesday, October 18, 2016 11:43 PM Aneesh Kumar K.V wrote: > > We cannot use the pte value used in set_pte_at for pte_same comparison, > because archs like ppc64, filter/add new pte flag in set_pte_at. Instead > fetch the pte value inside hugetlb_cow. We are comparing pte value to > make sure

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

On Tuesday, October 18, 2016 11:43 PM Aneesh Kumar K.V wrote: > > We cannot use the pte value used in set_pte_at for pte_same comparison, > because archs like ppc64, filter/add new pte flag in set_pte_at. Instead > fetch the pte value inside hugetlb_cow. We are comparing pte value to > make sure

Re: [PATCH] dt-bindings: usb: atmel: fix a couple of copy-paste style typos

On Tue, Oct 18, 2016 at 01:05:18PM +0200, Peter Rosin wrote: > Signed-off-by: Peter Rosin > --- > Documentation/devicetree/bindings/usb/atmel-usb.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Acked-by: Rob Herring

Re: [PATCH] dt-bindings: usb: atmel: fix a couple of copy-paste style typos

On Tue, Oct 18, 2016 at 01:05:18PM +0200, Peter Rosin wrote: > Signed-off-by: Peter Rosin > --- > Documentation/devicetree/bindings/usb/atmel-usb.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Acked-by: Rob Herring

Re: [RFC PATCH] mtd: nand: Add OX820 NAND Support

On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote: > Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller. > This is a simple memory mapped NAND controller with single chip select and > software ECC. > > Signed-off-by: Neil Armstrong >

Re: [RFC PATCH] mtd: nand: Add OX820 NAND Support

On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote: > Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller. > This is a simple memory mapped NAND controller with single chip select and > software ECC. > > Signed-off-by: Neil Armstrong > --- >

Re: [PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

Hi, On Wed, Sep 21, 2016 at 10:17:34PM +0800, Liu Xiang wrote: > According to the datasheet, MAX17040 has six 16-bit registers. > Register reads and writes are only valid if all 16 bits are transferred. > Any write command that is terminated early is ignored. > So it's better to change register

Re: [PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

Hi, On Wed, Sep 21, 2016 at 10:17:34PM +0800, Liu Xiang wrote: > According to the datasheet, MAX17040 has six 16-bit registers. > Register reads and writes are only valid if all 16 bits are transferred. > Any write command that is terminated early is ignored. > So it's better to change register

Re: [PATCH] power: bq27xxx_battery: don't update poll_interval param if same

Hi, On Fri, Sep 30, 2016 at 09:45:30PM -0700, Matt Ranostay wrote: > To avoid canceling the delayed workqueue needlessly, and scheduling an > immediate polling. Check if the new poll_interval value is different > than the previous setting. > > Cc: Tony Lindgren > Cc: Sebastian

Re: [PATCH] power: bq27xxx_battery: don't update poll_interval param if same

Hi, On Fri, Sep 30, 2016 at 09:45:30PM -0700, Matt Ranostay wrote: > To avoid canceling the delayed workqueue needlessly, and scheduling an > immediate polling. Check if the new poll_interval value is different > than the previous setting. > > Cc: Tony Lindgren > Cc: Sebastian Reichel >

Re: [PATCH 08/15] power: improve function-level documentation

Hi Julia, On Sat, Oct 01, 2016 at 09:46:25PM +0200, Julia Lawall wrote: > In drivers/power/supply/ab8500_fg.c, fix two typos and adjust the function > name in two cases to correspond to the names of the defined functions. > > In drivers/power/supply/power_supply_core.c, change two variable names

Re: [PATCH 08/15] power: improve function-level documentation

Hi Julia, On Sat, Oct 01, 2016 at 09:46:25PM +0200, Julia Lawall wrote: > In drivers/power/supply/ab8500_fg.c, fix two typos and adjust the function > name in two cases to correspond to the names of the defined functions. > > In drivers/power/supply/power_supply_core.c, change two variable names

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

On 2016/10/18 16:39, Hanjun Guo wrote: > On 2016/10/17 22:56, Lorenzo Pieralisi wrote: >> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must >> bind to node0") removed the numa cpu<->node mapping restriction whereby >> logical cpu 0 always corresponds to numa node 0; removing

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

On 2016/10/18 16:39, Hanjun Guo wrote: > On 2016/10/17 22:56, Lorenzo Pieralisi wrote: >> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must >> bind to node0") removed the numa cpu<->node mapping restriction whereby >> logical cpu 0 always corresponds to numa node 0; removing

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue wrote: > > > 在 2016/10/18 23:58, Rob Herring 写道: >> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: >>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset >>> Generator) module generates clock and reset

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue wrote: > > > 在 2016/10/18 23:58, Rob Herring 写道: >> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: >>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset >>> Generator) module generates clock and reset signals used >>> by other module

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

二, 10月 18, 2016 at 02:52:47下午 +0200, Michal Hocko wrote: hi, > On Tue 18-10-16 15:29:50, Minchan Kim wrote: > > On Mon, Oct 17, 2016 at 10:42:45AM +0200, Michal Hocko wrote: > [...] > > > Sure, what do you think about the following? I haven't marked it for > > > stable because there was no bug

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

在 2016/10/18 23:58, Rob Herring 写道: > On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset >> Generator) module generates clock and reset signals used >> by other module blocks on SoC. >> >> Signed-off-by: Pan Wen

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

二, 10月 18, 2016 at 02:52:47下午 +0200, Michal Hocko wrote: hi, > On Tue 18-10-16 15:29:50, Minchan Kim wrote: > > On Mon, Oct 17, 2016 at 10:42:45AM +0200, Michal Hocko wrote: > [...] > > > Sure, what do you think about the following? I haven't marked it for > > > stable because there was no bug

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

在 2016/10/18 23:58, Rob Herring 写道: > On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote: >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset >> Generator) module generates clock and reset signals used >> by other module blocks on SoC. >> >> Signed-off-by: Pan Wen >> --- >>

[PATCH v18 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[PATCH v18 1/4] usb: gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

[PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

[PATCH v18 2/4] usb: gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Signed-off-by: Baolin Wang

[PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

[PATCH v18 2/4] usb: gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Signed-off-by: Baolin Wang Reviewed-by: Li

[PATCH v18 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[PATCH v18 1/4] usb: gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

Re: [PATCH 20/23] ASoC: add simple-graph-card document

On Tue, Oct 18, 2016 at 8:36 PM, Kuninori Morimoto wrote: > > Hi Rob > >> > + type = "sound"; >> >> I'm still not convinced this is necessary. This is implied either by >> the fact there is only one port or perhaps the compatible string. > > Do you

linux-next: Tree for Oct 19

Hi all, Changes since 20161018: The drm-intel tree lost its build failures. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree): 1218 1521 files changed, 58816 insertions(+), 23659 deletions

[PATCH v18 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger can implement the usb_charger_plug_by_gadget() function, usb_charger_exit() function and dev_to_uchger() function by getting 'struct usb_charger' from 'struct gadget'. Signed-off-by: Baolin Wang

Re: [PATCH 20/23] ASoC: add simple-graph-card document

On Tue, Oct 18, 2016 at 8:36 PM, Kuninori Morimoto wrote: > > Hi Rob > >> > + type = "sound"; >> >> I'm still not convinced this is necessary. This is implied either by >> the fact there is only one port or perhaps the compatible string. > > Do you mean "on this sample" ? or in

linux-next: Tree for Oct 19

Hi all, Changes since 20161018: The drm-intel tree lost its build failures. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree): 1218 1521 files changed, 58816 insertions(+), 23659 deletions

[PATCH v18 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger can implement the usb_charger_plug_by_gadget() function, usb_charger_exit() function and dev_to_uchger() function by getting 'struct usb_charger' from 'struct gadget'. Signed-off-by: Baolin Wang Reviewed-by: Li Jun

Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking

On Tue, Oct 18, 2016 at 06:28:20PM -0400, Jarod Wilson wrote: > On Tue, Oct 18, 2016 at 11:33:27AM -0400, David Miller wrote: > > From: Jarod Wilson > > Date: Mon, 17 Oct 2016 16:29:43 -0400 > > > > > On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote: > > >> From:

Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking

On Tue, Oct 18, 2016 at 06:28:20PM -0400, Jarod Wilson wrote: > On Tue, Oct 18, 2016 at 11:33:27AM -0400, David Miller wrote: > > From: Jarod Wilson > > Date: Mon, 17 Oct 2016 16:29:43 -0400 > > > > > On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote: > > >> From: Jarod Wilson > > >>

[PATCH net-next 6/6] net: use core MTU range checking in misc drivers

firewire-net: - set min/max_mtu - remove fwnet_change_mtu nes: - set max_mtu - clean up nes_netdev_change_mtu xpnet: - set min/max_mtu - remove xpnet_dev_change_mtu hippi: - set min/max_mtu - remove hippi_change_mtu batman-adv: - set max_mtu - remove batadv_interface_change_mtu -

[PATCH net-next 5/6] net: use core MTU range checking in virt drivers

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: net...@vger.kernel.org CC: virtualizat...@lists.linux-foundation.org CC: "K. Y. Srinivasan" CC: Haiyang Zhang CC: "Michael S.

[PATCH net-next 6/6] net: use core MTU range checking in misc drivers

firewire-net: - set min/max_mtu - remove fwnet_change_mtu nes: - set max_mtu - clean up nes_netdev_change_mtu xpnet: - set min/max_mtu - remove xpnet_dev_change_mtu hippi: - set min/max_mtu - remove hippi_change_mtu batman-adv: - set max_mtu - remove batadv_interface_change_mtu -

[PATCH net-next 5/6] net: use core MTU range checking in virt drivers

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: net...@vger.kernel.org CC: virtualizat...@lists.linux-foundation.org CC: "K. Y. Srinivasan" CC: Haiyang Zhang CC: "Michael S. Tsirkin" CC: Shrikrishna Khare CC: "VMware,

  1   2   3   4   5   6   7   8   9   10   >