Re: [PATCH 1/7] pstore: Make spinlock per zone instead of global

Apologies that not everyone got CC'd on the cover letter, like the rest of the patch series: https://lkml.org/lkml/2016/10/8/12 Also, this patch series is an RFC, I screwed up the subject line. Thanks, Joel On Fri, Oct 7, 2016 at 10:28 PM, Joel Fernandes wrote: > > Currently

Re: [PATCH 1/7] pstore: Make spinlock per zone instead of global

Apologies that not everyone got CC'd on the cover letter, like the rest of the patch series: https://lkml.org/lkml/2016/10/8/12 Also, this patch series is an RFC, I screwed up the subject line. Thanks, Joel On Fri, Oct 7, 2016 at 10:28 PM, Joel Fernandes wrote: > > Currently pstore has a

Re: [PATCH] x86/fpu: Remove 'eagerfpu=' docs

* Andy Lutomirski wrote: > Now that eagerfpu= is gone, remove it from the docs. Whoops. > > Fixes: ca6938a1cd8a ("x86/fpu: Hard-disable lazy FPU mode") > Signed-off-by: Andy Lutomirski > --- > Documentation/kernel-parameters.txt | 6 -- > 1 file

Re: [PATCH] x86/fpu: Remove 'eagerfpu=' docs

* Andy Lutomirski wrote: > Now that eagerfpu= is gone, remove it from the docs. Whoops. > > Fixes: ca6938a1cd8a ("x86/fpu: Hard-disable lazy FPU mode") > Signed-off-by: Andy Lutomirski > --- > Documentation/kernel-parameters.txt | 6 -- > 1 file changed, 6 deletions(-) > > diff --git

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 10:33 PM, Yinghai Lu wrote: > On Fri, Oct 7, 2016 at 10:26 PM, Yinghai Lu wrote: >> On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner >>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c >>> index

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 10:33 PM, Yinghai Lu wrote: > On Fri, Oct 7, 2016 at 10:26 PM, Yinghai Lu wrote: >> On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner >>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c >>> index 32a7d70..6d35baf 100644 >>> ---

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 10:26 PM, Yinghai Lu wrote: > On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner >> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c >> index 32a7d70..6d35baf 100644 >> --- a/arch/x86/kernel/acpi/boot.c >> +++

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 10:26 PM, Yinghai Lu wrote: > On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner >> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c >> index 32a7d70..6d35baf 100644 >> --- a/arch/x86/kernel/acpi/boot.c >> +++ b/arch/x86/kernel/acpi/boot.c >>

[PATCH 3/7] pstore: Remove case of PSTORE_TYPE_PMSG write using deprecated function

PMSG now uses ramoops_pstore_write_buf_user instead of ramoops_pstore_write_buf Remove the case where we check PSTORE_TYPE_PMSG case. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c

[PATCH 3/7] pstore: Remove case of PSTORE_TYPE_PMSG write using deprecated function

PMSG now uses ramoops_pstore_write_buf_user instead of ramoops_pstore_write_buf Remove the case where we check PSTORE_TYPE_PMSG case. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index

[PATCH 7/7] pstore: Merge per-CPU ftrace zones into one zone for output

Up until this patch, each of the per CPU buffers appear as a separate ftrace-ramoops-N file. In this patch we merge all the zones into one and populate the ftrace-ramoops-0 file. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c | 91

[PATCH 2/7] pstore: locking: dont lock unless caller asks to

In preparation of not locking at all for certain buffers depending on if there's contention, make locking optional depending if caller requested it. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c| 10 +- fs/pstore/ram_core.c | 27

[PATCH 5/7] ramoops: Split ftrace buffer space into per-CPU zones

If FTRACE_PER_CPU flag is passed to ramoops pdata, split the space into multiple zones depending on the number of CPUs. This speeds up the performance of function tracing by about 280% in my tests as we avoid the locking. The trade off being lesser space available per CPU. Let the ramoops user

[PATCH 6/7] pstore: Add support to store timestamp counter in ftrace records

In preparation for merging the per CPU buffers into one buffer when we retrieve the pstore ftrace data, we store the timestamp as a counter in the ftrace pstore record. We store the CPU number as well if !PSTORE_CPU_IN_IP, in this case we shift the counter and may lose ordering there but we

[PATCH 7/7] pstore: Merge per-CPU ftrace zones into one zone for output

Up until this patch, each of the per CPU buffers appear as a separate ftrace-ramoops-N file. In this patch we merge all the zones into one and populate the ftrace-ramoops-0 file. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c | 91 + 1

[PATCH 2/7] pstore: locking: dont lock unless caller asks to

In preparation of not locking at all for certain buffers depending on if there's contention, make locking optional depending if caller requested it. Signed-off-by: Joel Fernandes --- fs/pstore/ram.c| 10 +- fs/pstore/ram_core.c | 27 ---

[PATCH 5/7] ramoops: Split ftrace buffer space into per-CPU zones

If FTRACE_PER_CPU flag is passed to ramoops pdata, split the space into multiple zones depending on the number of CPUs. This speeds up the performance of function tracing by about 280% in my tests as we avoid the locking. The trade off being lesser space available per CPU. Let the ramoops user

[PATCH 6/7] pstore: Add support to store timestamp counter in ftrace records

In preparation for merging the per CPU buffers into one buffer when we retrieve the pstore ftrace data, we store the timestamp as a counter in the ftrace pstore record. We store the CPU number as well if !PSTORE_CPU_IN_IP, in this case we shift the counter and may lose ordering there but we

[PATCH 4/7] pstore: Make ramoops_init_przs generic for other prz arrays

Currently ramoops_init_przs is hard wired only for panic dump zone array. In preparation for the ftrace zone array (one zone per-cpu), make the function more generic to be able to handle this case. Add a new ramoops_init_dump_przs function and use the generic function for the dump prz array.

[PATCH 1/7] pstore: Make spinlock per zone instead of global

Currently pstore has a global spinlock for all zones. Since the zones are independent and modify different areas of memory, there's no need to have a global lock, make the lock per-zone to protect the respective zone. Signed-off-by: Joel Fernandes --- fs/pstore/ram_core.c

[PATCH 4/7] pstore: Make ramoops_init_przs generic for other prz arrays

Currently ramoops_init_przs is hard wired only for panic dump zone array. In preparation for the ftrace zone array (one zone per-cpu), make the function more generic to be able to handle this case. Add a new ramoops_init_dump_przs function and use the generic function for the dump prz array.

[PATCH 1/7] pstore: Make spinlock per zone instead of global

Currently pstore has a global spinlock for all zones. Since the zones are independent and modify different areas of memory, there's no need to have a global lock, make the lock per-zone to protect the respective zone. Signed-off-by: Joel Fernandes --- fs/pstore/ram_core.c | 11 +--

[RFC 0/7] pstore: Improve performance of ftrace backend with ramoops

Here's an early RFC for a patch series on improving ftrace throughput with ramoops. I am hoping to get some early comments so I'm releasing it in advance. It is functional and tested. Currently ramoops uses a single zone to store function traces. To make this work, it has to uses locking to

[RFC 0/7] pstore: Improve performance of ftrace backend with ramoops

Here's an early RFC for a patch series on improving ftrace throughput with ramoops. I am hoping to get some early comments so I'm releasing it in advance. It is functional and tested. Currently ramoops uses a single zone to store function traces. To make this work, it has to uses locking to

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner wrote: > Commit-ID: 8237bded3959c6d038798b905485d3ba94b8ea10 > Gitweb: http://git.kernel.org/tip/8237bded3959c6d038798b905485d3ba94b8ea10 > Author: Thomas Gleixner > AuthorDate: Fri, 7 Oct

Re: [tip:x86/urgent] x86/acpi: Prevent LAPIC id 0xff from being accounted

On Fri, Oct 7, 2016 at 6:28 AM, tip-bot for Thomas Gleixner wrote: > Commit-ID: 8237bded3959c6d038798b905485d3ba94b8ea10 > Gitweb: http://git.kernel.org/tip/8237bded3959c6d038798b905485d3ba94b8ea10 > Author: Thomas Gleixner > AuthorDate: Fri, 7 Oct 2016 14:02:12 +0200 > Committer:

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi tglx, At 10/07/2016 09:00 PM, Thomas Gleixner wrote: On Fri, 7 Oct 2016, Thomas Gleixner wrote: On Fri, 7 Oct 2016, Dou Liyang wrote: Is it possible that the "-1/ox" could appear in the MADT which is one of the ACPI tables? According to the SDM the x2apic id is a 32bit ID, so

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi tglx, At 10/07/2016 09:00 PM, Thomas Gleixner wrote: On Fri, 7 Oct 2016, Thomas Gleixner wrote: On Fri, 7 Oct 2016, Dou Liyang wrote: Is it possible that the "-1/ox" could appear in the MADT which is one of the ACPI tables? According to the SDM the x2apic id is a 32bit ID, so

[PATCH 4/5] rpmsg: Driver for user space endpoint interface

This driver allows rpmsg instances to expose access to rpmsg endpoints to user space processes. It provides a control interface, allowing userspace to export endpoints and an endpoint interface for each exposed endpoint. The implementation is based on prior art by Texas Instrument, Google,

[PATCH 2/5] rpmsg: Introduce a driver override mechanism

Similar to other subsystems it's useful to provide a mechanism to force a specific driver match on a device, so introduce this. Signed-off-by: Bjorn Andersson --- drivers/rpmsg/rpmsg_core.c | 3 +++ include/linux/rpmsg.h | 2 ++ 2 files changed, 5 insertions(+)

[PATCH 4/5] rpmsg: Driver for user space endpoint interface

This driver allows rpmsg instances to expose access to rpmsg endpoints to user space processes. It provides a control interface, allowing userspace to export endpoints and an endpoint interface for each exposed endpoint. The implementation is based on prior art by Texas Instrument, Google,

[PATCH 2/5] rpmsg: Introduce a driver override mechanism

Similar to other subsystems it's useful to provide a mechanism to force a specific driver match on a device, so introduce this. Signed-off-by: Bjorn Andersson --- drivers/rpmsg/rpmsg_core.c | 3 +++ include/linux/rpmsg.h | 2 ++ 2 files changed, 5 insertions(+) diff --git

[PATCH 5/5] rpmsg: smd: Register rpmsg user space interface for edges

Create and register a rpmsg device for use with the rpmsg user space interface, allowing user space to access SMD channels. Also provide the "rpmsg_name" device attribute to expose the edge name in sysfs, allowing the user to write udev rules for specific rpmsg devices and their children.

[PATCH 3/5] rpmsg: Support drivers without primary endpoint

Some types of rpmsg drivers does not have a primary endpoint to tie their existence upon, but wishes to create and destroy endpoints dynamically, e.g. based on user interactions. Allow rpmsg drivers to omit a driver callback to signal this case and make the probe path not create a primary

[PATCH 5/5] rpmsg: smd: Register rpmsg user space interface for edges

Create and register a rpmsg device for use with the rpmsg user space interface, allowing user space to access SMD channels. Also provide the "rpmsg_name" device attribute to expose the edge name in sysfs, allowing the user to write udev rules for specific rpmsg devices and their children.

[PATCH 3/5] rpmsg: Support drivers without primary endpoint

Some types of rpmsg drivers does not have a primary endpoint to tie their existence upon, but wishes to create and destroy endpoints dynamically, e.g. based on user interactions. Allow rpmsg drivers to omit a driver callback to signal this case and make the probe path not create a primary

[PATCH 1/5] rpmsg: smd: Reduce restrictions when finding channel

SMD channels are created by the remotes in "opening" state, but sometimes as we close and try to reopen them they linger in closing state. Following the search for a matching channel the create_ept() will verify that the channel is in a suitable state, so we can lax the restrictions of the search

[PATCH 1/5] rpmsg: smd: Reduce restrictions when finding channel

SMD channels are created by the remotes in "opening" state, but sometimes as we close and try to reopen them they linger in closing state. Following the search for a matching channel the create_ept() will verify that the channel is in a suitable state, so we can lax the restrictions of the search

[PATCH] perf, tools: Handle events including .c and .o

This patch helps with Sukadev's JSON event tree where such events can happen. >From Andi Kleen: Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading and then an error. This can happen for some Intel JSON events, which cannot be used. This patch fixes this problem by

[PATCH] perf, tools: Handle events including .c and .o

This patch helps with Sukadev's JSON event tree where such events can happen. >From Andi Kleen: Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading and then an error. This can happen for some Intel JSON events, which cannot be used. This patch fixes this problem by

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi tglx, At 10/07/2016 09:07 PM, Thomas Gleixner wrote: On Thu, 6 Oct 2016, Dou Liyang wrote: + if (processor->id >= 255) { + ++disabled_cpus; Incrementing disabled_cpus here is simply wrong because 0xff is an invalid local APIC id. So we can simply return -EINVAL and be

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi tglx, At 10/07/2016 09:07 PM, Thomas Gleixner wrote: On Thu, 6 Oct 2016, Dou Liyang wrote: + if (processor->id >= 255) { + ++disabled_cpus; Incrementing disabled_cpus here is simply wrong because 0xff is an invalid local APIC id. So we can simply return -EINVAL and be

Re: [PATCH] wan/fsl_ucc_hdlc: Fix size used in dma_free_coherent()

From: Christophe JAILLET Date: Fri, 7 Oct 2016 22:58:47 +0200 > Size used with 'dma_alloc_coherent()' and 'dma_free_coherent()' should be > consistent. > Here, the size of a pointer is used in dma_alloc... and the size of the > pointed structure is used in

Re: [PATCH] wan/fsl_ucc_hdlc: Fix size used in dma_free_coherent()

From: Christophe JAILLET Date: Fri, 7 Oct 2016 22:58:47 +0200 > Size used with 'dma_alloc_coherent()' and 'dma_free_coherent()' should be > consistent. > Here, the size of a pointer is used in dma_alloc... and the size of the > pointed structure is used in dma_free... > > This has been spotted

Re: [PATCH 1/3] perf, tools: Handle events including .c and .o

On 2016/10/7 4:18, Arnaldo Carvalho de Melo wrote: Em Wed, Oct 05, 2016 at 12:47:10PM -0700, Andi Kleen escreveu: From: Andi Kleen This is a generic bug fix, but it helps with Sukadev's JSON event tree where such events can happen. Any event inclduing a .c/.o/.bpf

Re: [PATCH 1/3] perf, tools: Handle events including .c and .o

On 2016/10/7 4:18, Arnaldo Carvalho de Melo wrote: Em Wed, Oct 05, 2016 at 12:47:10PM -0700, Andi Kleen escreveu: From: Andi Kleen This is a generic bug fix, but it helps with Sukadev's JSON event tree where such events can happen. Any event inclduing a .c/.o/.bpf currently triggers BPF

Re: [PATCH] net: macb: NULL out phydev after removing mdio bus

From: Xander Huff Date: Fri, 7 Oct 2016 10:13:22 -0500 > From: Nathan Sullivan > > To ensure the dev->phydev pointer is not used after becoming invalid in > mdiobus_unregister, set it to NULL. This happens when removing the macb > driver without

Re: [PATCH] net: macb: NULL out phydev after removing mdio bus

From: Xander Huff Date: Fri, 7 Oct 2016 10:13:22 -0500 > From: Nathan Sullivan > > To ensure the dev->phydev pointer is not used after becoming invalid in > mdiobus_unregister, set it to NULL. This happens when removing the macb > driver without first taking its interface down, since

RE: [RESEND PATCH v3] scsi: ufshcd: fix possible unclocked register access

Reviewed-by: Kiwoong Kim > Vendor specific setup_clocks callback may require the clocks managed > by ufshcd driver to be ON. So if the vendor specific setup_clocks callback > is called while the required clocks are turned off, it could result into > unclocked register

RE: [RESEND PATCH v3] scsi: ufshcd: fix possible unclocked register access

Reviewed-by: Kiwoong Kim > Vendor specific setup_clocks callback may require the clocks managed > by ufshcd driver to be ON. So if the vendor specific setup_clocks callback > is called while the required clocks are turned off, it could result into > unclocked register access. > > To prevent

RE: [v12, 0/8] Fix eSDHC host version register bug

Hi Uffe, Arnd and Scott, Any comments on this latest patcheset? Could we consider to merge it if no any other changes needed? :) Thanks. Best regards, Yangbo Lu > -Original Message- > From: Y.B. Lu > Sent: Monday, September 26, 2016 11:15 AM > To: linux-...@vger.kernel.org;

RE: [v12, 0/8] Fix eSDHC host version register bug

Hi Uffe, Arnd and Scott, Any comments on this latest patcheset? Could we consider to merge it if no any other changes needed? :) Thanks. Best regards, Yangbo Lu > -Original Message- > From: Y.B. Lu > Sent: Monday, September 26, 2016 11:15 AM > To: linux-...@vger.kernel.org;

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

Hi Neil, On 5 October 2016 at 18:44, NeilBrown wrote: > On Wed, Oct 05 2016, Felipe Balbi wrote: > >> Hi Baolin, >> >> Baolin Wang writes: > But you do! > The mA number from the USB configuration is passed to > usb_gadget_vbus_draw. >

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

Hi Neil, On 5 October 2016 at 18:44, NeilBrown wrote: > On Wed, Oct 05 2016, Felipe Balbi wrote: > >> Hi Baolin, >> >> Baolin Wang writes: > But you do! > The mA number from the USB configuration is passed to > usb_gadget_vbus_draw. > Your patch passes that to

Re: [PATCH V1 01/10] mfd: da9061: MFD core support

On Friday 07 October 2016 08:02 PM, Steve Twiss wrote: Hi, On 06 October 2016 17:34, Steve Twiss wrote: On 06 October 2016 11:38, Keerthy [mailto:a0393...@ti.com], wrote: + int cell_num; No need of cell_num. + cell_num = ARRAY_SIZE(da9061_devs); No need of the above

Re: [PATCH V1 01/10] mfd: da9061: MFD core support

On Friday 07 October 2016 08:02 PM, Steve Twiss wrote: Hi, On 06 October 2016 17:34, Steve Twiss wrote: On 06 October 2016 11:38, Keerthy [mailto:a0393...@ti.com], wrote: + int cell_num; No need of cell_num. + cell_num = ARRAY_SIZE(da9061_devs); No need of the above

[PATCH] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

vmxnet3_set_mc() still assumes zero is invalid pa: it assumes dma_mapping_error(...,0) returns true if vmxnet3_copy_mc() fails; it calls dma_unmap_single() iff new_table_pa is not zero. The patch adds an explicit variable to track status of new_table_pa. Found by Linux Driver Verification

[PATCH] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

vmxnet3_set_mc() still assumes zero is invalid pa: it assumes dma_mapping_error(...,0) returns true if vmxnet3_copy_mc() fails; it calls dma_unmap_single() iff new_table_pa is not zero. The patch adds an explicit variable to track status of new_table_pa. Found by Linux Driver Verification

Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC

在 2016/10/7 23:22, Gregory CLEMENT 写道: From: Ziji Hu Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY. Three types of PHYs are supported. Add support to multiple types of PHYs init and configuration. Add register definitions of PHYs. Signed-off-by: Hu Ziji

Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC

在 2016/10/7 23:22, Gregory CLEMENT 写道: From: Ziji Hu Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY. Three types of PHYs are supported. Add support to multiple types of PHYs init and configuration. Add register definitions of PHYs. Signed-off-by: Hu Ziji Reviewed-by: Gregory

Re: [PATCH 2/10] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c

Hi, 在 2016/10/7 23:22, Gregory CLEMENT 写道: From: Ziji Hu Export sdhci_start_signal_voltage_switch() from sdhci.c. Thus vendor sdhci driver can implement its own signal voltage switch routine. You can overwtite this callback within your driver itself. That is what other

Re: [PATCH 2/10] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c

Hi, 在 2016/10/7 23:22, Gregory CLEMENT 写道: From: Ziji Hu Export sdhci_start_signal_voltage_switch() from sdhci.c. Thus vendor sdhci driver can implement its own signal voltage switch routine. You can overwtite this callback within your driver itself. That is what other sdhci variant

[PATCH] arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER

The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig. Signed-off-by: Masahiro Yamada --- This is a counter-part of the following ARM-32bit variant:

[PATCH] arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER

The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig. Signed-off-by: Masahiro Yamada --- This is a counter-part of the following ARM-32bit variant: https://patchwork.kernel.org/patch/9341021/ As discussed with

Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER

2016-09-20 16:30 GMT+09:00 Philipp Zabel : > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada: >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig. >> >> Signed-off-by:

Re: [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER

2016-09-20 16:30 GMT+09:00 Philipp Zabel : > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada: >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig. >> >> Signed-off-by: Masahiro Yamada > >

Re: [PATCH 00/10] Introduce Juniper PTXPMB CPLD driver

On 10/07/16 16:39, Frank Rowand wrote: > On 10/07/16 08:17, Pantelis Antoniou wrote: >> Add Juniper's PTXPMB FPGA CPLD driver. Those FPGAs >> are present in Juniper's PTX series of routers. >> >> The MFD driver provices watchdog/i2c/gpio/mtd devices. >> >> There are full device tree binding

Re: [PATCH 00/10] Introduce Juniper PTXPMB CPLD driver

On 10/07/16 16:39, Frank Rowand wrote: > On 10/07/16 08:17, Pantelis Antoniou wrote: >> Add Juniper's PTXPMB FPGA CPLD driver. Those FPGAs >> are present in Juniper's PTX series of routers. >> >> The MFD driver provices watchdog/i2c/gpio/mtd devices. >> >> There are full device tree binding

[GIT PULL] blk-mq CPU hotplug

Hi Linus, Last topical branch, this is the conversion of blk-mq to the new hotplug state machine. This should merge cleanly. Please pull! git://git.kernel.dk/linux-block.git for-4.9/block-smp Jens Axboe (1): Merge

[GIT PULL] blk-mq CPU hotplug

Hi Linus, Last topical branch, this is the conversion of blk-mq to the new hotplug state machine. This should merge cleanly. Please pull! git://git.kernel.dk/linux-block.git for-4.9/block-smp Jens Axboe (1): Merge

[GIT PULL] blk-mq irq/cpu mapping updates

Hi Linus, This is the block-irq topic branch for 4.9-rc. It's mostly from Christoph, and it allows drivers to specify their own mappings, and more importantly, to share the blk-mq mappings with the IRQ affinity mappings. It's a good step towards making this work better out of the box. This will

[GIT PULL] blk-mq irq/cpu mapping updates

Hi Linus, This is the block-irq topic branch for 4.9-rc. It's mostly from Christoph, and it allows drivers to specify their own mappings, and more importantly, to share the blk-mq mappings with the IRQ affinity mappings. It's a good step towards making this work better out of the box. This will

[PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage

With centralized MTU checking, there's nothing productive done by eth_change_mtu that isn't already done in dev_set_mtu, so mark it as deprecated and remove all usage of it in the kernel. All callers have been audited for calls to alloc_etherdev* or ether_setup directly, which means they all have

[PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage

With centralized MTU checking, there's nothing productive done by eth_change_mtu that isn't already done in dev_set_mtu, so mark it as deprecated and remove all usage of it in the kernel. All callers have been audited for calls to alloc_etherdev* or ether_setup directly, which means they all have

[PATCH v3 net-next 1/2] net: centralize net_device min/max MTU checking

While looking into an MTU issue with sfc, I started noticing that almost every NIC driver with an ndo_change_mtu function implemented almost exactly the same range checks, and in many cases, that was the only practical thing their ndo_change_mtu function was doing. Quite a few drivers have either

Re: [PATCH v2 00/18] perf clang: Support compiling BPF script on the fly

On 2016/10/6 7:20, Arnaldo Carvalho de Melo wrote: Em Mon, Sep 26, 2016 at 07:26:54AM +, Wang Nan escreveu: This patch add builtin clang, allow perf compile BPF scripts on the fly. This is the first step to implement what I announced at LinuxCon 2016 NA: Ok, so I refreshed this series to

[PATCH v3 net-next 0/2] net: centralize net_device MTU bounds checking

Jarod Wilson (2): net: centralize net_device min/max MTU checking net: deprecate eth_change_mtu, remove usage While looking into an MTU issue with sfc, I started noticing that almost every NIC driver with an ndo_change_mtu function implemented almost exactly the same range checks, and in many

[PATCH v3 net-next 1/2] net: centralize net_device min/max MTU checking

While looking into an MTU issue with sfc, I started noticing that almost every NIC driver with an ndo_change_mtu function implemented almost exactly the same range checks, and in many cases, that was the only practical thing their ndo_change_mtu function was doing. Quite a few drivers have either

Re: [PATCH v2 00/18] perf clang: Support compiling BPF script on the fly

On 2016/10/6 7:20, Arnaldo Carvalho de Melo wrote: Em Mon, Sep 26, 2016 at 07:26:54AM +, Wang Nan escreveu: This patch add builtin clang, allow perf compile BPF scripts on the fly. This is the first step to implement what I announced at LinuxCon 2016 NA: Ok, so I refreshed this series to

[PATCH v3 net-next 0/2] net: centralize net_device MTU bounds checking

Jarod Wilson (2): net: centralize net_device min/max MTU checking net: deprecate eth_change_mtu, remove usage While looking into an MTU issue with sfc, I started noticing that almost every NIC driver with an ndo_change_mtu function implemented almost exactly the same range checks, and in many

Re: [PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

Hello, On Friday 07 October 2016 at 04:37:26PM, Dmitry Torokhov has written: > Hi Christophe, > > On Fri, Oct 07, 2016 at 12:41:48PM +0800, Christophe Tordeux wrote: > > From: Christophe TORDEUX > > > > With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and >

Re: [PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

Hello, On Friday 07 October 2016 at 04:37:26PM, Dmitry Torokhov has written: > Hi Christophe, > > On Fri, Oct 07, 2016 at 12:41:48PM +0800, Christophe Tordeux wrote: > > From: Christophe TORDEUX > > > > With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and > > probably other

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Fri, Sep 30, 2016 at 03:15:11PM +0200, Thomas Gleixner wrote: > On Tue, 27 Sep 2016, Rich Felker wrote: > > I've managed to get a trace with a stall. I'm not sure what the best > > way to share the full thing is, since it's large, but here are the > > potentially interesting parts. > > Upload

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Fri, Sep 30, 2016 at 03:15:11PM +0200, Thomas Gleixner wrote: > On Tue, 27 Sep 2016, Rich Felker wrote: > > I've managed to get a trace with a stall. I'm not sure what the best > > way to share the full thing is, since it's large, but here are the > > potentially interesting parts. > > Upload

[REGRESSION v4.7] i915 / drm crash when undocking from DP monitors

Hi folks, I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when booting it while in a docking station connected to two external DisplayPort monitors, undocking, and then either logging out or shutting down -- regardless of whether I've redocked it beforehand or not. Both logout and

[REGRESSION v4.7] i915 / drm crash when undocking from DP monitors

Hi folks, I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when booting it while in a docking station connected to two external DisplayPort monitors, undocking, and then either logging out or shutting down -- regardless of whether I've redocked it beforehand or not. Both logout and

Re: [PATCH 4/10] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers

Hi Joe, On 2016/10/8 4:44, Joe Perches wrote: > On Fri, 2016-10-07 at 17:22 +0200, Gregory CLEMENT wrote: >> Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host >> Controller drivers. > [] >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -7578,6 +7578,11 @@ M:Nicolas Pitre

Re: [PATCH 4/10] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers

Hi Joe, On 2016/10/8 4:44, Joe Perches wrote: > On Fri, 2016-10-07 at 17:22 +0200, Gregory CLEMENT wrote: >> Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host >> Controller drivers. > [] >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -7578,6 +7578,11 @@ M:Nicolas Pitre >> S:

[GIT PULL 5/8] ARM: SoC driver updates for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-drivers for you to fetch changes up to

[GIT PULL 3/8] ARM: SoC defconfig changes for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-defconfig for you to fetch changes up to

[GIT PULL 5/8] ARM: SoC driver updates for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-drivers for you to fetch changes up to

[GIT PULL 3/8] ARM: SoC defconfig changes for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-defconfig for you to fetch changes up to

[GIT PULL 6/8] ARM: DT updates for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt for you to fetch changes up to

[GIT PULL 7/8] ARM: 64-bit DT updates for v4.8

The following changes since commit f2a89d3b2b85b90b05453872aaabfdb412a21a03: arm64: dts: Fix broken architected timer interrupt trigger (2016-09-14 22:47:22 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt64 for

[GIT PULL 6/8] ARM: DT updates for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt for you to fetch changes up to

[GIT PULL 7/8] ARM: 64-bit DT updates for v4.8

The following changes since commit f2a89d3b2b85b90b05453872aaabfdb412a21a03: arm64: dts: Fix broken architected timer interrupt trigger (2016-09-14 22:47:22 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-dt64 for

[GIT PULL 1/8] ARM: SoC cleanups for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-cleanup for you to fetch changes up to

[GIT PULL 2/8] ARM: SoC platform updates for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc for you to fetch changes up to

[GIT PULL 4/8] ARM: SoC 64-bit changes for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-arm64 for you to fetch changes up to

[GIT PULL 1/8] ARM: SoC cleanups for v4.9

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-cleanup for you to fetch changes up to

  1   2   3   4   5   6   7   8   9   10   >