[PATCH 0/2] Add a devm_of_clk_add_hw_provider() API

This cleans up some open-coded versions of this API and makes it official. It's also another carrot to convert drivers to use the clk hw registration APIs instead of the clk registration APIs. Stephen Boyd (2): clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs clk: qcom: common:

[PATCH 0/2] Add a devm_of_clk_add_hw_provider() API

This cleans up some open-coded versions of this API and makes it official. It's also another carrot to convert drivers to use the clk hw registration APIs instead of the clk registration APIs. Stephen Boyd (2): clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs clk: qcom: common:

[PATCH 1/2] clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs

Sometimes we only have one of_clk_del_provider() call in driver error and remove paths, because we're missing a devm_of_clk_add_hw_provider() API. Introduce the API so we can convert drivers to use this and potentially reduce the amount of code needed to remove providers in drivers.

[PATCH 1/2] clk: Add devm_of_clk_add_hw_provider()/del_provider() APIs

Sometimes we only have one of_clk_del_provider() call in driver error and remove paths, because we're missing a devm_of_clk_add_hw_provider() API. Introduce the API so we can convert drivers to use this and potentially reduce the amount of code needed to remove providers in drivers.

[PATCH 2/2] clk: qcom: common: Migrate to devm_* APIs for resets and clk providers

Now that we have devm APIs for the reset controller and of clk hw provider APIs we can remove the custom code here. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/common.c | 26 ++ 1 file changed, 2 insertions(+), 24 deletions(-) diff --git

[PATCH 2/2] clk: qcom: common: Migrate to devm_* APIs for resets and clk providers

Now that we have devm APIs for the reset controller and of clk hw provider APIs we can remove the custom code here. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/common.c | 26 ++ 1 file changed, 2 insertions(+), 24 deletions(-) diff --git a/drivers/clk/qcom/common.c

Re: [PATCH 24/31] mips/sgi-ip22: Use separate static data field with with static timer

Acked-by: Ralf Baechle Ralf

Re: [PATCH 24/31] mips/sgi-ip22: Use separate static data field with with static timer

Acked-by: Ralf Baechle Ralf

Re: [PATCH v5 1/7] clk: at91: clk-generated: remove useless divisor loop

On 08/10, Quentin Schulz wrote: > The driver requests the current clk rate of each of its parent clocks to > decide whether a clock rate is suitable or not. It does not request > determine_rate from a parent clock which could request a rate change in > parent clock (i.e. there is no parent rate

Re: [PATCH v5 1/7] clk: at91: clk-generated: remove useless divisor loop

On 08/10, Quentin Schulz wrote: > The driver requests the current clk rate of each of its parent clocks to > decide whether a clock rate is suitable or not. It does not request > determine_rate from a parent clock which could request a rate change in > parent clock (i.e. there is no parent rate

Re: [PATCH 23/31] mips/sgi-ip32: Use separate static data field with with static timer

Acked-by: Ralf Baechle Ralf

Re: [PATCH v5 3/7] clk: at91: add audio pll clock drivers

On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can

Re: [PATCH 23/31] mips/sgi-ip32: Use separate static data field with with static timer

Acked-by: Ralf Baechle Ralf

Re: [PATCH v5 3/7] clk: at91: add audio pll clock drivers

On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can

Re: [PATCH v5 6/7] ASoC: atmel-classd: remove aclk clock from DT binding

On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > This binding is used by no board in mainline so it is safe to be >

Re: [PATCH v5 6/7] ASoC: atmel-classd: remove aclk clock from DT binding

On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > This binding is used by no board in mainline so it is safe to be >

Re: [PATCH v5 4/7] clk: at91: clk-generated: create function to find best_diff

On 08/10, Quentin Schulz wrote: > The way to find the best_diff and do the appropriate process afterwards > can be re-used. > > This patch prepares the driver for an upcoming patch that will allow > clk_generated to determine the rate of the audio_pll. > > Signed-off-by: Quentin Schulz

Re: [PATCH v5 7/7] ASoC: atmel-classd: remove aclk clock

On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > Thus, remove all mentions to aclk in classd driver and update

Re: [PATCH v5 4/7] clk: at91: clk-generated: create function to find best_diff

On 08/10, Quentin Schulz wrote: > The way to find the best_diff and do the appropriate process afterwards > can be re-used. > > This patch prepares the driver for an upcoming patch that will allow > clk_generated to determine the rate of the audio_pll. > > Signed-off-by: Quentin Schulz >

Re: [PATCH v5 7/7] ASoC: atmel-classd: remove aclk clock

On 08/10, Quentin Schulz wrote: > Since gclk (generated-clk) is now able to determine the rate of the > audio_pll, there is no need for classd to have a direct phandle to the > audio_pll while already having a phandle to gclk. > > Thus, remove all mentions to aclk in classd driver and update

Re: [PATCH v5 2/7] dt-bindings: clk: at91: add audio plls to the compatible list

On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can

Re: [PATCH v5 5/7] clk: at91: clk-generated: make gclk determine audio_pll rate

On 08/10, Quentin Schulz wrote: > This allows gclk to determine audio_pll rate and set the parent rate > accordingly. > > However, there are multiple children clocks that could technically > change the rate of audio_pll (via gck). With the rate locking, the first > consumer to enable the clock

Re: [PATCH v5 2/7] dt-bindings: clk: at91: add audio plls to the compatible list

On 08/10, Quentin Schulz wrote: > This new clock driver set allows to have a fractional divided clock that > would generate a precise clock particularly suitable for audio > applications. > > The main audio pll clock has two children clocks: one that is connected > to the PMC, the other that can

Re: [PATCH v5 5/7] clk: at91: clk-generated: make gclk determine audio_pll rate

On 08/10, Quentin Schulz wrote: > This allows gclk to determine audio_pll rate and set the parent rate > accordingly. > > However, there are multiple children clocks that could technically > change the rate of audio_pll (via gck). With the rate locking, the first > consumer to enable the clock

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: I was trying to avoid mixing early and no-early set_memory_decrypted() but if feedback is: use early_set_memory_decrypted() only if its required otherwise use

Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: I was trying to avoid mixing early and no-early set_memory_decrypted() but if feedback is: use early_set_memory_decrypted() only if its required otherwise use

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

Peter Zijlstra wrote: > if (obj) { > /* use obj */ > refcount_dec(>refs); /* should never hit 0 */ > } You've missed a bit: We need to tell the gc to run when we reduce the refcount to 1: if (obj) { ...

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

Peter Zijlstra wrote: > if (obj) { > /* use obj */ > refcount_dec(>refs); /* should never hit 0 */ > } You've missed a bit: We need to tell the gc to run when we reduce the refcount to 1: if (obj) { ... if

Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

On 01/09/17 07:04, Maxime Ripard wrote: > On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote: >> Hi, >> >> On 31/08/17 00:36, Stefan Brüns wrote: >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a >>> reduced amount of physical channels. Add the proper config data >>>

Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

On 01/09/17 07:04, Maxime Ripard wrote: > On Fri, Sep 01, 2017 at 01:31:35AM +0100, Andre Przywara wrote: >> Hi, >> >> On 31/08/17 00:36, Stefan Brüns wrote: >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a >>> reduced amount of physical channels. Add the proper config data >>>

Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

Hi, On 01/09/17 02:19, Stefan Bruens wrote: > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote: >> Hi, >> >> On 31/08/17 00:36, Stefan Brüns wrote: >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a >>> reduced amount of physical channels. Add the proper config data

Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64

Hi, On 01/09/17 02:19, Stefan Bruens wrote: > On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote: >> Hi, >> >> On 31/08/17 00:36, Stefan Brüns wrote: >>> The A64 SoC has the same dma engine as the H3 (sun8i), with a >>> reduced amount of physical channels. Add the proper config data

kmemleak not always catching stuff

Hi, Recently kmemleak discovered a bug in my code where an allocated trampoline for a ftrace function tracer wasn't freed due to an exit path. The thing is, kmemleak was able to catch this 100% when it was triggered by one of my ftrace selftests that happen at bootup. But when I trigger the issue

kmemleak not always catching stuff

Hi, Recently kmemleak discovered a bug in my code where an allocated trampoline for a ftrace function tracer wasn't freed due to an exit path. The thing is, kmemleak was able to catch this 100% when it was triggered by one of my ftrace selftests that happen at bootup. But when I trigger the issue

[rcu:rcu/next 27/27] kernel/rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU stall warnings while dumping trace config: i386-randconfig-x000-201735 (attached

[rcu:rcu/next 27/27] kernel/rcu/rcu.h:225:8: error: 'rcu_cpu_stall_suppress' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU stall warnings while dumping trace config: i386-randconfig-x000-201735 (attached

Re: [PATCH] DSA support for Micrel KSZ8895

On 09/01/2017 05:15 AM, Pavel Machek wrote: > Hi! > > On Wed 2017-08-30 21:32:07, tristram...@microchip.com wrote: >>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote: > I may be confused here, but AFAICT: > > 1) Yes, it has standard layout when accessed over MDIO.

Re: [PATCH] DSA support for Micrel KSZ8895

On 09/01/2017 05:15 AM, Pavel Machek wrote: > Hi! > > On Wed 2017-08-30 21:32:07, tristram...@microchip.com wrote: >>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote: > I may be confused here, but AFAICT: > > 1) Yes, it has standard layout when accessed over MDIO.

[rcu:rcu/next 27/27] kernel//rcu/rcutorture.c:1124:3: note: in expansion of macro 'rcu_ftrace_dump'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU stall warnings while dumping trace config: x86_64-randconfig-x016-201735

[rcu:rcu/next 27/27] kernel//rcu/rcutorture.c:1124:3: note: in expansion of macro 'rcu_ftrace_dump'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 commit: 909bd6e3d9e73fd0ca1d6255466573d4c3fbe321 [27/27] rcu: Suppress RCU CPU stall warnings while dumping trace config: x86_64-randconfig-x016-201735

Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup

On Fri 01 Sep 13:47 PDT 2017, Marcel Holtmann wrote: > Hi Bjorn, > > > Bluetooth BD address can be retrieved in the same way as > > for wcnss-wlan MAC address. This patch mainly stores the > > local-mac-address property and sets the BD address during > > hci device setup. > > > > Signed-off-by:

Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup

On Fri 01 Sep 13:47 PDT 2017, Marcel Holtmann wrote: > Hi Bjorn, > > > Bluetooth BD address can be retrieved in the same way as > > for wcnss-wlan MAC address. This patch mainly stores the > > local-mac-address property and sets the BD address during > > hci device setup. > > > > Signed-off-by:

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

On Fri, Sep 01, 2017 at 11:50:03PM +0200, Peter Zijlstra wrote: > > Did you read the other other part of the description? > > > > Further, both functions can be used to accurately trace the refcount > > (refcount_inc() followed by refcount_read() can't be considered > > accurate). >

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

On Fri, Sep 01, 2017 at 11:50:03PM +0200, Peter Zijlstra wrote: > > Did you read the other other part of the description? > > > > Further, both functions can be used to accurately trace the refcount > > (refcount_inc() followed by refcount_read() can't be considered > > accurate). >

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 09/01/2017 11:19 AM, Mika Westerberg wrote: On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 09/01/2017 11:19 AM, Mika Westerberg wrote: On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: +int

RE: [PATCH][staging-next] staging: unisys: visorbus: make two functions static

> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Friday, September 1, 2017 6:08 AM > To: Greg Kroah-Hartman ; Sell, Timothy C > ; Binder, David Anthony > ; Wadgaonkar, Sameer

RE: [PATCH][staging-next] staging: unisys: visorbus: make two functions static

> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Friday, September 1, 2017 6:08 AM > To: Greg Kroah-Hartman ; Sell, Timothy C > ; Binder, David Anthony > ; Wadgaonkar, Sameer Laxmikant > ; Charles Daniels > ; Andy Shevchenko > ; *S-Par-Maintainer > ;

[PATCH v2] mux: core: Fix double get_device()

class_find_device already does a get_device on the returned device. So the device returned by of_find_mux_chip_by_node is already referenced and we should not reference it again (and unref it on error). Also rename of_find_mux_chip_by_node to of_get_mux_chip_by_node to make it clear that it

[PATCH v2] mux: core: Fix double get_device()

class_find_device already does a get_device on the returned device. So the device returned by of_find_mux_chip_by_node is already referenced and we should not reference it again (and unref it on error). Also rename of_find_mux_chip_by_node to of_get_mux_chip_by_node to make it clear that it

[PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code to add entries to a lookup table and then use this table to look things up. This commit adds support for getting a mux

[PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code to add entries to a lookup table and then use this table to look things up. This commit adds support for getting a mux

[PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

The Intel cherrytrail xhci controller has an extended cap mmio-range which contains registers to control the muxing to the xhci (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a mux driver included in the xhci code (or under drivers/usb/host) is not desirable.

[PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

The Intel cherrytrail xhci controller has an extended cap mmio-range which contains registers to control the muxing to the xhci (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a mux driver included in the xhci code (or under drivers/usb/host) is not desirable.

[PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede --- drivers/mux/Kconfig | 10 + drivers/mux/Makefile | 2 + drivers/mux/pi3usb30532.c | 97

[PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede --- drivers/mux/Kconfig | 10 + drivers/mux/Makefile | 2 + drivers/mux/pi3usb30532.c | 97

[PATCH 07/11] extcon: intel-int3496: Add support for controlling the USB-role mux

Cherry Trail SoCs have a built-in USB-role mux for switching between the host and device controllers, rather then using an external mux controller by a GPIO. There is a driver using the mux-subsys to control this mux, this commit adds support to the intel-int3496 driver to get a mux_controller

[PATCH 07/11] extcon: intel-int3496: Add support for controlling the USB-role mux

Cherry Trail SoCs have a built-in USB-role mux for switching between the host and device controllers, rather then using an external mux controller by a GPIO. There is a driver using the mux-subsys to control this mux, this commit adds support to the intel-int3496 driver to get a mux_controller

[PATCH 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede

[PATCH 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede ---

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

On Fri, Sep 01, 2017 at 10:15:39PM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > > unsigned int refcount_dec_return(refcount_t *r); > > > unsigned int refcount_inc_return(refcount_t *r); > > > > > > > I'm not immediately seeing how wanting 1 to mean unused

Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions

On Fri, Sep 01, 2017 at 10:15:39PM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > > unsigned int refcount_dec_return(refcount_t *r); > > > unsigned int refcount_inc_return(refcount_t *r); > > > > > > > I'm not immediately seeing how wanting 1 to mean unused leads to > >

[PATCH 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic tcpc_mux_dev code in our devicetree bindings. Cc: Rob Herring Cc: Mark Rutland

[PATCH 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic tcpc_mux_dev code in our devicetree bindings. Cc: Rob Herring Cc: Mark Rutland Cc:

[PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede --- drivers/platform/x86/Kconfig | 1

[PATCH 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

Setting the mux to TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT when the data-role is device is not correct. Plenty of devices support operating as USB device through a (separate) USB device controller. So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST and TYPEC_MUX_USB_DEVICE

[PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede --- drivers/platform/x86/Kconfig | 1 +

[PATCH 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

Setting the mux to TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT when the data-role is device is not correct. Plenty of devices support operating as USB device through a (separate) USB device controller. So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST and TYPEC_MUX_USB_DEVICE

[PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some Cherrytrail systems this mux is controlled through AML code reacting on a GPIO IRQ connected to the USB OTG id pin (through an _AIE ACPI

[PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some Cherrytrail systems this mux is controlled through AML code reacting on a GPIO IRQ connected to the USB OTG id pin (through an _AIE ACPI

[PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux drivers 3) Hookup the Intel CHT USB mux driver for CHT

[PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux drivers 3) Hookup the Intel CHT USB mux driver for CHT

[PATCH 01/11] mux: core: Add of_mux_control_get helper function

Currently the mux_control_get implementation only deals with getting mux controllers on DT platforms. This commit renames the current implementation to of_mux_control_get to reflect this and makes mux_control_get a wrapper around of_mux_control_get. This is a preparation patch for adding support

[PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede ---

[PATCH 01/11] mux: core: Add of_mux_control_get helper function

Currently the mux_control_get implementation only deals with getting mux controllers on DT platforms. This commit renames the current implementation to of_mux_control_get to reflect this and makes mux_control_get a wrapper around of_mux_control_get. This is a preparation patch for adding support

[PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede --- include/linux/mux/consumer.h | 16

Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

On 1 September 2017 at 21:22, Kees Cook wrote: > Using .text.unlikely for refcount exceptions isn't safe because gcc may > move entire functions into .text.unlikely (e.g. in6_dev_get()), which > would cause any uses of a protected refcount_t function to stay inline > with

Re: [PATCH] locking/refcounts, x86/asm: Use unique .text section for refcount exceptions

On 1 September 2017 at 21:22, Kees Cook wrote: > Using .text.unlikely for refcount exceptions isn't safe because gcc may > move entire functions into .text.unlikely (e.g. in6_dev_get()), which > would cause any uses of a protected refcount_t function to stay inline > with the function, triggering

[PULL REQUEST] i2c for 4.13

Linus, I2C has two bugfixes for you: the ismt driver had a problem with a rarely used transaction type and the designware driver was made even more robust against non standard ACPI tables. Please pull. Thanks, Wolfram The following changes since commit

[PULL REQUEST] i2c for 4.13

Linus, I2C has two bugfixes for you: the ismt driver had a problem with a rarely used transaction type and the designware driver was made even more robust against non standard ACPI tables. Please pull. Thanks, Wolfram The following changes since commit

RE: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:44 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux-

RE: [PATCH 5/9] ASoC: max98927: Removed obsolete variables

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:54 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux-

RE: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:44 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org;

RE: [PATCH 5/9] ASoC: max98927: Removed obsolete variables

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Thursday, August 31, 2017 4:54 AM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org;

RE: [PATCH 1/9] ASoC: max98927: Added support for DSP_A and DSP_B format

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Tuesday, August 29, 2017 12:00 PM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux-

RE: [PATCH 1/9] ASoC: max98927: Added support for DSP_A and DSP_B format

>-Original Message- >From: Mark Brown [mailto:broo...@kernel.org] >Sent: Tuesday, August 29, 2017 12:00 PM >To: Ryan Lee >Cc: lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.com; >kuninori.morimoto...@renesas.com; alsa-de...@alsa-project.org; linux- >ker...@vger.kernel.org;

[PATCH 1/3] ASoC: max98927: Added support for DSP_A and DSP_B format

Signed-off-by: Ryan Lee --- Changelog: Added support for DSP_A and DSP_B format Added 'max98927_dai_tdm_slot' function to configure for proper slot configuration. Moved max98927->iface out of switch statement to avoid line duplication.

[PATCH 1/3] ASoC: max98927: Added support for DSP_A and DSP_B format

Signed-off-by: Ryan Lee --- Changelog: Added support for DSP_A and DSP_B format Added 'max98927_dai_tdm_slot' function to configure for proper slot configuration. Moved max98927->iface out of switch statement to avoid line duplication. Added variable 'tdm_mode' to avoid

Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings

On Fri, 1 Sep 2017 14:30:03 -0700 Haiyang Zhang wrote: > From: Haiyang Zhang > > This patch set cleans up some unused variables, unnecessary checks. > Also fixed some limit checking of channel number. > > > Haiyang Zhang (4): >

Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings

On Fri, 1 Sep 2017 14:30:03 -0700 Haiyang Zhang wrote: > From: Haiyang Zhang > > This patch set cleans up some unused variables, unnecessary checks. > Also fixed some limit checking of channel number. > > > Haiyang Zhang (4): > hv_netvsc: Clean up an unused parameter in

[PATCH 2/3] ASoC: max98927: Added controls for Envelope tracking

Signed-off-by: Ryan Lee --- Changelog: Added one control to set different headroom value for envelop tracking function. Added one more control to enable/disable envelop tracking function. Removed writing process to register 0x0087 because it is read

[PATCH 3/3] ASoC: max98927: Removed obsolete variables

Signed-off-by: Ryan Lee --- Changelog: Removed obsolete variables that have never been referred from driver before. sound/soc/codecs/max98927.h | 4 1 file changed, 4 deletions(-) diff --git a/sound/soc/codecs/max98927.h

[PATCH 2/3] ASoC: max98927: Added controls for Envelope tracking

Signed-off-by: Ryan Lee --- Changelog: Added one control to set different headroom value for envelop tracking function. Added one more control to enable/disable envelop tracking function. Removed writing process to register 0x0087 because it is read only register.

[PATCH 3/3] ASoC: max98927: Removed obsolete variables

Signed-off-by: Ryan Lee --- Changelog: Removed obsolete variables that have never been referred from driver before. sound/soc/codecs/max98927.h | 4 1 file changed, 4 deletions(-) diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h index 98b5f17..d215f60 100644

Re: [PATCH 31/31] timer: Switch to testing for .function instead of .data

On Thu, 2017-08-31 at 16:29 -0700, Kees Cook wrote: > In several places, .data is checked for initialization to gate early > calls to del_timer_sync(). Checking for .function is equally valid, > so > switch to this in all callers. > > Cc: "Rafael J. Wysocki" > Cc: Pavel

Re: [PATCH 31/31] timer: Switch to testing for .function instead of .data

On Thu, 2017-08-31 at 16:29 -0700, Kees Cook wrote: > In several places, .data is checked for initialization to gate early > calls to del_timer_sync(). Checking for .function is equally valid, > so > switch to this in all callers. > > Cc: "Rafael J. Wysocki" > Cc: Pavel Machek > Cc: Len Brown

[PATCH 6/6] x86/platform/intel-mid: Use ARRAY_SIZE macro

Found by a coccinelle run with: make coccicheck MODE=patch COCCI=scripts/coccinelle/misc/array_size.cocci Signed-off-by: Thomas Meyer --- arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 6/6] x86/platform/intel-mid: Use ARRAY_SIZE macro

Found by a coccinelle run with: make coccicheck MODE=patch COCCI=scripts/coccinelle/misc/array_size.cocci Signed-off-by: Thomas Meyer --- arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH net-next, 3/4] hv_netvsc: Simplify the limit check in netvsc_set_channels()

From: Haiyang Zhang Because of the following code, net->num_tx_queues equals to VRSS_CHANNEL_MAX, and max_chn is less than or equals to VRSS_CHANNEL_MAX. netvsc_drv.c: alloc_etherdev_mq(sizeof(struct net_device_context), VRSS_CHANNEL_MAX);

[PATCH net-next, 3/4] hv_netvsc: Simplify the limit check in netvsc_set_channels()

From: Haiyang Zhang Because of the following code, net->num_tx_queues equals to VRSS_CHANNEL_MAX, and max_chn is less than or equals to VRSS_CHANNEL_MAX. netvsc_drv.c: alloc_etherdev_mq(sizeof(struct net_device_context), VRSS_CHANNEL_MAX); rndis_filter.c:

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