Re: [PATCH v2] staging: greybus: light: Release memory obtained by kasprintf

On Fri, Sep 22, 2017 at 10:49:43AM +0530, Arvind Yadav wrote: > - Free memory region, if gb_lights_channel_config is not successful. > - No need to add check for gb_lights_channel_flash_config(). These should be separate patches. They're not related. regards, dan carpenter

Re: [PATCH v1] staging: rtl8188eu: Fix spelling

Hi Valentine, I can't quite work out the email threading of this patch. My guess is that if I cannot work it out it might get missed by Greg. Is this a new patch that you made by squashing the three patches previously submitted into one? If so, my suggestion would be to respond to this patch

[PATCH] staging: rtl8192u: Fix some error handling path

If 'rtl8192_usb_initendpoints()' fails, it may have allocated some resources that need to be freed. The corresponding is propagated up to 'rtl8192_usb_prob()'. So, in this function if an error code is returned by 'rtl8192_init()' we should call 'rtl8192_usb_deleteendpoints()'. Some error handling

[PATCH] staging: rtl8192u: Check some memory allocation failure

If one of these memory allocations fail, a NULL pointer dereference will occur later on. Return -ENOMEM instead. There is no need to free the resources already allocated, this is done by the caller (i.e. 'rtl8192_usb_probe()') which calls 'rtl8192_usb_deleteendpoints()'. The calling graph is:

[PATCH v3 13/14] 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 v3 09/14] 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 --- Changes in v2: -Adjust for new MUX_TYPEC_foo state defines -Add MAINTAINERS entry -Various code-style fixes Changes in v3: -Use

[PATCH v3 08/14] 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 v3 12/14] 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 v3 14/14] 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 Acked-by: Andy Shevchenko

[PATCH v3 10/14] 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 v3 11/14] 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 v3 07/14] 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 v3 06/14] xhci: Add option to get next extended capability in list by passing id = 0

From: Mathias Nyman Modify xhci_find_next_ext_cap(base, offset, id) to return the next capability offset if 0 is passed for id. Otherwise it will behave as previously and return the offset of the next capability with matching id capability id 0 is not used by xhci

[PATCH v3 02/14] mux: core: Add explicit hook to leave the mux as-is on init/registration

From: Peter Rosin A board may need a mux controller to stay as-is for a while longer, e.g. if setting the normally preferred idle state destroys booting. The mechanism provided here is not perfect in two ways. 1. As soon as the mux controller is registered, some mux consumer

[PATCH v3 05/14] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. 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 v3 03/14] 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 v3 04/14] 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 v3 01/14] mux: core: Add mux_control_get_optional() API

From: Stephen Boyd Sometimes drivers only use muxes under certain scenarios. For example, the chipidea usb controller may be connected to a usb switch on some platforms, and connected directly to a usb port on others. The driver won't know one way or the other though, so

RE: [PATCH] hv_netvsc: make const array ver_list static, reduces object code size

> -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Friday, September 22, 2017 8:50 AM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger ; > de...@linuxdriverproject.org;

[PATCH] hv_netvsc: make const array ver_list static, reduces object code size

From: Colin Ian King Don't populate const array ver_list on the stack, instead make it static. Makes the object code smaller by over 400 bytes: Before: textdata bss dec hex filename 184443168 320 2193255ac drivers/net/hyperv/netvsc.o

[PATCH] staging: rtl8192e: make const array broadcast_addr static, reduces object code size

From: Colin Ian King Don't populate const array broadcast_addr on the stack, instead make it static. Makes the object code smaller by over 40 bytes: Before: textdata bss dec hex filename 6390682481216 73370 11e9a rtllib_softmac.o

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

Hi, On 09/11/2017 12:56 AM, Guenter Roeck wrote: On 09/05/2017 09:42 AM, Hans de Goede wrote: 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.

Re: [PATCH] android: binder: fix type mismatch warning

On Fri, Sep 22, 2017 at 11:12 AM, Arnd Bergmann wrote: > How would waiting help? Once P drops support for v7, all P userspaces (including containerized ones) need to be v8. After a while, the number of non-Android userspaces < P with v7 would become practically zero. But it's

Re: [PATCH] staging:ccree Fix dont use assignment in if condition

A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Sep 22, 2017 at

Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: remove unneeded conversions to bool

On Fri, 22 Sep 2017, Aishwarya Pant wrote: > On Fri, Sep 22, 2017 at 11:47:44AM +0200, Julia Lawall wrote: > > > > > > On Fri, 22 Sep 2017, Aishwarya Pant wrote: > > > > > Patch suppresses the following warning issued by coccicheck: > > > WARNING: conversion to bool not needed here > > > > > >

Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: remove unneeded conversions to bool

On Fri, Sep 22, 2017 at 11:47:44AM +0200, Julia Lawall wrote: > > > On Fri, 22 Sep 2017, Aishwarya Pant wrote: > > > Patch suppresses the following warning issued by coccicheck: > > WARNING: conversion to bool not needed here > > > > Signed-off-by: Aishwarya Pant > >

Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: remove implicit bool->int conversions

On Fri, Sep 22, 2017 at 11:52:36AM +0200, Julia Lawall wrote: > > > On Fri, 22 Sep 2017, Aishwarya Pant wrote: > > > Implicit type conversions are bad; they hinder readability of code and have > > potential to cause bugs. Here the variable wait_ack is always supplied a > > bool > > value while

Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: remove implicit bool->int conversions

On Fri, 22 Sep 2017, Aishwarya Pant wrote: > Implicit type conversions are bad; they hinder readability of code and have > potential to cause bugs. Here the variable wait_ack is always supplied a bool > value while in function declarations it is defined as an int type. Fix it by > defining

Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: remove unneeded conversions to bool

On Fri, 22 Sep 2017, Aishwarya Pant wrote: > Patch suppresses the following warning issued by coccicheck: > WARNING: conversion to bool not needed here > > Signed-off-by: Aishwarya Pant Acked-by: Julia Lawall > --- >

[PATCH] staging: rtl8188eu: remove unneeded conversions to bool

Patch suppresses the following warning issued by coccicheck: WARNING: conversion to bool not needed here Signed-off-by: Aishwarya Pant --- drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH] staging: rtl8188eu: remove implicit bool->int conversions

Implicit type conversions are bad; they hinder readability of code and have potential to cause bugs. Here the variable wait_ack is always supplied a bool value while in function declarations it is defined as an int type. Fix it by defining wait_ack a bool type in all usages. Signed-off-by:

Re: [PATCH] android: binder: fix type mismatch warning

On Fri, Sep 22, 2017 at 9:00 AM, Martijn Coenen wrote: >> The case that gets interesting is a any kind of user that wants to >> run an Android application on a regular Linux box without >> using virtual machines or emulation, e.g. a an app developer, >> or a user that wants to

Re: [PATCH] staging: ccree: Fix Kernel coding style issues

On Fri, Sep 22, 2017 at 02:15:34PM +0530, kart...@techveda.org wrote: > From: Karthik Tummala > > Fixed following checkpatch warnings & checks: > CHECK: Unnecessary parentheses > WARNING: suspect code indent for conditional statements > WARNING: Missing a blank line after

Re: [PATCH] staging:ccree Fix dont use assignment in if condition

On Thu, Sep 21, 2017 at 12:07:04PM +0530, Janani Sankara Babu wrote: > This patch solves the following error shown by checkpatch script > ERROR: do not use assignment in if condition > > Signed-off-by: Janani Sankara Babu > --- > drivers/staging/ccree/ssi_hash.c | 8

[PATCH] staging: ccree: Fix Kernel coding style issues

From: Karthik Tummala Fixed following checkpatch warnings & checks: CHECK: Unnecessary parentheses WARNING: suspect code indent for conditional statements WARNING: Missing a blank line after declarations Signed-off-by: Karthik Tummala --- Note: -

Re: [Outreachy kernel] [PATCH v2] staging: vc04_services: Remove typedef struct

On Fri, 22 Sep 2017, Harsha Sharma wrote: > Remove typedef from struct as linux-kernel coding style tends to > avoid using typedefs > > Done using following coccinelle semantic patch > > @r1@ > type T; > @@ > > typedef struct { ... } T; > > @script:python c1@ > T2; > T << r1.T; > @@ > if T[-2:]

[PATCH v2] staging: vc04_services: Remove typedef struct

Remove typedef from struct as linux-kernel coding style tends to avoid using typedefs Done using following coccinelle semantic patch @r1@ type T; @@ typedef struct { ... } T; @script:python c1@ T2; T << r1.T; @@ if T[-2:] =="_t" or T[-2:] == "_T": coccinelle.T2 = T[:-2]; else:

Re: [PATCH] android: binder: fix type mismatch warning

On Wed, Sep 20, 2017 at 3:37 PM, Arnd Bergmann wrote: > I'm not really worried about shipping Android products, for those > there is no big problem using the compile-time option as they build > everything together. Ack. > The case that gets interesting is a any kind of user that

[PATCH 2/2] Drivers: hv: fcopy: restore correct transfer length

From: Olaf Hering Till recently the expected length of bytes read by the daemon did depend on the context. It was either hv_start_fcopy or hv_do_fcopy. The daemon had a buffer size of two pages, which was much larger than needed. Now the expected length of bytes read by the

[PATCH 1/2] vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister()

From: Dexuan Cui Due to commit 54a66265d675 ("Drivers: hv: vmbus: Fix rescind handling"), we need this patch to resolve the below deadlock: after we get the mutex in vmbus_hvsock_device_unregister() and call vmbus_device_unregister() -> device_unregister() -> ... ->

[PATCH 0/2] Drivers: hv: Miscellaneous fixes

From: "K. Y. Srinivasan" Miscellaneous fixes. Greg, please apply these to 4.14-final. Dexuan Cui (1): vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister() Olaf Hering (1): Drivers: hv: fcopy: restore correct transfer length drivers/hv/channel_mgmt.c | 4

Re: [PATCH v2] [media] staging: atomisp: use clock framework for camera clocks

Hi Pierre-Louis, On Wed, Sep 20, 2017 at 03:53:58PM -0500, Pierre-Louis Bossart wrote: > The Atom ISP driver initializes and configures PMC clocks which are > already handled by the clock framework. > > Remove all legacy vlv2_platform_clock stuff and move to the clk API to > avoid conflicts,

[PATCH] [media] atomisp2: remove cast from memory allocation

Patch removes the following warning issued was coccicheck: WARNING: casting value returned by memory allocation function to (char *) is useless. Signed-off-by: Aishwarya Pant --- drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 4 ++-- 1 file changed, 2