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
___
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 yo
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
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:
rtl
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: devicet...@vger.kernel.org
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 new init_as_is mux fl
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 me
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
---
Changes in v3:
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
---
drivers/platform/x86/Kconfig
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
han
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
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.
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 (reserved)
This is useful when
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 can
access it and
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 f
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
---
Changes in v2:
-Start numb
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 cont
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 add
a mux_control_get_opt
> -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; net...@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.
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
After:
textdata
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
After:
textdata bss
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.
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 really
hard to draw
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 03:
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
> > >
> > > S
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
>
> Acked-by: Julia Lawall
D
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
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 wait_
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
> ---
> drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 8
> 1 file chan
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 a/drivers/staging/rtl8188eu/core/rtw_
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: Aishwar
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 run some Android ap
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 declarations
Hi,
This
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
> 1 file changed, 4
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:
- Patch was tested & built (ARCH=arm) on staging,
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:]
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:
c
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 wants to
> run a
38 matches
Mail list logo
