[PATCH] usb: usb-skeleton: make MODULE_LICENSE and SPDX tag match

GPL v2 is the original license according to the old license text. See f64cdd0e94f1faf3b7f2b03af71f70dc6d8da0c2. Signed-off-by: Marcus Folkesson --- drivers/usb/usb-skeleton.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] usb: usb-skeleton: make MODULE_LICENSE and SPDX tag match

GPL v2 is the original license according to the old license text. See f64cdd0e94f1faf3b7f2b03af71f70dc6d8da0c2. Signed-off-by: Marcus Folkesson --- drivers/usb/usb-skeleton.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usb-skeleton.c

[GIT PULL] GPIO fixes for v4.16 - second try

Hi Linus, here is this pull request again, fixing up the device tree property readouts for the GPIOs. Last time the fix needed fixing, not I think the fix is fixed. Please pull it in! Yours, Linus Walleij The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux

[GIT PULL] GPIO fixes for v4.16 - second try

Hi Linus, here is this pull request again, fixing up the device tree property readouts for the GPIOs. Last time the fix needed fixing, not I think the fix is fixed. Please pull it in! Yours, Linus Walleij The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux

Re[v2]: Use of GCC plugin instead ISO C

On Thu, 2018-02-22 at 20:07 +0530, Progyan Bhattacharya wrote: > On Sun, 2018-02-18 at 08:47 -0800, Randy Dunlap wrote: > > You could try (re)building with V=1 on the "make" command line and > > capture > > the output to see where the "pedantic" is coming from. > > This is a late reply. > I did

Re: [PATCH v4 1/4] HID: add driver for Valve Steam Controller

Rodrigo, On Wed, Feb 28, 2018 at 11:49:26PM +0100, Rodrigo Rivas Costa wrote: > On Wed, Feb 28, 2018 at 09:21:15PM +0200, Andy Shevchenko wrote: > > On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa > > wrote: > > > There are two ways to connect the Steam

Re[v2]: Use of GCC plugin instead ISO C

On Thu, 2018-02-22 at 20:07 +0530, Progyan Bhattacharya wrote: > On Sun, 2018-02-18 at 08:47 -0800, Randy Dunlap wrote: > > You could try (re)building with V=1 on the "make" command line and > > capture > > the output to see where the "pedantic" is coming from. > > This is a late reply. > I did

Re: [PATCH v4 1/4] HID: add driver for Valve Steam Controller

Rodrigo, On Wed, Feb 28, 2018 at 11:49:26PM +0100, Rodrigo Rivas Costa wrote: > On Wed, Feb 28, 2018 at 09:21:15PM +0200, Andy Shevchenko wrote: > > On Wed, Feb 28, 2018 at 8:43 PM, Rodrigo Rivas Costa > > wrote: > > > There are two ways to connect the Steam Controller: directly to the USB > > >

Re: [PATCH v1 3/4] ASoC: codecs: pcm179x: Add reset gpio

Hello, On Tue, 27 Feb 2018 23:02:00 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:32 +0100, Mylène Josserand wrote: > > Add a reset gpio to be able to reset this line at startup. > > > > Signed-off-by: Mylène Josserand

Re: [PATCH v1 3/4] ASoC: codecs: pcm179x: Add reset gpio

Hello, On Tue, 27 Feb 2018 23:02:00 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:32 +0100, Mylène Josserand wrote: > > Add a reset gpio to be able to reset this line at startup. > > > > Signed-off-by: Mylène Josserand > > This needs an updated of the DT binding,

Re: [PATCH v1 2/4] ASoC: codecs: pcm179x: Add support for PCM1789

Hello, On Tue, 27 Feb 2018 22:56:29 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:31 +0100, Mylène Josserand wrote: > > > diff --git a/sound/soc/codecs/pcm179x-i2c.c b/sound/soc/codecs/pcm179x-i2c.c > > index 795a0657c097..83a2e1508df8

Re: [PATCH v1 2/4] ASoC: codecs: pcm179x: Add support for PCM1789

Hello, On Tue, 27 Feb 2018 22:56:29 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:31 +0100, Mylène Josserand wrote: > > > diff --git a/sound/soc/codecs/pcm179x-i2c.c b/sound/soc/codecs/pcm179x-i2c.c > > index 795a0657c097..83a2e1508df8 100644 > > ---

Re: [PATCH v2 5/6] kconfig: invoke oldconfig instead of silentoldconfig from local*config

2018-02-28 14:15 GMT+09:00 Ulf Magnusson : > On Wed, Feb 28, 2018 at 09:15:25AM +0900, Masahiro Yamada wrote: >> The purpose of local{yes,mod}config is to arrange the .config file >> based on actually loaded modules. It is unnecessary to update >> include/generated/autoconf.h

Re: [PATCH v2 5/6] kconfig: invoke oldconfig instead of silentoldconfig from local*config

2018-02-28 14:15 GMT+09:00 Ulf Magnusson : > On Wed, Feb 28, 2018 at 09:15:25AM +0900, Masahiro Yamada wrote: >> The purpose of local{yes,mod}config is to arrange the .config file >> based on actually loaded modules. It is unnecessary to update >> include/generated/autoconf.h and include/config/*

Re: [PATCH] Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table

Hi Kai-Heng, > The issue can be reproduced before commit fd865802c66b ("Bluetooth: > btusb: fix QCA Rome suspend/resume") gets introduced, so the reset > resume quirk is still needed for this system. > > T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 2.01

Re: [PATCH] Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table

Hi Kai-Heng, > The issue can be reproduced before commit fd865802c66b ("Bluetooth: > btusb: fix QCA Rome suspend/resume") gets introduced, so the reset > resume quirk is still needed for this system. > > T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 2.01

Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

On Thu, 2018-03-01 at 11:47 +0800, Zhiyong Tao wrote: > On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote: > > On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote: > > > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote: > > > > For generic pins, parameter "arg" is 0 or 1. > > > > For special

Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

On Thu, 2018-03-01 at 11:47 +0800, Zhiyong Tao wrote: > On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote: > > On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote: > > > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote: > > > > For generic pins, parameter "arg" is 0 or 1. > > > > For special

Re: [PATCH v1 1/4] ASoC: codecs: pcm179x: Add PCM1789 id

Hello, Thank you for the review. On Tue, 27 Feb 2018 22:51:40 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:30 +0100, Mylène Josserand wrote: > > To prepare the support for the PCM1789, add a new compatible > > and use the i2c_id to handle,

Re: [PATCH v1 1/4] ASoC: codecs: pcm179x: Add PCM1789 id

Hello, Thank you for the review. On Tue, 27 Feb 2018 22:51:40 +0100 Thomas Petazzoni wrote: > Hello, > > On Tue, 27 Feb 2018 22:24:30 +0100, Mylène Josserand wrote: > > To prepare the support for the PCM1789, add a new compatible > > and use the i2c_id to handle, later, the differences

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information about the memory map

Re: [PATCH v2] Input: gpio_keys: Add level trigger support for GPIO keys

On 28 February 2018 at 20:53, Linus Walleij wrote: > On Mon, Feb 26, 2018 at 7:24 AM, Baolin Wang wrote: >> On 21 February 2018 at 19:35, Baolin Wang wrote: >>> On 20 February 2018 at 02:11, Rob Herring

Re: [PATCH v2] Input: gpio_keys: Add level trigger support for GPIO keys

On 28 February 2018 at 20:53, Linus Walleij wrote: > On Mon, Feb 26, 2018 at 7:24 AM, Baolin Wang wrote: >> On 21 February 2018 at 19:35, Baolin Wang wrote: >>> On 20 February 2018 at 02:11, Rob Herring wrote: > > diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt >

Re: [PATCH] clk: tegra: fix pllu rate configuration

On Wed, Feb 28, 2018 at 08:20:47PM +0300, Dmitry Osipenko wrote: > On 28.02.2018 17:14, Peter De Schrijver wrote: > > On Wed, Feb 28, 2018 at 03:00:23PM +0300, Dmitry Osipenko wrote: > >> On 28.02.2018 12:36, Peter De Schrijver wrote: > >>> On Tue, Feb 27, 2018 at 02:59:11PM +0300, Dmitry Osipenko

Re: [PATCH] clk: tegra: fix pllu rate configuration

On Wed, Feb 28, 2018 at 08:20:47PM +0300, Dmitry Osipenko wrote: > On 28.02.2018 17:14, Peter De Schrijver wrote: > > On Wed, Feb 28, 2018 at 03:00:23PM +0300, Dmitry Osipenko wrote: > >> On 28.02.2018 12:36, Peter De Schrijver wrote: > >>> On Tue, Feb 27, 2018 at 02:59:11PM +0300, Dmitry Osipenko

[PATCH v4] Input: gpio_keys: Add level trigger support for GPIO keys

On some platforms (such as Spreadtrum platform), the GPIO keys can only be triggered by level type. So this patch introduces one trigger_type to indicate if the button's interrupt type is level trigger or edge trigger. Signed-off-by: Baolin Wang --- Changes since v3: -

[PATCH v4] Input: gpio_keys: Add level trigger support for GPIO keys

On some platforms (such as Spreadtrum platform), the GPIO keys can only be triggered by level type. So this patch introduces one trigger_type to indicate if the button's interrupt type is level trigger or edge trigger. Signed-off-by: Baolin Wang --- Changes since v3: - Remove the reserse level

Re: 4.16 regression: s2ram broken on non-PAE i686

On Wed, 28 Feb 2018, Woody Suwalski wrote: > Thanks for the patch, good news, it did fix the problem. > I did 2 builds and both worked OK over the s2ram cycle. Good. > It will be necessary to add the patch to 4.15-stable and 4.14-stable, I > believe that both have now broken s2ram. Right, it's

Re: [PATCH v3] Input: gpio_keys: Add level trigger support for GPIO keys

On 28 February 2018 at 22:44, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 1:44 PM, Baolin Wang wrote: >> On some platforms (such as Spreadtrum platform), the GPIO keys can only >> be triggered by level type. So this patch introduces one property to >>

Re: 4.16 regression: s2ram broken on non-PAE i686

On Wed, 28 Feb 2018, Woody Suwalski wrote: > Thanks for the patch, good news, it did fix the problem. > I did 2 builds and both worked OK over the s2ram cycle. Good. > It will be necessary to add the patch to 4.15-stable and 4.14-stable, I > believe that both have now broken s2ram. Right, it's

Re: [PATCH v3] Input: gpio_keys: Add level trigger support for GPIO keys

On 28 February 2018 at 22:44, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 1:44 PM, Baolin Wang wrote: >> On some platforms (such as Spreadtrum platform), the GPIO keys can only >> be triggered by level type. So this patch introduces one property to >> indicate if the GPIO trigger type is

Re: [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/18 19:28, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/18 19:28, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

On 28/02/18 19:28, Maran Wilson wrote: > The start info structure that is defined as part of the x86/HVM direct boot > ABI and used for starting Xen PVH guests would be more versatile if it also > included a way to pass information about the memory map to the guest. This > would allow KVM guests

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

On 28/02/18 19:28, Maran Wilson wrote: > The start info structure that is defined as part of the x86/HVM direct boot > ABI and used for starting Xen PVH guests would be more versatile if it also > included a way to pass information about the memory map to the guest. This > would allow KVM guests

Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

Hi, On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote: > > +struct device *device_find_connection(struct device *dev, const char > > +*con_id) { > > + return __device_find_connection(dev, con_id, generic_match, NULL); } > > - return __device_find_connection(dev, con_id,

Re: [PATCH v5 01/12] drivers: base: Unified device connection lookup

Hi, On Thu, Mar 01, 2018 at 12:56:57AM +, Jun Li wrote: > > +struct device *device_find_connection(struct device *dev, const char > > +*con_id) { > > + return __device_find_connection(dev, con_id, generic_match, NULL); } > > - return __device_find_connection(dev, con_id,

Re: [PATCH v5 08/12] xhci: Add Intel extended cap / otg phy mux handling

On Wed, Feb 28, 2018 at 04:42:32PM +0100, Hans de Goede wrote: > Hi, > > On 28-02-18 16:15, Heikki Krogerus wrote: > > On Wed, Feb 28, 2018 at 04:07:45PM +0100, Hans de Goede wrote: > > > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h > > > index 96099a245c69..5917e3095e2a 100644

Re: [PATCH v5 08/12] xhci: Add Intel extended cap / otg phy mux handling

On Wed, Feb 28, 2018 at 04:42:32PM +0100, Hans de Goede wrote: > Hi, > > On 28-02-18 16:15, Heikki Krogerus wrote: > > On Wed, Feb 28, 2018 at 04:07:45PM +0100, Hans de Goede wrote: > > > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h > > > index 96099a245c69..5917e3095e2a 100644

[PATCH v3 2/2] phy: add inno-usb2-phy driver for hi3798cv200 SoC

From: Pengcheng Li It adds inno-usb2-phy driver for hi3798cv200 SoC USB 2.0 support. One inno-usb2-phy device can support up to two PHY ports. While there is device level reference clock and power reset to be controlled, each PHY port has its own utmi reset that needs to

[PATCH v3 1/2] dt-bindings: add bindings doc for HiSilicon INNO USB2 PHY

From: Pengcheng Li It adds device tree bindings document for HiSilicon INNO USB2 PHY. Signed-off-by: Pengcheng Li Signed-off-by: Jiancheng Xue Signed-off-by: Shawn Guo ---

[PATCH v3 1/2] dt-bindings: add bindings doc for HiSilicon INNO USB2 PHY

From: Pengcheng Li It adds device tree bindings document for HiSilicon INNO USB2 PHY. Signed-off-by: Pengcheng Li Signed-off-by: Jiancheng Xue Signed-off-by: Shawn Guo --- .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 52 ++ 1 file changed, 52 insertions(+)

[PATCH v3 2/2] phy: add inno-usb2-phy driver for hi3798cv200 SoC

From: Pengcheng Li It adds inno-usb2-phy driver for hi3798cv200 SoC USB 2.0 support. One inno-usb2-phy device can support up to two PHY ports. While there is device level reference clock and power reset to be controlled, each PHY port has its own utmi reset that needs to assert/de-assert as

[PATCH v3 0/2] Add HiSilicon INNO USB2 PHY driver support

It adds device tree bindings and driver support for HiSilicon INNO USB2 PHY device, which can be found on HiSilicon STB SoC Hi3798cv200. Changes for v3: - Make combphy device be child of peripheral controller and use 'reg' property for mapping combphy configuration register. Changes for v2:

[PATCH v3 0/2] Add HiSilicon INNO USB2 PHY driver support

It adds device tree bindings and driver support for HiSilicon INNO USB2 PHY device, which can be found on HiSilicon STB SoC Hi3798cv200. Changes for v3: - Make combphy device be child of peripheral controller and use 'reg' property for mapping combphy configuration register. Changes for v2:

Re: [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The original design for PVH entry in Xen guests relies on being able to > obtain the memory map from the hypervisor using a hypercall.

Re: [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The original design for PVH entry in Xen guests relies on being able to > obtain the memory map from the hypervisor using a hypercall.

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 28/02/18 19:27, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The first step in doing that, is to > create a new config option for

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 28/02/18 19:27, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The first step in doing that, is to > create a new config option for

Re: [PATCH v3 0/4] Split page_type out from mapcount

On Wed, 28 Feb 2018 14:31:53 -0800 Matthew Wilcox wrote: > From: Matthew Wilcox > > I want to use the _mapcount field to record what a page is in use as. > This can help with debugging and we can also expose that information to > userspace through

Re: [PATCH v3 0/4] Split page_type out from mapcount

On Wed, 28 Feb 2018 14:31:53 -0800 Matthew Wilcox wrote: > From: Matthew Wilcox > > I want to use the _mapcount field to record what a page is in use as. > This can help with debugging and we can also expose that information to > userspace through /proc/kpageflags to help diagnose memory usage

Re: [RFC PATCH v2 00/12] Rewrite asm-generic/bitops/{atomic,lock}.h and use on arm64

2018-02-27 0:04 GMT+09:00 Will Deacon : > Hi everyone, > > This is version two of the RFC I previously posted here: > > https://www.spinics.net/lists/arm-kernel/msg634719.html > > Changes since v1 include: > > * Fixed __clear_bit_unlock to work on archs with lock-based

Re: [RFC PATCH v2 00/12] Rewrite asm-generic/bitops/{atomic,lock}.h and use on arm64

2018-02-27 0:04 GMT+09:00 Will Deacon : > Hi everyone, > > This is version two of the RFC I previously posted here: > > https://www.spinics.net/lists/arm-kernel/msg634719.html > > Changes since v1 include: > > * Fixed __clear_bit_unlock to work on archs with lock-based atomics > * Moved lock

Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

Le 28/02/2018 à 07:53, Nicholas Piggin a écrit : On Tue, 27 Feb 2018 18:11:07 +0530 "Aneesh Kumar K.V" wrote: Nicholas Piggin writes: On Tue, 27 Feb 2018 14:31:07 +0530 "Aneesh Kumar K.V" wrote:

Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

Le 28/02/2018 à 07:53, Nicholas Piggin a écrit : On Tue, 27 Feb 2018 18:11:07 +0530 "Aneesh Kumar K.V" wrote: Nicholas Piggin writes: On Tue, 27 Feb 2018 14:31:07 +0530 "Aneesh Kumar K.V" wrote: Christophe Leroy writes: The number of high slices a process might use now depends

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

On Thu, Mar 1, 2018 at 3:55 AM, Michael Ellerman wrote: > Mathieu Malaterre writes: > >> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the >> array feature_properties is defined as an empty array, which in turn >> triggers the

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

On Thu, Mar 1, 2018 at 3:55 AM, Michael Ellerman wrote: > Mathieu Malaterre writes: > >> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the >> array feature_properties is defined as an empty array, which in turn >> triggers the following warning (treated as error on

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Wed, 2018-02-28 at 17:08 -0600, Bjorn Helgaas wrote: > > What's the bottom line?  Do we want this for sparc?  If so, do you > want to take it, Dave M, or would you like me to? I need to fix it first, and then the intention is for Dave to take it. There'll be a final patch to remove

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Wed, 2018-02-28 at 17:08 -0600, Bjorn Helgaas wrote: > > What's the bottom line?  Do we want this for sparc?  If so, do you > want to take it, Dave M, or would you like me to? I need to fix it first, and then the intention is for Dave to take it. There'll be a final patch to remove

[PATCH v2] ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

The values of bclk and fsync are inverted WRT the codec. But the existing solution already works for Broadwell, see the alsa-lib config: `alsa-lib/src/conf/topology/broadwell/broadwell.conf` This commit provides the backwards-compatible solution to fix this misuse. This commit goes in pair with

[PATCH v2] ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

The values of bclk and fsync are inverted WRT the codec. But the existing solution already works for Broadwell, see the alsa-lib config: `alsa-lib/src/conf/topology/broadwell/broadwell.conf` This commit provides the backwards-compatible solution to fix this misuse. This commit goes in pair with

Re: [RFC PATCH v2] ptr_ring: linked list fallback

On 2018年02月28日 23:43, Michael S. Tsirkin wrote: On Wed, Feb 28, 2018 at 10:20:33PM +0800, Jason Wang wrote: On 2018年02月28日 22:01, Michael S. Tsirkin wrote: On Wed, Feb 28, 2018 at 02:28:21PM +0800, Jason Wang wrote: On 2018年02月28日 12:09, Michael S. Tsirkin wrote: Or we can add plist to a

Re: [RFC PATCH v2] ptr_ring: linked list fallback

On 2018年02月28日 23:43, Michael S. Tsirkin wrote: On Wed, Feb 28, 2018 at 10:20:33PM +0800, Jason Wang wrote: On 2018年02月28日 22:01, Michael S. Tsirkin wrote: On Wed, Feb 28, 2018 at 02:28:21PM +0800, Jason Wang wrote: On 2018年02月28日 12:09, Michael S. Tsirkin wrote: Or we can add plist to a

Re: [PATCH] e1000e: Fix link status in case of error.

On 2018/02/28 08:48, Alexander Duyck wrote: > On Tue, Feb 27, 2018 at 9:20 PM, Benjamin Poirier wrote: > > Before commit 19110cfbb34d ("e1000e: Separate signaling for link check/link > > up"), errors which happen after "get_link_status = false" in the copper > > check_for_link

Re: [PATCH] e1000e: Fix link status in case of error.

On 2018/02/28 08:48, Alexander Duyck wrote: > On Tue, Feb 27, 2018 at 9:20 PM, Benjamin Poirier wrote: > > Before commit 19110cfbb34d ("e1000e: Separate signaling for link check/link > > up"), errors which happen after "get_link_status = false" in the copper > > check_for_link callbacks would be

Re: [PATCH 3/5] staging: ks7010: Factor out repeated code into function 'ks_wlan_cap()'.

On Wed, Feb 28, 2018 at 09:19:09PM -0800, Quytelda Kahja wrote: > The code that generates a WLAN capability mask is repeated in five > functions. This change refactors that code into a new function, which is > called now in each of those functions. Perhaps in future something like: Code to

Re: [PATCH 3/5] staging: ks7010: Factor out repeated code into function 'ks_wlan_cap()'.

On Wed, Feb 28, 2018 at 09:19:09PM -0800, Quytelda Kahja wrote: > The code that generates a WLAN capability mask is repeated in five > functions. This change refactors that code into a new function, which is > called now in each of those functions. Perhaps in future something like: Code to

[PATCH v3 2/2] kconfig: rename silentoldconfig to syncconfig

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a historical misnomer. That commit removed it from help and docs since it is an internal interface. If so, it should be allowed to rename it to something more

[PATCH v3 2/2] kconfig: rename silentoldconfig to syncconfig

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a historical misnomer. That commit removed it from help and docs since it is an internal interface. If so, it should be allowed to rename it to something more

[PATCH v3 1/2] kconfig: invoke oldconfig instead of silentoldconfig from local*config

The purpose of local{yes,mod}config is to arrange the .config file based on actually loaded modules. It is unnecessary to update include/generated/autoconf.h and include/config/* stuff here. They will be updated as needed during the build. Signed-off-by: Masahiro Yamada

[PATCH v3 1/2] kconfig: invoke oldconfig instead of silentoldconfig from local*config

The purpose of local{yes,mod}config is to arrange the .config file based on actually loaded modules. It is unnecessary to update include/generated/autoconf.h and include/config/* stuff here. They will be updated as needed during the build. Signed-off-by: Masahiro Yamada Reviewed-by: Ulf

Re: [PATCH 1/5] staging: ks7010: Use constants from ieee80211_eid instead of literal ints.

On Wed, Feb 28, 2018 at 09:19:07PM -0800, Quytelda Kahja wrote: ... I would normally respond to the cover letter but here goes. Reviewed-by: Tobin C. Harding thanks, Tobin.

[PATCH v3] hwmon: g762: handle cleanup with devm_add_action

Simplify code and use devm_add_action() to handle cleanup. Signed-off-by: Peng Hao --- drivers/hwmon/g762.c | 58 +--- 1 file changed, 19 insertions(+), 39 deletions(-) diff --git a/drivers/hwmon/g762.c

Re: [PATCH 1/5] staging: ks7010: Use constants from ieee80211_eid instead of literal ints.

On Wed, Feb 28, 2018 at 09:19:07PM -0800, Quytelda Kahja wrote: ... I would normally respond to the cover letter but here goes. Reviewed-by: Tobin C. Harding thanks, Tobin.

[PATCH v3] hwmon: g762: handle cleanup with devm_add_action

Simplify code and use devm_add_action() to handle cleanup. Signed-off-by: Peng Hao --- drivers/hwmon/g762.c | 58 +--- 1 file changed, 19 insertions(+), 39 deletions(-) diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c index

Re: [PATCH 1/5] staging: ks7010: Use constants from ieee80211_eid instead of literal ints.

On Wed, Feb 28, 2018 at 09:19:07PM -0800, Quytelda Kahja wrote: > The case statement in get_ap_information() should not use literal integers > to parse information element IDs when these values are provided by name > in 'enum ieee80211_eid' in the header 'linux/ieee80211.h'. Nice. Magic number

Re: [PATCH 1/5] staging: ks7010: Use constants from ieee80211_eid instead of literal ints.

On Wed, Feb 28, 2018 at 09:19:07PM -0800, Quytelda Kahja wrote: > The case statement in get_ap_information() should not use literal integers > to parse information element IDs when these values are provided by name > in 'enum ieee80211_eid' in the header 'linux/ieee80211.h'. Nice. Magic number

[PATCH v4 0/3] mm: improve zone->lock scalability

Patch 1/3 is a small cleanup suggested by Matthew Wilcox which doesn't affect scalability or performance; Patch 2/3 moves some code in free_pcppages_bulk() outside of zone->lock and has Mel Gorman's ack; Patch 3/3 uses prefetch in free_pcppages_bulk() outside of zone->lock to speedup page merging

[PATCH v4 0/3] mm: improve zone->lock scalability

Patch 1/3 is a small cleanup suggested by Matthew Wilcox which doesn't affect scalability or performance; Patch 2/3 moves some code in free_pcppages_bulk() outside of zone->lock and has Mel Gorman's ack; Patch 3/3 uses prefetch in free_pcppages_bulk() outside of zone->lock to speedup page merging

[PATCH v4 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, the zone->lock is held and then pages are chosen from PCP's migratetype list. While there is actually no need to do this 'choose part' under lock since it's PCP pages, the only CPU that can touch them is us and irq is also

[PATCH v4 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy, the zone->lock is held and then pages are chosen from PCP's migratetype list. While there is actually no need to do this 'choose part' under lock since it's PCP pages, the only CPU that can touch them is us and irq is also

[PATCH v4 3/3] mm/free_pcppages_bulk: prefetch buddy while not holding lock

When a page is freed back to the global pool, its buddy will be checked to see if it's possible to do a merge. This requires accessing buddy's page structure and that access could take a long time if it's cache cold. This patch adds a prefetch to the to-be-freed page's buddy outside of zone->lock

[PATCH v4 3/3] mm/free_pcppages_bulk: prefetch buddy while not holding lock

When a page is freed back to the global pool, its buddy will be checked to see if it's possible to do a merge. This requires accessing buddy's page structure and that access could take a long time if it's cache cold. This patch adds a prefetch to the to-be-freed page's buddy outside of zone->lock

[PATCH v4 1/3] mm/free_pcppages_bulk: update pcp->count inside

Matthew Wilcox found that all callers of free_pcppages_bulk() currently update pcp->count immediately after so it's natural to do it inside free_pcppages_bulk(). No functionality or performance change is expected from this patch. Suggested-by: Matthew Wilcox Signed-off-by:

[PATCH v4 1/3] mm/free_pcppages_bulk: update pcp->count inside

Matthew Wilcox found that all callers of free_pcppages_bulk() currently update pcp->count immediately after so it's natural to do it inside free_pcppages_bulk(). No functionality or performance change is expected from this patch. Suggested-by: Matthew Wilcox Signed-off-by: Aaron Lu ---

Re: [PATCH v4 13/24] fpga: region: add compat_id support

On Wed, Feb 28, 2018 at 04:55:15PM -0600, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, Hi Alan, Thanks for the review. > > > This patch introduces a compat_id member and sysfs interface for each > > fpga-region, e.g userspace applications

Re: [PATCH v4 13/24] fpga: region: add compat_id support

On Wed, Feb 28, 2018 at 04:55:15PM -0600, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, Hi Alan, Thanks for the review. > > > This patch introduces a compat_id member and sysfs interface for each > > fpga-region, e.g userspace applications could read the

Re: [PATCH v2] pvcalls-front: 64-bit align flags

On 01/03/18 03:05, Stefano Stabellini wrote: > We are using test_and_* operations on the status and flag fields of > struct sock_mapping. However, these functions require the operand to be > 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > > Make status and flags explicitly

Re: [PATCH v2] pvcalls-front: 64-bit align flags

On 01/03/18 03:05, Stefano Stabellini wrote: > We are using test_and_* operations on the status and flag fields of > struct sock_mapping. However, these functions require the operand to be > 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > > Make status and flags explicitly

Re: [PATCH v3 1/6] jailhouse: Provide detection for non-x86 systems

On 01/03/18 06:40, Jan Kiszka wrote: > From: Jan Kiszka > > Implement jailhouse_paravirt() via device tree probing on architectures > != x86. Will be used by the PCI core. > > CC: Rob Herring > CC: Mark Rutland > Signed-off-by:

Re: [PATCH v3 1/6] jailhouse: Provide detection for non-x86 systems

On 01/03/18 06:40, Jan Kiszka wrote: > From: Jan Kiszka > > Implement jailhouse_paravirt() via device tree probing on architectures > != x86. Will be used by the PCI core. > > CC: Rob Herring > CC: Mark Rutland > Signed-off-by: Jan Kiszka > --- >

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/18 22:35, Paolo Bonzini wrote: > On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: >> +obj-$(CONFIG_XEN_PVH) += pvh.o >> +obj-$(CONFIG_XEN_PVH) += pvh-head.o >> + > > Probably a better place for these would be > arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no > .c

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/18 22:35, Paolo Bonzini wrote: > On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: >> +obj-$(CONFIG_XEN_PVH) += pvh.o >> +obj-$(CONFIG_XEN_PVH) += pvh-head.o >> + > > Probably a better place for these would be > arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no > .c

Re: [PATCH] arm: Initialize hrtimer-based broadcast clockevent

On 2018-01-22 07:06, Jan Kiszka wrote: > Analogously to 9358d755bd5c, this registers a broadcast clockevent in > case no hardware broadcast timer is available and the per-CPU timers can > be stopped in deep power states. > > Partitions of the Jailhouse hypervisor fall in this category. >

Re: [PATCH] arm: Initialize hrtimer-based broadcast clockevent

On 2018-01-22 07:06, Jan Kiszka wrote: > Analogously to 9358d755bd5c, this registers a broadcast clockevent in > case no hardware broadcast timer is available and the per-CPU timers can > be stopped in deep power states. > > Partitions of the Jailhouse hypervisor fall in this category. >

[PATCH v5 1/3] x86/apic: Move pending intr check code into it's own function

the pending interrupt check code is mixed with the local APIC setup code, that looks messy. Extract the related code, move it into a new function named apic_pending_intr_clear(). Signed-off-by: Dou Liyang Reviewed-by: Andy Shevchenko ---

[PATCH v5 1/3] x86/apic: Move pending intr check code into it's own function

the pending interrupt check code is mixed with the local APIC setup code, that looks messy. Extract the related code, move it into a new function named apic_pending_intr_clear(). Signed-off-by: Dou Liyang Reviewed-by: Andy Shevchenko --- changelog: v4 --> v5: - Fix undeclared 'i' error

  1   2   3   4   5   6   7   8   9   10   >