[PATCH net-next 09/17] net: hns: modify buffer format of cpu data to le64

From: Qianqian Xie Hardware ring buffer data is stored in Little-endian. Thus cpu data should be modified to Little-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta

[PATCH net-next 08/17] net: hns: fix to intimate the link-status change by adding LF/RF method

From: Daode Huang In current scenario, when the interface is disabled we reset the XGMAC RX/TX functionality. This operation does not affects the PHY layer/SFP and which appears UP to the remote end(this behaviour is unlike GMAC). The result is remote end keeps on

RE: [PATCH V3 8/9] thermal: da9062/61: Thermal junction temperature monitoring driver

On 02 November 2016 13:29, Lukasz Luba wrote: [...] > Apart from these 2 comments, 10sec is not to long > (waiting for the temperature change)? Hi Lukasz, Are you saying the maximum polling time is too long or too short if it is fixed in the driver at 10 seconds? Certainly 10 seconds can be

[PATCH net-next 09/17] net: hns: modify buffer format of cpu data to le64

From: Qianqian Xie Hardware ring buffer data is stored in Little-endian. Thus cpu data should be modified to Little-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta --- drivers/net/ethernet/hisilicon/hns/hnae.h |6 +++--- 1 file changed, 3

[PATCH net-next 08/17] net: hns: fix to intimate the link-status change by adding LF/RF method

From: Daode Huang In current scenario, when the interface is disabled we reset the XGMAC RX/TX functionality. This operation does not affects the PHY layer/SFP and which appears UP to the remote end(this behaviour is unlike GMAC). The result is remote end keeps on sending the packets which gets

RE: [PATCH V3 8/9] thermal: da9062/61: Thermal junction temperature monitoring driver

On 02 November 2016 13:29, Lukasz Luba wrote: [...] > Apart from these 2 comments, 10sec is not to long > (waiting for the temperature change)? Hi Lukasz, Are you saying the maximum polling time is too long or too short if it is fixed in the driver at 10 seconds? Certainly 10 seconds can be

[PATCH net-next 07/17] net: hns: modify ethtool statistics value error

From: Qianqian Xie This patch modify the gmac_rx_filt_pkt and gmac_rx_octets_total_filt statistics value. The two statistics is inconsistent with register, and just the opposite. Signed-off-by: Qianqian Xie Signed-off-by: Jun He

[PATCH net-next 07/17] net: hns: modify ethtool statistics value error

From: Qianqian Xie This patch modify the gmac_rx_filt_pkt and gmac_rx_octets_total_filt statistics value. The two statistics is inconsistent with register, and just the opposite. Signed-off-by: Qianqian Xie Signed-off-by: Jun He Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta ---

[PATCH net-next 06/17] net: hns: delete redundant macro definition

From: Qianqian Xie This patch deletes redundant macro definitions in hns drivers. And change the .h file containing relation to make the layers more clearly Signed-off-by: Qianqian Xie Signed-off-by: Weiwei Deng

Re: KASAN & the vmalloc area

On Wed, Nov 9, 2016 at 8:53 AM, Andrey Ryabinin wrote: > On 11/08/2016 10:03 PM, Mark Rutland wrote: >> Hi, >> >> I see a while back [1] there was a discussion of what to do about KASAN >> and vmapped stacks, but it doesn't look like that was solved, judging by >> the

[PATCH net-next 06/17] net: hns: delete redundant macro definition

From: Qianqian Xie This patch deletes redundant macro definitions in hns drivers. And change the .h file containing relation to make the layers more clearly Signed-off-by: Qianqian Xie Signed-off-by: Weiwei Deng Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta ---

Re: KASAN & the vmalloc area

On Wed, Nov 9, 2016 at 8:53 AM, Andrey Ryabinin wrote: > On 11/08/2016 10:03 PM, Mark Rutland wrote: >> Hi, >> >> I see a while back [1] there was a discussion of what to do about KASAN >> and vmapped stacks, but it doesn't look like that was solved, judging by >> the vmapped stacks pull [2] for

[PATCH net-next 13/17] net: hns: modify tcam table of mac mc-port

From: Qianqian Xie Little-endian is only supported by current tcam table to add or delete mac mc-port. This patch makes it support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On 11/09/2016 10:35 AM, Thomas Gleixner wrote: Both ACPI and MP specifications require that the APIC id in the respective tables must be the same as the APIC id in CPUID. The kernel retrieves the physical package id from the APIC id during the ACPI/MP table scan and builds the physical to

[PATCH net-next 13/17] net: hns: modify tcam table of mac mc-port

From: Qianqian Xie Little-endian is only supported by current tcam table to add or delete mac mc-port. This patch makes it support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta ---

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On 11/09/2016 10:35 AM, Thomas Gleixner wrote: Both ACPI and MP specifications require that the APIC id in the respective tables must be the same as the APIC id in CPUID. The kernel retrieves the physical package id from the APIC id during the ACPI/MP table scan and builds the physical to

Re: KASAN & the vmalloc area

On Wed, Nov 9, 2016 at 2:56 AM, Mark Rutland wrote: > On Tue, Nov 08, 2016 at 02:09:27PM -0800, Dmitry Vyukov wrote: >> On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland wrote: >> > When KASAN is selected, we allocate shadow for the whole vmalloc area, >>

Re: [PATCH v7] soc: qcom: add l2 cache perf events driver

On Wed, Nov 09, 2016 at 05:54:13PM +, Mark Rutland wrote: > On Fri, Oct 28, 2016 at 04:50:13PM -0400, Neil Leeder wrote: > > + struct perf_event *events[MAX_L2_CTRS]; > > + struct l2cache_pmu *l2cache_pmu; > > + DECLARE_BITMAP(used_counters, MAX_L2_CTRS); > > +

Re: [PATCH] serial: pl011: add console matching function

On Tue, Oct 4, 2016 at 2:15 AM, Aleksey Makarov wrote: > This patch adds function pl011_console_match() that implements > method match of struct console. It allows to match consoles against > data specified in a string, for example taken from command line or >

Re: KASAN & the vmalloc area

On Wed, Nov 9, 2016 at 2:56 AM, Mark Rutland wrote: > On Tue, Nov 08, 2016 at 02:09:27PM -0800, Dmitry Vyukov wrote: >> On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland wrote: >> > When KASAN is selected, we allocate shadow for the whole vmalloc area, >> > using common zero pte, pmd, pud tables.

Re: [PATCH v7] soc: qcom: add l2 cache perf events driver

On Wed, Nov 09, 2016 at 05:54:13PM +, Mark Rutland wrote: > On Fri, Oct 28, 2016 at 04:50:13PM -0400, Neil Leeder wrote: > > + struct perf_event *events[MAX_L2_CTRS]; > > + struct l2cache_pmu *l2cache_pmu; > > + DECLARE_BITMAP(used_counters, MAX_L2_CTRS); > > +

Re: [PATCH] serial: pl011: add console matching function

On Tue, Oct 4, 2016 at 2:15 AM, Aleksey Makarov wrote: > This patch adds function pl011_console_match() that implements > method match of struct console. It allows to match consoles against > data specified in a string, for example taken from command line or > compiled by ACPI SPCR table

[PATCH net-next 10/17] net: hns: modify tcam table and set mac key

From: Qianqian Xie The current definition of dsaf_drv_tbl_tcam_key is only suitable for Little-endian. If data is stored in Big-endian, this may lead to error in data use. Shift operation can make it work normally in both Big-endian and Little-endian. Signed-off-by:

[PATCH net-next 10/17] net: hns: modify tcam table and set mac key

From: Qianqian Xie The current definition of dsaf_drv_tbl_tcam_key is only suitable for Little-endian. If data is stored in Big-endian, this may lead to error in data use. Shift operation can make it work normally in both Big-endian and Little-endian. Signed-off-by: Qianqian Xie Reviewed-by:

[PATCH net-next 15/17] net: hns: modify tcam table of mask_key

From: Qianqian Xie The packets of wrong mac address(only the last bit is different) can be received in Big-endian by current definition of mask_key. Thus it needs to be modified to support Big-endian and ensure Big-endian normal. Signed-off-by: Qianqian Xie

[PATCH net-next 11/17] net: hns: modify tcam table of mac uc-entry

From: Qianqian Xie The current definition of mac_uc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac uc-entry to support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang

[PATCH net-next 14/17] net: hns: modify tcam table of mac mc-entry

From: Qianqian Xie The current definition of mac_mc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac mc-entry to support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang

[PATCH net-next 04/17] net: hns: set default mac pause time to 0xffff

From: Daode Huang The default mac pause time set to 0xff which is too short for pausing, this patch change it to the max value 0x. Signed-off-by: Daode Huang Reviewed-by: Yisen Zhuang Reviewed-by: lipeng

[PATCH net-next 05/17] net: hns: bug fix about restart auto-negotiation

From: Daode Huang When set auto-negotiation off and duplex half, if run "ethtool -r ethX" on port with phy, then the port will be failed to work. It should forbid to start auto-negotiation when auto-negotiate is off. This patch add the limited condition. Reported-by:

[PATCH net-next 15/17] net: hns: modify tcam table of mask_key

From: Qianqian Xie The packets of wrong mac address(only the last bit is different) can be received in Big-endian by current definition of mask_key. Thus it needs to be modified to support Big-endian and ensure Big-endian normal. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang

[PATCH net-next 11/17] net: hns: modify tcam table of mac uc-entry

From: Qianqian Xie The current definition of mac_uc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac uc-entry to support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta ---

[PATCH net-next 14/17] net: hns: modify tcam table of mac mc-entry

From: Qianqian Xie The current definition of mac_mc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac mc-entry to support both Little-endian and Big-endian. Signed-off-by: Qianqian Xie Reviewed-by: Yisen Zhuang Signed-off-by: Salil Mehta ---

[PATCH net-next 04/17] net: hns: set default mac pause time to 0xffff

From: Daode Huang The default mac pause time set to 0xff which is too short for pausing, this patch change it to the max value 0x. Signed-off-by: Daode Huang Reviewed-by: Yisen Zhuang Reviewed-by: lipeng Signed-off-by: Salil Mehta --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h |

[PATCH net-next 05/17] net: hns: bug fix about restart auto-negotiation

From: Daode Huang When set auto-negotiation off and duplex half, if run "ethtool -r ethX" on port with phy, then the port will be failed to work. It should forbid to start auto-negotiation when auto-negotiate is off. This patch add the limited condition. Reported-by: Jinchuang Tian

Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs

On 11/08/2016 06:30 PM, Joel Holdsworth wrote: On the whole, I don't think the zero-length transfers are too egregiously bad, and all the alternatives seem worse to me. >>> >>> So why not turn the CS line into GPIO and just toggle the GPIO? >> >> Does that work with *all* SPI

Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs

On 11/08/2016 06:30 PM, Joel Holdsworth wrote: On the whole, I don't think the zero-length transfers are too egregiously bad, and all the alternatives seem worse to me. >>> >>> So why not turn the CS line into GPIO and just toggle the GPIO? >> >> Does that work with *all* SPI

Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory

On Mon, Nov 7, 2016 at 5:44 PM, Reza Arbab wrote: > When movable nodes are enabled, any node containing only hotpluggable > memory is made movable at boot time. > > On x86, hotpluggable memory is discovered by parsing the ACPI SRAT, > making corresponding calls to

Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory

On Mon, Nov 7, 2016 at 5:44 PM, Reza Arbab wrote: > When movable nodes are enabled, any node containing only hotpluggable > memory is made movable at boot time. > > On x86, hotpluggable memory is discovered by parsing the ACPI SRAT, > making corresponding calls to memblock_mark_hotplug(). > > If

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 11/06/2016 03:22 PM, Jonathan Maxwell wrote: > On Thu, Nov 3, 2016 at 8:40 AM, Brian King wrote: >> On 10/27/2016 10:26 AM, Eric Dumazet wrote: >>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: We recently encountered a bug where a few customers using

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 11/06/2016 03:22 PM, Jonathan Maxwell wrote: > On Thu, Nov 3, 2016 at 8:40 AM, Brian King wrote: >> On 10/27/2016 10:26 AM, Eric Dumazet wrote: >>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: We recently encountered a bug where a few customers using ibmveth on the same LPAR

[PATCH v4] KVM: x86: emulate FXSAVE and FXRSTOR

Internal errors were reported on 16 bit fxsave and fxrstor with ipxe. Old Intels don't have unrestricted_guest, so we have to emulate them. The patch takes advantage of the hardware implementation. AMD and Intel differ in saving and restoring other fields in first 32 bytes. A test wrote 0xff to

[PATCH v4] KVM: x86: emulate FXSAVE and FXRSTOR

Internal errors were reported on 16 bit fxsave and fxrstor with ipxe. Old Intels don't have unrestricted_guest, so we have to emulate them. The patch takes advantage of the hardware implementation. AMD and Intel differ in saving and restoring other fields in first 32 bytes. A test wrote 0xff to

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 10:54:52PM +0100, Thomas Gleixner wrote: > So for now we should fold something like the below into this patch. Ok, how's that? --- From: Borislav Petkov Date: Tue, 8 Nov 2016 16:20:05 +0100 Subject: [PATCH] x86/MCE: Correct TSC timestamping of error records

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 10:54:52PM +0100, Thomas Gleixner wrote: > So for now we should fold something like the below into this patch. Ok, how's that? --- From: Borislav Petkov Date: Tue, 8 Nov 2016 16:20:05 +0100 Subject: [PATCH] x86/MCE: Correct TSC timestamping of error records We did have

[PATCH 2/2] soc: qcom: smem_state: Fix include for ERR_PTR()

The correct include file for getting errno constants and ERR_PTR() is linux/err.h, rather than linux/errno.h, so fix the include. Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled smem_state") Signed-off-by: Bjorn Andersson --- Andy, I don't see

[PATCH 2/2] soc: qcom: smem_state: Fix include for ERR_PTR()

The correct include file for getting errno constants and ERR_PTR() is linux/err.h, rather than linux/errno.h, so fix the include. Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled smem_state") Signed-off-by: Bjorn Andersson --- Andy, I don't see anything else going into v4.10

[PATCH 1/2] wcn36xx: Correct Kconfig dependency

In the case SMD or WCNSS_CTRL are compiled as modules, wcn36xx must be compiled as module as well, so we need to mention this dependency. But we still want allow the driver to be compiled in case either of those are =n, for compile testing reasons. Signed-off-by: Bjorn Andersson

[PATCH 1/2] wcn36xx: Correct Kconfig dependency

In the case SMD or WCNSS_CTRL are compiled as modules, wcn36xx must be compiled as module as well, so we need to mention this dependency. But we still want allow the driver to be compiled in case either of those are =n, for compile testing reasons. Signed-off-by: Bjorn Andersson ---

Re: [PATCH v7] soc: qcom: add l2 cache perf events driver

Hi Neil, Apologies for the delay in replying to this. This is looking good. I have a few specific comments and a couple of general concerns below. Will, please see the bit below about cluster/socket aggregation (grep for your name). On Fri, Oct 28, 2016 at 04:50:13PM -0400, Neil Leeder wrote:

Re: [PATCH v7] soc: qcom: add l2 cache perf events driver

Hi Neil, Apologies for the delay in replying to this. This is looking good. I have a few specific comments and a couple of general concerns below. Will, please see the bit below about cluster/socket aggregation (grep for your name). On Fri, Oct 28, 2016 at 04:50:13PM -0400, Neil Leeder wrote:

Re: [PATCH net-next 0/2] ARM64: Add Internal PHY support for Meson GXL

From: Neil Armstrong Date: Fri, 4 Nov 2016 16:51:21 +0100 > The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the > external RGMII pins. > > In order to support switching between the two PHYs links, extended registers > size for mdio-mux-mmioreg

Re: [PATCH net-next 0/2] ARM64: Add Internal PHY support for Meson GXL

From: Neil Armstrong Date: Fri, 4 Nov 2016 16:51:21 +0100 > The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the > external RGMII pins. > > In order to support switching between the two PHYs links, extended registers > size for mdio-mux-mmioreg must be added. > > The DT

Re: sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

On Wed, Nov 09, 2016 at 05:59:33PM +0100, Oleg Nesterov wrote: > We need to ensure that autogroup/tg returned by autogroup_task_group() > can't go away if we race with autogroup_move_group(), and unless the > caller holds ->siglock we rely on fact that autogroup_move_group() > will a) see this

Re: sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

On Wed, Nov 09, 2016 at 05:59:33PM +0100, Oleg Nesterov wrote: > We need to ensure that autogroup/tg returned by autogroup_task_group() > can't go away if we race with autogroup_move_group(), and unless the > caller holds ->siglock we rely on fact that autogroup_move_group() > will a) see this

Re: [rcu] 49961e2723: WARNING: CPU: 0 PID: 1 at include/linux/mm.h:993 workingset_activation+0x54/0x7b

On Wed, Nov 09, 2016 at 01:21:33PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > commit 49961e272333ac720ac4ccbaba45521bfea259ae ("rcu: Maintain special bits > at bottom of ->dynticks

Re: [rcu] 49961e2723: WARNING: CPU: 0 PID: 1 at include/linux/mm.h:993 workingset_activation+0x54/0x7b

On Wed, Nov 09, 2016 at 01:21:33PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > commit 49961e272333ac720ac4ccbaba45521bfea259ae ("rcu: Maintain special bits > at bottom of ->dynticks

[RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

Hi All, This is a RFC patch for Synopsys Designware HDMI RX PHY e405. This phy receives and decodes HDMI video that is delivered to a controller. The controller bit is not yet ready for submission but we are planning to submit it as soon as possible. Main included features in this driver are:

[RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

Hi All, This is a RFC patch for Synopsys Designware HDMI RX PHY e405. This phy receives and decodes HDMI video that is delivered to a controller. The controller bit is not yet ready for submission but we are planning to submit it as soon as possible. Main included features in this driver are:

[PATCH] drivers: cpuidle: assign enter_freeze to same as enter callback function

enter_freeze() callback is expected atleast to do the same as enter() but it has to guarantee that interrupts aren't enabled at any point in its execution, as the tick is frozen. CPUs execute ->enter_freeze with the local tick or entire timekeeping suspended, so it must not re-enable interrupts

[PATCH] drivers: cpuidle: assign enter_freeze to same as enter callback function

enter_freeze() callback is expected atleast to do the same as enter() but it has to guarantee that interrupts aren't enabled at any point in its execution, as the tick is frozen. CPUs execute ->enter_freeze with the local tick or entire timekeeping suspended, so it must not re-enable interrupts

Re: [PATCH V2 2/5] arm64: Allow hw watchpoint at varied offset from base address

Hi Will, Thanks a lot for your review. On Tuesday 08 November 2016 08:56 AM, Will Deacon wrote: Hi Pratyush, On Thu, Oct 20, 2016 at 11:18:14AM +0530, Pratyush Anand wrote: ARM64 hardware supports watchpoint at any double word aligned address. However, it can select any consecutive bytes

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 03:14:35AM -0800, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 5:40 PM, Paul E. McKenney > wrote: Thank you for the review and comments! > > commit 49961e272333ac720ac4ccbaba45521bfea259ae > > Author: Paul E. McKenney

Re: [PATCH V2 2/5] arm64: Allow hw watchpoint at varied offset from base address

Hi Will, Thanks a lot for your review. On Tuesday 08 November 2016 08:56 AM, Will Deacon wrote: Hi Pratyush, On Thu, Oct 20, 2016 at 11:18:14AM +0530, Pratyush Anand wrote: ARM64 hardware supports watchpoint at any double word aligned address. However, it can select any consecutive bytes

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 09, 2016 at 03:14:35AM -0800, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 5:40 PM, Paul E. McKenney > wrote: Thank you for the review and comments! > > commit 49961e272333ac720ac4ccbaba45521bfea259ae > > Author: Paul E. McKenney > > Date: Tue Nov 8 14:25:21 2016 -0800 > > > >

Re: [PATCH V2 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses

On Tuesday 08 November 2016 05:28 PM, Pavel Labath wrote: + if (min_dist > 0 && min_dist != -1) { >> + /* No exact match found. */ >> + wp = slots[closest_match]; >> + info = counter_arch_bp(wp); >> + info->trigger = addr; >> +

Re: [PATCH V2 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses

On Tuesday 08 November 2016 05:28 PM, Pavel Labath wrote: + if (min_dist > 0 && min_dist != -1) { >> + /* No exact match found. */ >> + wp = slots[closest_match]; >> + info = counter_arch_bp(wp); >> + info->trigger = addr; >> +

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, 2016-11-09 at 11:27 -0500, J. Bruce Fields wrote: > On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > > > > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > > > > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > > > > > > > Hello,

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, 2016-11-09 at 11:27 -0500, J. Bruce Fields wrote: > On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > > > > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > > > > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > > > > > > > Hello,

Re: [PATCH 2/2] kthread: don't use to_live_kthread() in kthread_park() and kthread_unpark()

On 11/09, Thomas Gleixner wrote: > > > - watchdog_park_threads() and it does not look nice. The code is actually > > correct, get_online_cpus() ensures that kthread_park() can't race with > > itself (note that kthread_park() can't handle this race correctly), but > > imo it should not use

Re: [PATCH 2/2] kthread: don't use to_live_kthread() in kthread_park() and kthread_unpark()

On 11/09, Thomas Gleixner wrote: > > > - watchdog_park_threads() and it does not look nice. The code is actually > > correct, get_online_cpus() ensures that kthread_park() can't race with > > itself (note that kthread_park() can't handle this race correctly), but > > imo it should not use

Re: [ppdev] sysfs warning on qemu boot

Hi Joe, On 09/11/16 16:00, Joe Lawrence wrote: > Hi Sudip, > > I hit a sysfs_warn_dup inside QEMU running 4.9.0-rc4 (I suspect earlier > versions as well, but this is the first upstream I've run in a while). > This warning looks like something the kernel test robot ran into a few > months ago:

Re: [ppdev] sysfs warning on qemu boot

Hi Joe, On 09/11/16 16:00, Joe Lawrence wrote: > Hi Sudip, > > I hit a sysfs_warn_dup inside QEMU running 4.9.0-rc4 (I suspect earlier > versions as well, but this is the first upstream I've run in a while). > This warning looks like something the kernel test robot ran into a few > months ago:

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-09 18:01:09 [+0100], Borislav Petkov wrote: > On Wed, Nov 09, 2016 at 05:24:51PM +0100, Sebastian Andrzej Siewior wrote: > > The behaviour was not changed - it was only reorganized to keep in one > > spot. > > So there's the full CPU init path down cpu_up() -> ... -> identify_cpu() >

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-09 18:01:09 [+0100], Borislav Petkov wrote: > On Wed, Nov 09, 2016 at 05:24:51PM +0100, Sebastian Andrzej Siewior wrote: > > The behaviour was not changed - it was only reorganized to keep in one > > spot. > > So there's the full CPU init path down cpu_up() -> ... -> identify_cpu() >

Re: [PATCH v15 4/4] arm: dts: mt2701: Use real clock for UARTs

On 11/04/2016 08:43 AM, Erin Lo wrote: We used to use a fixed rate clock for the UARTs. Now that we have clock support we can associate the correct clocks to the UARTs and drop the 26MHz fixed rate UART clock. Signed-off-by: Erin Lo Applied, thanks. ---

Re: [PATCH v15 4/4] arm: dts: mt2701: Use real clock for UARTs

On 11/04/2016 08:43 AM, Erin Lo wrote: We used to use a fixed rate clock for the UARTs. Now that we have clock support we can associate the correct clocks to the UARTs and drop the 26MHz fixed rate UART clock. Signed-off-by: Erin Lo Applied, thanks. --- arch/arm/boot/dts/mt2701.dtsi |

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd, On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann wrote: > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote: >> > And Samsung. >> > Shall I create the immutable branch now? >> >> Arnd: are you happy with the new patches and changes? > > I still had some

Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

From: Madalin-Cristian Bucur Date: Wed, 9 Nov 2016 17:16:12 + >> From: Madalin-Cristian Bucur >> Sent: Monday, November 07, 2016 5:43 PM >> >> > From: David Miller [mailto:da...@davemloft.net] >> > Sent: Thursday, November 03, 2016 9:58 PM >> > >> > From: Madalin

Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

From: Madalin-Cristian Bucur Date: Wed, 9 Nov 2016 17:16:12 + >> From: Madalin-Cristian Bucur >> Sent: Monday, November 07, 2016 5:43 PM >> >> > From: David Miller [mailto:da...@davemloft.net] >> > Sent: Thursday, November 03, 2016 9:58 PM >> > >> > From: Madalin Bucur >> > Date: Wed, 2

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd, On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann wrote: > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote: >> > And Samsung. >> > Shall I create the immutable branch now? >> >> Arnd: are you happy with the new patches and changes? > > I still had some comments for

[PATCH v3 3/3] hwmon: (mcp3021) replace S_IRUGO with 0444

Replace S_IRUGO with the better readable 0444. This fixes a checkpatch warning. Signed-off-by: Clemens Gruber --- drivers/hwmon/mcp3021.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c index

[PATCH v3 3/3] hwmon: (mcp3021) replace S_IRUGO with 0444

Replace S_IRUGO with the better readable 0444. This fixes a checkpatch warning. Signed-off-by: Clemens Gruber --- drivers/hwmon/mcp3021.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c index 81f4b7f..3a007ab 100644 ---

[PATCH v3 1/3] hwmon: (mcp3021) add devicetree support

Support setting the reference voltage from the device tree. Signed-off-by: Clemens Gruber --- drivers/hwmon/mcp3021.c | 46 -- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/hwmon/mcp3021.c

[PATCH v3 1/3] hwmon: (mcp3021) add devicetree support

Support setting the reference voltage from the device tree. Signed-off-by: Clemens Gruber --- drivers/hwmon/mcp3021.c | 46 -- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c index

RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

> From: Madalin-Cristian Bucur > Sent: Monday, November 07, 2016 5:43 PM > > > From: David Miller [mailto:da...@davemloft.net] > > Sent: Thursday, November 03, 2016 9:58 PM > > > > From: Madalin Bucur > > Date: Wed, 2 Nov 2016 22:17:26 +0200 > > > > > This introduces the

RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

> From: Madalin-Cristian Bucur > Sent: Monday, November 07, 2016 5:43 PM > > > From: David Miller [mailto:da...@davemloft.net] > > Sent: Thursday, November 03, 2016 9:58 PM > > > > From: Madalin Bucur > > Date: Wed, 2 Nov 2016 22:17:26 +0200 > > > > > This introduces the Freescale Data Path

[PATCH 3/5] ASoC: wm_adsp: Add support for SYSTEM firmware controls

From: Stuart Henderson Add support for firmware controls marked SYSTEM. These are internal to the driver-firmware interface and do not have a user-accessible ALSA control. Signed-off-by: Stuart Henderson Signed-off-by:

[PATCH 5/5] ASoC: wm_adsp: Support acknowledged controls

This patch handles publishing acknowledged controls through ALSA. These controls allow user-side to send events to the firmware and wait for the firmware to acknowledge it. Note that although acked controls only operate in the direction host->firmware, and therefore they are write-only as seen

[PATCH 3/5] ASoC: wm_adsp: Add support for SYSTEM firmware controls

From: Stuart Henderson Add support for firmware controls marked SYSTEM. These are internal to the driver-firmware interface and do not have a user-accessible ALSA control. Signed-off-by: Stuart Henderson Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 28

[PATCH 5/5] ASoC: wm_adsp: Support acknowledged controls

This patch handles publishing acknowledged controls through ALSA. These controls allow user-side to send events to the firmware and wait for the firmware to acknowledge it. Note that although acked controls only operate in the direction host->firmware, and therefore they are write-only as seen

[PATCH 4/5] ASoC: wm_adsp: Signal firmware shutdown through event control

If the firmware has any system event signalling controls, signal them during DSP PRE_PMD to tell the firmware it is about to be stopped. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 114 +

[PATCH 2/5] ASoC: wm_adsp: factor out getting region name from type

This patch factors out converting a memory region type into a name string, mainly so that it can be used in log commands. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 53 +++--- 1 file changed, 22

[PATCH 1/5] ASoC: wm_adsp: factor out getting base register for a control

The lookup of the base register corresponding to a control is duplicated in read and write so factor it out into a separate function. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 46 -- 1 file

[PATCH 4/5] ASoC: wm_adsp: Signal firmware shutdown through event control

If the firmware has any system event signalling controls, signal them during DSP PRE_PMD to tell the firmware it is about to be stopped. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 114 + sound/soc/codecs/wmfw.h| 3 ++ 2

[PATCH 2/5] ASoC: wm_adsp: factor out getting region name from type

This patch factors out converting a memory region type into a name string, mainly so that it can be used in log commands. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 53 +++--- 1 file changed, 22 insertions(+), 31 deletions(-) diff

[PATCH 1/5] ASoC: wm_adsp: factor out getting base register for a control

The lookup of the base register corresponding to a control is duplicated in read and write so factor it out into a separate function. Signed-off-by: Richard Fitzgerald --- sound/soc/codecs/wm_adsp.c | 46 -- 1 file changed, 24 insertions(+), 22

it's worth reading

Hi, Look what I've got for you, I guess it's worth reading, more info here Take care, Benoit

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

Hi Johannes, On Wed, Nov 02, 2016 at 04:35:52PM -0600, Johannes Thumshirn wrote: > The Read Completion Boundary (RCB) bit must only be set on a device or > endpoint if it is set on the root complex. > > Certain BIOSes erroneously set the RCB Bit in their ACPI _HPX Tables > even if it is not set

it's worth reading

Hi, Look what I've got for you, I guess it's worth reading, more info here Take care, Benoit

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

Hi Johannes, On Wed, Nov 02, 2016 at 04:35:52PM -0600, Johannes Thumshirn wrote: > The Read Completion Boundary (RCB) bit must only be set on a device or > endpoint if it is set on the root complex. > > Certain BIOSes erroneously set the RCB Bit in their ACPI _HPX Tables > even if it is not set

<    4   5   6   7   8   9   10   11   12   13   >