Re: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

Hi Zhang > > Hi Linux-PM, Linux-Kernel ML > > > > I posted thermal driver patch 2month ago, but no response and nothing > > happen. > > I'm following scripts/get_maintainer.pl, but am I wrong ?? > > Who is the maintainer of these patches ?? > > > The patch is queued for 4.8-rc2. > As you can

Re: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

Hi Zhang > > Hi Linux-PM, Linux-Kernel ML > > > > I posted thermal driver patch 2month ago, but no response and nothing > > happen. > > I'm following scripts/get_maintainer.pl, but am I wrong ?? > > Who is the maintainer of these patches ?? > > > The patch is queued for 4.8-rc2. > As you can

RE: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

> -Original Message- > From: Kuninori Morimoto [mailto:kuninori.morimoto...@renesas.com] > Sent: Wednesday, August 10, 2016 10:10 AM > To: Kuninori Morimoto > Cc: Zhang, Rui ; edubez...@gmail.com; Geert > Uytterhoeven

RE: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

> -Original Message- > From: Kuninori Morimoto [mailto:kuninori.morimoto...@renesas.com] > Sent: Wednesday, August 10, 2016 10:10 AM > To: Kuninori Morimoto > Cc: Zhang, Rui ; edubez...@gmail.com; Geert > Uytterhoeven ; linux-kernel@vger.kernel.org; linux- > renesas-...@vger.kernel.org;

Re: [PATCH] mm: optimize find_zone_movable_pfns_for_nodes to avoid unnecessary loop.

On 2016/8/10 7:29, Andrew Morton wrote: > On Fri, 5 Aug 2016 22:04:07 +0800 zhongjiang wrote: > >> when required_kernelcore decrease to zero, we should exit the loop in time. >> because It will waste time to scan the remainder node. > The patch is rather ugly and it only

Re: [PATCH] mm: optimize find_zone_movable_pfns_for_nodes to avoid unnecessary loop.

On 2016/8/10 7:29, Andrew Morton wrote: > On Fri, 5 Aug 2016 22:04:07 +0800 zhongjiang wrote: > >> when required_kernelcore decrease to zero, we should exit the loop in time. >> because It will waste time to scan the remainder node. > The patch is rather ugly and it only affects __init code, so

[PATCH v4] arm64: mm: convert __dma_* routines to use start, size

__dma_* routines have been converted to use start and size instread of start and end addresses. The patch was origianlly for adding __clean_dcache_area_poc() which will be used in pmem driver to clean dcache to the PoC(Point of Coherency) in arch_wb_cache_pmem(). The functionality of

[PATCH v4] arm64: mm: convert __dma_* routines to use start, size

__dma_* routines have been converted to use start and size instread of start and end addresses. The patch was origianlly for adding __clean_dcache_area_poc() which will be used in pmem driver to clean dcache to the PoC(Point of Coherency) in arch_wb_cache_pmem(). The functionality of

Re: [PATCH] usb: core: Add runtime resume checking

Hi Greg, On 9 August 2016 at 18:26, Greg KH wrote: > On Tue, Aug 09, 2016 at 05:33:33PM +0800, Baolin Wang wrote: >> When the usb device has entered suspend state by runtime suspend method, and >> the sustem also try to enter suspend state by issuing

Re: [PATCH] usb: core: Add runtime resume checking

Hi Greg, On 9 August 2016 at 18:26, Greg KH wrote: > On Tue, Aug 09, 2016 at 05:33:33PM +0800, Baolin Wang wrote: >> When the usb device has entered suspend state by runtime suspend method, and >> the sustem also try to enter suspend state by issuing usb_dev_suspend(), it >> will issue

RE: [PATCH v3] arm64: mm: convert __dma_* routines to use start, size

Hi Robin, > -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, August 09, 2016 8:51 PM > To: 이광우(LEE KWANGWOO) MS SW; Russell King - ARM Linux; Catalin Marinas; Will > Deacon; Mark Rutland; > linux-arm-ker...@lists.infradead.org > Cc: 정우석(CHUNG WOO

RE: [PATCH v3] arm64: mm: convert __dma_* routines to use start, size

Hi Robin, > -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, August 09, 2016 8:51 PM > To: 이광우(LEE KWANGWOO) MS SW; Russell King - ARM Linux; Catalin Marinas; Will > Deacon; Mark Rutland; > linux-arm-ker...@lists.infradead.org > Cc: 정우석(CHUNG WOO

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

On 2016/8/8 17:18, Zhen Lei wrote: > Use the same tactic to cpu and numa-distance nodes. > > Signed-off-by: Zhen Lei > --- > arch/arm64/mm/numa.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > index

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

On 2016/8/8 17:18, Zhen Lei wrote: > Use the same tactic to cpu and numa-distance nodes. > > Signed-off-by: Zhen Lei > --- > arch/arm64/mm/numa.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > index c7fe3ec..2601660 100644 > ---

Re: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

Hi Linux-PM, Linux-Kernel ML I posted thermal driver patch 2month ago, but no response and nothing happen. I'm following scripts/get_maintainer.pl, but am I wrong ?? Who is the maintainer of these patches ?? > Hi Zhang > > ping ?? > > > These are resend patches for rcar-thermal hwmon. > > >

Re: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

Hi Linux-PM, Linux-Kernel ML I posted thermal driver patch 2month ago, but no response and nothing happen. I'm following scripts/get_maintainer.pl, but am I wrong ?? Who is the maintainer of these patches ?? > Hi Zhang > > ping ?? > > > These are resend patches for rcar-thermal hwmon. > > >

Re: [PATCH v5 00/14] fix some type infos and bugs for arm64/of numa

Hi Zhen, On 2016/8/8 17:18, Zhen Lei wrote: > v4 -> v5: > This version has no code changes, just add "Acked-by: Rob Herring > " > into patches 1, 2, 4, 6, 7, 13, 14. Because these patches rely on some acpi > numa > patches, and the latter had not been upstreamed in 4.7, but

Re: [PATCH v5 00/14] fix some type infos and bugs for arm64/of numa

Hi Zhen, On 2016/8/8 17:18, Zhen Lei wrote: > v4 -> v5: > This version has no code changes, just add "Acked-by: Rob Herring > " > into patches 1, 2, 4, 6, 7, 13, 14. Because these patches rely on some acpi > numa > patches, and the latter had not been upstreamed in 4.7, but upstreamed in >

Re: [PATCH] rcu: Fix soft lockup for rcu_nocb_kthread

On Wed, Aug 10, 2016 at 09:13:14AM +0800, Ding Tianhong wrote: > On 2016/6/16 22:19, Paul E. McKenney wrote: > > On Thu, Jun 16, 2016 at 02:09:47PM +0800, Ding Tianhong wrote: > >> On 2016/6/15 23:49, Paul E. McKenney wrote: > >>> On Wed, Jun 15, 2016 at 03:27:36PM +0800, Ding Tianhong wrote: >

Re: [PATCH] rcu: Fix soft lockup for rcu_nocb_kthread

On Wed, Aug 10, 2016 at 09:13:14AM +0800, Ding Tianhong wrote: > On 2016/6/16 22:19, Paul E. McKenney wrote: > > On Thu, Jun 16, 2016 at 02:09:47PM +0800, Ding Tianhong wrote: > >> On 2016/6/15 23:49, Paul E. McKenney wrote: > >>> On Wed, Jun 15, 2016 at 03:27:36PM +0800, Ding Tianhong wrote: >

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > > > > > > > Mark, Aurelien, > > >

Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote: > > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote: > > > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote: > > > > > > > > > > > > Mark, Aurelien, > > >

[Update][PATCH 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

From: Rafael J. Wysocki It is useful to know the reason why cpufreq_update_util() has just been called and that can be passed as flags to cpufreq_update_util() and to the ->func() callback in struct update_util_data. However, doing that in addition to passing the

[Update][PATCH 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

From: Rafael J. Wysocki It is useful to know the reason why cpufreq_update_util() has just been called and that can be passed as flags to cpufreq_update_util() and to the ->func() callback in struct update_util_data. However, doing that in addition to passing the util and max arguments they

Re: [PATCH] i2c: uniphier{-f}: don't print error when adding adapter fails

On Tue, Aug 09, 2016 at 10:11:40PM +0200, Wolfram Sang wrote: > The core will do this for us now. > > Signed-off-by: Wolfram Sang Acked-by: Guenter Roeck > --- > drivers/i2c/busses/i2c-uniphier-f.c | 5 - >

Re: [PATCH] i2c: uniphier{-f}: don't print error when adding adapter fails

On Tue, Aug 09, 2016 at 10:11:40PM +0200, Wolfram Sang wrote: > The core will do this for us now. > > Signed-off-by: Wolfram Sang Acked-by: Guenter Roeck > --- > drivers/i2c/busses/i2c-uniphier-f.c | 5 - > drivers/i2c/busses/i2c-uniphier.c | 5 - > 2 files changed, 10 deletions(-)

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

On Tue, Aug 09, 2016 at 10:14:48PM +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 09:04:35PM +0100, Alan Cox wrote: > > > > (Going back to pick up the specific licence thread) > > > > > > > > > > I'd like to see Richard do so as well. > > > With Richard that's 3 attorneys now. > > >

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

On Tue, Aug 09, 2016 at 10:14:48PM +0200, Luis R. Rodriguez wrote: > On Tue, Aug 09, 2016 at 09:04:35PM +0100, Alan Cox wrote: > > > > (Going back to pick up the specific licence thread) > > > > > > > > > > I'd like to see Richard do so as well. > > > With Richard that's 3 attorneys now. > > >

[PATCHv5] arm64: Handle el1 synchronous instruction aborts cleanly

Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at 08880700 Bad mode in Synchronous Abort handler detected on CPU2, code 0x840e -- IABT (current

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On Tue, Aug 09, 2016 at 07:22:21PM +0200, Greg Kroah-Hartman wrote: > > Can you push it into the -rc repository ? I see the patch in the queue, > > but not in the repository. > > Sorry about that, now regenerated. > All but the unicore32 build problems are now fixed. Guenter

[PATCHv5] arm64: Handle el1 synchronous instruction aborts cleanly

Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at 08880700 Bad mode in Synchronous Abort handler detected on CPU2, code 0x840e -- IABT (current

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On Tue, Aug 09, 2016 at 07:22:21PM +0200, Greg Kroah-Hartman wrote: > > Can you push it into the -rc repository ? I see the patch in the queue, > > but not in the repository. > > Sorry about that, now regenerated. > All but the unicore32 build problems are now fixed. Guenter

Making pdfdocs with sphinx - only select rst targets

I'm excited to see the new documentation format, so I'm changing my documentation in the pending patches I have to use it. I however cannot generate anything other than the main Documentation/output/pdf/Kernel.pdf How can I see in PDF the other documentation? I'm using: make DOCBOOKS=""

Making pdfdocs with sphinx - only select rst targets

I'm excited to see the new documentation format, so I'm changing my documentation in the pending patches I have to use it. I however cannot generate anything other than the main Documentation/output/pdf/Kernel.pdf How can I see in PDF the other documentation? I'm using: make DOCBOOKS=""

[PATCH] arm64: KVM: Save two instructions in __guest_enter()

We are doing an unnecessary stack push/pop operation when restoring the guest registers x0-x18 in __guest_enter(). This patch saves the two instructions by using x18 as a base register. No need to store the vcpu context pointer in stack because it is redundant and not being used anywhere, the same

[PATCH] arm64: KVM: Save two instructions in __guest_enter()

We are doing an unnecessary stack push/pop operation when restoring the guest registers x0-x18 in __guest_enter(). This patch saves the two instructions by using x18 as a base register. No need to store the vcpu context pointer in stack because it is redundant and not being used anywhere, the same

Re: [PATCH] rcu: Fix soft lockup for rcu_nocb_kthread

On 2016/6/16 22:19, Paul E. McKenney wrote: > On Thu, Jun 16, 2016 at 02:09:47PM +0800, Ding Tianhong wrote: >> On 2016/6/15 23:49, Paul E. McKenney wrote: >>> On Wed, Jun 15, 2016 at 03:27:36PM +0800, Ding Tianhong wrote: I met this problem when using the Testgine to send package to ixgbevf

Re: [PATCHv4] arm64: Handle el1 synchronous instruction aborts cleanly

On 08/09/2016 06:24 AM, Will Deacon wrote: On Mon, Aug 08, 2016 at 05:35:34PM -0700, Laura Abbott wrote: Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at

Re: [PATCH] rcu: Fix soft lockup for rcu_nocb_kthread

On 2016/6/16 22:19, Paul E. McKenney wrote: > On Thu, Jun 16, 2016 at 02:09:47PM +0800, Ding Tianhong wrote: >> On 2016/6/15 23:49, Paul E. McKenney wrote: >>> On Wed, Jun 15, 2016 at 03:27:36PM +0800, Ding Tianhong wrote: I met this problem when using the Testgine to send package to ixgbevf

Re: [PATCHv4] arm64: Handle el1 synchronous instruction aborts cleanly

On 08/09/2016 06:24 AM, Will Deacon wrote: On Mon, Aug 08, 2016 at 05:35:34PM -0700, Laura Abbott wrote: Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at

Re: [PATCH] ARM: dts: add rk3288-firefly-reload

On 08/09/2016 06:58 PM, Heiko Stübner wrote: Am Dienstag, 9. August 2016, 18:06:33 schrieb Randy Li: 從我的 iPad 傳送 陈豪 於 2016年8月9日 下午6:02 寫道： well，it has already been added The root cause is not act8846. Firefly have a bug with sdmmc and it seems they didn't fix

Re: [PATCH v1] firmware_class: encapsulate firmware loading status

On Thu, Aug 04, 2016 at 02:27:16PM +0200, Daniel Wagner wrote: > From: Daniel Wagner > > The firmware user helper code tracks the current state of the loading > process via an member of struct firmware_buf and a completion. Let's > encapsulate this simple state

Re: [PATCH] ARM: dts: add rk3288-firefly-reload

On 08/09/2016 06:58 PM, Heiko Stübner wrote: Am Dienstag, 9. August 2016, 18:06:33 schrieb Randy Li: 從我的 iPad 傳送 陈豪 於 2016年8月9日 下午6:02 寫道： well，it has already been added The root cause is not act8846. Firefly have a bug with sdmmc and it seems they didn't fix it in firefly-reload.

Re: [PATCH v1] firmware_class: encapsulate firmware loading status

On Thu, Aug 04, 2016 at 02:27:16PM +0200, Daniel Wagner wrote: > From: Daniel Wagner > > The firmware user helper code tracks the current state of the loading > process via an member of struct firmware_buf and a completion. Let's > encapsulate this simple state machine into struct fw_status. The

[PATCH 0/2] cpufreq / sched: Rework of cpufreq_update_util() arguments

Hi, There were some comments on the "cpufreq / sched: cpufreq_update_util() flags and iowait boosting" series I sent some time ago and I wanted to address them, but for this purpose I had to combine patches [1-2,4/7] from that series into one and make some changes on top of that. Then I thought

[PATCH 0/2] cpufreq / sched: Rework of cpufreq_update_util() arguments

Hi, There were some comments on the "cpufreq / sched: cpufreq_update_util() flags and iowait boosting" series I sent some time ago and I wanted to address them, but for this purpose I had to combine patches [1-2,4/7] from that series into one and make some changes on top of that. Then I thought

[PATCH 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

From: Rafael J. Wysocki It is useful to know the reason why cpufreq_update_util() has just been called and that can be passed as flags to cpufreq_update_util() and to the ->func() callback in struct update_util_data. However, doing that in addition to passing the

[PATCH 2/2] cpufreq / sched: Check cpu_of(rq) in cpufreq_update_util()

From: Rafael J. Wysocki All of the callers of cpufreq_update_util() check whether or not cpu_of(rq) is equal to smp_processor_id() before calling it and pass rq_clock(rq) to it as the time argument, so rework it to take a runqueue pointer as the argument and move the

[PATCH 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

From: Rafael J. Wysocki It is useful to know the reason why cpufreq_update_util() has just been called and that can be passed as flags to cpufreq_update_util() and to the ->func() callback in struct update_util_data. However, doing that in addition to passing the util and max arguments they

[PATCH 2/2] cpufreq / sched: Check cpu_of(rq) in cpufreq_update_util()

From: Rafael J. Wysocki All of the callers of cpufreq_update_util() check whether or not cpu_of(rq) is equal to smp_processor_id() before calling it and pass rq_clock(rq) to it as the time argument, so rework it to take a runqueue pointer as the argument and move the cpu_of(rq) check and the

[PATCH v5 2/2] Add support for SCT Write Same

SATA drives may support write same via SCT. This is useful for setting the drive contents to a specific pattern (0's). Translate a SCSI WRITE SAME command to be either a DSM TRIM command or an SCT Write Same command. Based on the UNMAP flag: - When set translate to DSM TRIM - When not set

[PATCH v5 2/2] Add support for SCT Write Same

SATA drives may support write same via SCT. This is useful for setting the drive contents to a specific pattern (0's). Translate a SCSI WRITE SAME command to be either a DSM TRIM command or an SCT Write Same command. Based on the UNMAP flag: - When set translate to DSM TRIM - When not set

[PATCH v5 1/2] Use kmap_atomic when rewriting attached page

The current SATL for WRITE_SAME does not protect against misaligned pages. Additionally the associated page should also kmap'd when being modified. Signed-off-by: Shaun Tancheff --- v5: Added prep patch to work with non-page aligned scatterlist pages and use

[PATCH v5 1/2] Use kmap_atomic when rewriting attached page

The current SATL for WRITE_SAME does not protect against misaligned pages. Additionally the associated page should also kmap'd when being modified. Signed-off-by: Shaun Tancheff --- v5: Added prep patch to work with non-page aligned scatterlist pages and use kmap_atomic() to lock page

[PATCH v5 0/2] Add support for SCT Write Same

At some point the method of issuing Write Same for ATA drives changed. Currently write same is commonly available via SCT so expose the SCT capabilities and use SCT Write Same when it is available. This is useful for zoned based media that prefers to support discard with lbprz set, aka discard

[PATCH v5 0/2] Add support for SCT Write Same

At some point the method of issuing Write Same for ATA drives changed. Currently write same is commonly available via SCT so expose the SCT capabilities and use SCT Write Same when it is available. This is useful for zoned based media that prefers to support discard with lbprz set, aka discard

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

On Tue, 9 Aug 2016 11:47:37 -0700 Andrey Smirnov wrote: > On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin wrote: > > On Thu, 28 Jul 2016 16:07:18 -0700 > > Andrey Smirnov wrote: > > > >> Convert fsl_rstcr_restart into a

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

On Tue, 9 Aug 2016 11:47:37 -0700 Andrey Smirnov wrote: > On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin wrote: > > On Thu, 28 Jul 2016 16:07:18 -0700 > > Andrey Smirnov wrote: > > > >> Convert fsl_rstcr_restart into a function to be registered with > >> register_reset_handler(). > >> > >>

[PATCH] mm, hugetlb: switch hugetlbfs to multi-order radix-tree entries

Hi Kirill, I wrote a patch to switch hugetlbfs to multi-order radix tree. Hopefully it's queued to your series. Thanks, Naoya Horiguchi --- From: Naoya Horiguchi Date: Wed, 10 Aug 2016 09:49:09 +0900 Subject: [PATCH] mm, hugetlb: switch hugetlbfs to multi-order

[PATCH] mm, hugetlb: switch hugetlbfs to multi-order radix-tree entries

Hi Kirill, I wrote a patch to switch hugetlbfs to multi-order radix tree. Hopefully it's queued to your series. Thanks, Naoya Horiguchi --- From: Naoya Horiguchi Date: Wed, 10 Aug 2016 09:49:09 +0900 Subject: [PATCH] mm, hugetlb: switch hugetlbfs to multi-order radix-tree entries Currently,

Re: [PATCH] i2c: uniphier{-f}: don't print error when adding adapter fails

2016-08-10 5:11 GMT+09:00 Wolfram Sang : > The core will do this for us now. > > Signed-off-by: Wolfram Sang > --- > drivers/i2c/busses/i2c-uniphier-f.c | 5 - > drivers/i2c/busses/i2c-uniphier.c | 5 - > 2 files changed, 10

Re: [PATCH] i2c: uniphier{-f}: don't print error when adding adapter fails

2016-08-10 5:11 GMT+09:00 Wolfram Sang : > The core will do this for us now. > > Signed-off-by: Wolfram Sang > --- > drivers/i2c/busses/i2c-uniphier-f.c | 5 - > drivers/i2c/busses/i2c-uniphier.c | 5 - > 2 files changed, 10 deletions(-) > > diff --git

Re: [PATCH v2 1/3] powerpc: Factor out common code in setup-common.c

On Tue, 9 Aug 2016 09:30:54 -0700 Andrey Smirnov wrote: > On Sun, Jul 31, 2016 at 8:40 PM, Nicholas Piggin wrote: > > On Thu, 28 Jul 2016 16:07:16 -0700 > > Andrey Smirnov wrote: > > > >> Factor out a small bit of common

Re: [PATCH v2 1/3] powerpc: Factor out common code in setup-common.c

On Tue, 9 Aug 2016 09:30:54 -0700 Andrey Smirnov wrote: > On Sun, Jul 31, 2016 at 8:40 PM, Nicholas Piggin wrote: > > On Thu, 28 Jul 2016 16:07:16 -0700 > > Andrey Smirnov wrote: > > > >> Factor out a small bit of common code in machine_restart(), > >> machine_power_off() and machine_halt().

[PATCH] soc: qcom: smd: Request irqs after parsing properties

The code exectued by the interrupt handler depends on the values parsed after requesting the irq, just to be save we should therefor move the request_irq() call to be done after parsing the properties. Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/smd.c | 32

[PATCH] soc: qcom: smd: Request irqs after parsing properties

The code exectued by the interrupt handler depends on the values parsed after requesting the irq, just to be save we should therefor move the request_irq() call to be done after parsing the properties. Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/smd.c | 32

[PATCH] soc: qcom: smd: Simplify multi channel handling

Multi-channel clients split between several drivers need a way to close individual channels, as these drivers might be removed individually. With this in place the responsibility of closing additionally opened channels to the client as well only concerning smd about the primary channel. With this

[PATCH] soc: qcom: smd: Simplify multi channel handling

Multi-channel clients split between several drivers need a way to close individual channels, as these drivers might be removed individually. With this in place the responsibility of closing additionally opened channels to the client as well only concerning smd about the primary channel. With this

Re: [v10 PATCH 0/5] Rockchip Type-C and DisplayPort driver

Hi Chris, On 2016년 08월 10일 08:32, Chris Zhong wrote: > Hi all > > This series patch is for rockchip Type-C phy and DisplayPort controller > driver. > > The USB Type-C PHY is designed to support the USB3 and DP applications. > The PHY basically has two main components: USB3 and DisplyPort. USB3

Re: [v10 PATCH 0/5] Rockchip Type-C and DisplayPort driver

Hi Chris, On 2016년 08월 10일 08:32, Chris Zhong wrote: > Hi all > > This series patch is for rockchip Type-C phy and DisplayPort controller > driver. > > The USB Type-C PHY is designed to support the USB3 and DP applications. > The PHY basically has two main components: USB3 and DisplyPort. USB3

[PATCH] soc: qcom: smd: Correct compile stub prototypes

The prototypes for the compile stubs was not properly marked as static inline, this patch corrects this. Fixes: f79a917e69e1 ("Merge tag 'qcom-soc-for-4.7-2' into net-next") Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/smd.h | 4 ++-- 1 file changed, 2

[PATCH] soc: qcom: smd: Correct compile stub prototypes

The prototypes for the compile stubs was not properly marked as static inline, this patch corrects this. Fixes: f79a917e69e1 ("Merge tag 'qcom-soc-for-4.7-2' into net-next") Signed-off-by: Bjorn Andersson --- include/linux/soc/qcom/smd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 9, 2016 at 12:16 PM, Konstantin Khlebnikov wrote: > > On Tue, Aug 9, 2016 at 7:05 PM, wrote: > > From: Sonny Rao > > > > This is based on earlier work by Thiago Goncales. It implements a new > > per process proc

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 9, 2016 at 12:16 PM, Konstantin Khlebnikov wrote: > > On Tue, Aug 9, 2016 at 7:05 PM, wrote: > > From: Sonny Rao > > > > This is based on earlier work by Thiago Goncales. It implements a new > > per process proc file which summarizes the contents of the smaps file > > but doesn't

Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On 08/09/2016 05:13 PM, Laura Abbott wrote: > On 08/09/2016 02:56 PM, Florian Fainelli wrote: >> On 08/08/2016 10:49 AM, Laura Abbott wrote: >>> arm may need the kernel_force_cache APIs to guarantee data consistency. >>> Implement versions of these APIs based on the DMA APIs. >>> >>>

Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On 08/09/2016 05:13 PM, Laura Abbott wrote: > On 08/09/2016 02:56 PM, Florian Fainelli wrote: >> On 08/08/2016 10:49 AM, Laura Abbott wrote: >>> arm may need the kernel_force_cache APIs to guarantee data consistency. >>> Implement versions of these APIs based on the DMA APIs. >>> >>>

Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

Quoting Peter Chen (2016-08-08 01:52:10) > From: Peter Chen > > At device tree, we have no device node for chipidea core, > the glue layer's node is the parent node for host and udc > device. But in related driver, the parent device is chipidea > core. So, in order to

Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

Quoting Peter Chen (2016-08-08 01:52:10) > From: Peter Chen > > At device tree, we have no device node for chipidea core, > the glue layer's node is the parent node for host and udc > device. But in related driver, the parent device is chipidea > core. So, in order to let the common driver get

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tuesday, August 09, 2016 11:23:31 PM Rafael J. Wysocki wrote: > On Tue, Aug 9, 2016 at 10:02 PM, Jiri Kosina wrote: > > On Tue, 9 Aug 2016, Rafael J. Wysocki wrote: > > > >> I have a murky suspicion, but it is really weird. Namely, what if > >> restore_jump_address in

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tuesday, August 09, 2016 11:23:31 PM Rafael J. Wysocki wrote: > On Tue, Aug 9, 2016 at 10:02 PM, Jiri Kosina wrote: > > On Tue, 9 Aug 2016, Rafael J. Wysocki wrote: > > > >> I have a murky suspicion, but it is really weird. Namely, what if > >> restore_jump_address in

Re: [PATCH] mm: fix the incorrect hugepages count

On Tue, Aug 09, 2016 at 06:32:39PM +0800, zhong jiang wrote: > On 2016/8/9 1:14, Mike Kravetz wrote: > > On 08/07/2016 07:49 PM, zhongjiang wrote: > >> From: zhong jiang > >> > >> when memory hotplug enable, free hugepages will be freed if movable node > >> offline. > >>

Re: [PATCH] mm: fix the incorrect hugepages count

On Tue, Aug 09, 2016 at 06:32:39PM +0800, zhong jiang wrote: > On 2016/8/9 1:14, Mike Kravetz wrote: > > On 08/07/2016 07:49 PM, zhongjiang wrote: > >> From: zhong jiang > >> > >> when memory hotplug enable, free hugepages will be freed if movable node > >> offline. > >> therefore,

Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On 08/09/2016 02:56 PM, Florian Fainelli wrote: On 08/08/2016 10:49 AM, Laura Abbott wrote: arm may need the kernel_force_cache APIs to guarantee data consistency. Implement versions of these APIs based on the DMA APIs. Signed-off-by: Laura Abbott ---

Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On 08/09/2016 02:56 PM, Florian Fainelli wrote: On 08/08/2016 10:49 AM, Laura Abbott wrote: arm may need the kernel_force_cache APIs to guarantee data consistency. Implement versions of these APIs based on the DMA APIs. Signed-off-by: Laura Abbott --- arch/arm/include/asm/cacheflush.h | 4

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-09 at 11:12 -0700, Alexander Duyck wrote: > > The PCI spec is what essentially assumes that there is only one block. > If I am not mistaken in the case of this device the second block here > actually contains device configuration data, not actual VPD data.  The > issue here is

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-09 at 11:12 -0700, Alexander Duyck wrote: > > The PCI spec is what essentially assumes that there is only one block. > If I am not mistaken in the case of this device the second block here > actually contains device configuration data, not actual VPD data.  The > issue here is

Re: spin_lock implicit/explicit memory barrier

On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > Hi Benjamin, Hi Michael, > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to  > arch_spin_is_locked()"): > > For the ipc/sem code, I would like to replace the spin_is_locked() with  > a smp_load_acquire(), see: > >

Re: spin_lock implicit/explicit memory barrier

On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > Hi Benjamin, Hi Michael, > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to  > arch_spin_is_locked()"): > > For the ipc/sem code, I would like to replace the spin_is_locked() with  > a smp_load_acquire(), see: > >

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

> On Tue, 2016-08-09 at 22:54 +1000, Alexey Kardashevskiy wrote: > The cxgb3 driver is reading the second bit starting from 0xc00 but since > the size is wrongly detected as 0x7c, VFIO blocks access beyond it and the > guest driver fails to probe. > > I also cannot find a clause in the PCI 3.0

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

> On Tue, 2016-08-09 at 22:54 +1000, Alexey Kardashevskiy wrote: > The cxgb3 driver is reading the second bit starting from 0xc00 but since > the size is wrongly detected as 0x7c, VFIO blocks access beyond it and the > guest driver fails to probe. > > I also cannot find a clause in the PCI 3.0

Re: [PATCH v2 1/1] Add nvd9128 as a simple panel

On Fri, Aug 05, 2016 at 11:47:54AM +0200, Fabien Lahoudere wrote: > Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel > > Signed-off-by: Fabien Lahoudere > --- > .../devicetree/bindings/display/panel/nvd,9128.txt | 7 ++ >

Re: [PATCH v2 1/1] Add nvd9128 as a simple panel

On Fri, Aug 05, 2016 at 11:47:54AM +0200, Fabien Lahoudere wrote: > Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel > > Signed-off-by: Fabien Lahoudere > --- > .../devicetree/bindings/display/panel/nvd,9128.txt | 7 ++ > .../devicetree/bindings/vendor-prefixes.txt| 1 + >

Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs

On 08/08/2016 09:20 AM, Oleg Nesterov wrote: > So far _I think_ that the bug is somewhere else... Say, someone clears > PG_locked without wake_up(). Then SIGKILL sent to the task sleeping in > sys_read() "adds" the necessary wakeup... Hello Oleg, Something that puzzles me is that removing the

Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs

On 08/08/2016 09:20 AM, Oleg Nesterov wrote: > So far _I think_ that the bug is somewhere else... Say, someone clears > PG_locked without wake_up(). Then SIGKILL sent to the task sleeping in > sys_read() "adds" the necessary wakeup... Hello Oleg, Something that puzzles me is that removing the

[PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds when p == current, but the CAP_SYS_NICE doesn't. Thus while the previous commit was intended to loosen the needed privledges to modify a processes

[PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds when p == current, but the CAP_SYS_NICE doesn't. Thus while the previous commit was intended to loosen the needed privledges to modify a processes

Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact

On Tue, Aug 9, 2016 at 2:51 AM, Peter Zijlstra wrote: > > Currently the percpu-rwsem switches to (global) atomic ops while a > writer is waiting; which could be quite a while and slows down > releasing the readers. > > This patch cures this problem by ordering the

Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact

On Tue, Aug 9, 2016 at 2:51 AM, Peter Zijlstra wrote: > > Currently the percpu-rwsem switches to (global) atomic ops while a > writer is waiting; which could be quite a while and slows down > releasing the readers. > > This patch cures this problem by ordering the reader-state vs > reader-count

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

2016-08-10 7:25 GMT+08:00 Wanpeng Li : > 2016-08-09 22:06 GMT+08:00 Rik van Riel : >> On Tue, 2016-08-09 at 11:59 +0800, Wanpeng Li wrote: >>> Hi Rik, >>> 2016-07-13 22:50 GMT+08:00 Frederic Weisbecker : >>> > From: Rik van Riel

Re: [PATCH 1/5] sched,time: Count actually elapsed irq & softirq time

2016-08-10 7:25 GMT+08:00 Wanpeng Li : > 2016-08-09 22:06 GMT+08:00 Rik van Riel : >> On Tue, 2016-08-09 at 11:59 +0800, Wanpeng Li wrote: >>> Hi Rik, >>> 2016-07-13 22:50 GMT+08:00 Frederic Weisbecker : >>> > From: Rik van Riel >>> > >>> > Currently, if there was any irq or softirq time during

<    1   2   3   4   5   6   7   8   9   10   >