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 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 app on their desktop > using anbox. I don't think the binder driver is present on any regular Linux box, so things like anbox actually have to provide it as a module. It looks like the current version of anbox is actually using the v8 interface, and is also using a modified version of the binder driver (eg for dkms, but also other hacks). The other popular one is Shashlik, but looks like it uses a VM (just for binder). The v7 interface doesn't work on 64-bit machines at all, so any container userspace using v7 would be seriously limiting the number of machines it could be run on, whereas v8 runs on both 32 and 64. So I'm not sure we have to be concerned about things like this, certainly if we have communicated earlier (as Greg said) that binder shouldn't be used outside Android pre 4.14. > The scenario I had in mind is like this: Thanks for clarifying! I think this works, but it's additional code to maintain and support for a pretty rare (and unsupported?) scenario. I understand that hiding ABI behind a config option is not a good design, and that it must be removed. If we really can't remove v7 from 4.14, I would actually prefer to leave the config option (but flip the default to v8), and remove it as soon as we think it can be (eg once P has been in the field for a while). Thanks, Martijn ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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:
coccinelle.T2 = T;
print T, coccinelle.T2
@r2@
type r1.T;
identifier c1.T2;
@@
-typedef
struct
+ T2
{ ... }
-T
;
@r3@
type r1.T;
identifier c1.T2;
@@
-T
+struct T2
Signed-off-by: Harsha Sharma
---
Changes in v2:
-Convert structure name to lowercase
.../vc04_services/interface/vchiq_arm/vchiq_shim.c | 44 +++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 8af95fc..2c09d5e 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -41,14 +41,14 @@
#define vchiq_status_to_vchi(status) ((int32_t)status)
-typedef struct {
+struct shim_service {
VCHIQ_SERVICE_HANDLE_T handle;
VCHIU_QUEUE_T queue;
VCHI_CALLBACK_T callback;
void *callback_param;
-} SHIM_SERVICE_T;
+};
/* --
* return pointer to the mphi message driver function table
@@ -99,7 +99,7 @@ int32_t vchi_msg_peek(VCHI_SERVICE_HANDLE_T handle,
uint32_t *msg_size,
VCHI_FLAGS_T flags)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_HEADER_T *header;
WARN_ON((flags != VCHI_FLAGS_NONE) &&
@@ -131,7 +131,7 @@ int32_t vchi_msg_peek(VCHI_SERVICE_HANDLE_T handle,
***/
int32_t vchi_msg_remove(VCHI_SERVICE_HANDLE_T handle)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_HEADER_T *header;
header = vchiu_queue_pop(&service->queue);
@@ -163,7 +163,7 @@ int32_t vchi_msg_queue(VCHI_SERVICE_HANDLE_T handle,
void *context,
uint32_t data_size)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_STATUS_T status;
while (1) {
@@ -262,7 +262,7 @@ int32_t vchi_bulk_queue_receive(VCHI_SERVICE_HANDLE_T
handle,
VCHI_FLAGS_T flags,
void *bulk_handle)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_BULK_MODE_T mode;
VCHIQ_STATUS_T status;
@@ -322,7 +322,7 @@ int32_t vchi_bulk_queue_transmit(VCHI_SERVICE_HANDLE_T
handle,
VCHI_FLAGS_T flags,
void *bulk_handle)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_BULK_MODE_T mode;
VCHIQ_STATUS_T status;
@@ -384,7 +384,7 @@ int32_t vchi_msg_dequeue(VCHI_SERVICE_HANDLE_T handle,
uint32_t *actual_msg_size,
VCHI_FLAGS_T flags)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_HEADER_T *header;
WARN_ON((flags != VCHI_FLAGS_NONE) &&
@@ -458,7 +458,7 @@ int32_t vchi_msg_hold(VCHI_SERVICE_HANDLE_T handle,
VCHI_FLAGS_T flags,
VCHI_HELD_MSG_T *message_handle)
{
- SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
+ struct shim_service *service = (struct shim_service *)handle;
VCHIQ_HEADER_T *header;
WARN_ON((flags != VCHI_FLAGS_NONE) &&
@@ -579,8 +579,8 @@ int32_t vchi_disconnect(VCHI_INSTANCE_T instance_handle)
static VCHIQ_STATUS_T shim_callback(VCHIQ_REASON_T reason,
VCHIQ_HEADER_T *header, VCHIQ_SERVICE_HANDLE_T handle, void *bulk_user)
{
- SHIM_SERVICE_T *service =
- (SHIM_SERVICE_T *)VCHIQ_GET_SERVICE_USERDATA(handle);
+ struct shim_service *service =
+ (struct shim_service *)VCHIQ_GET_SERVICE_USERDATA(handle);
if (!service->callback)
goto release;
@@ -637,10 +637,10 @@ static VCHIQ_STATUS_T shim_callback(VCHIQ_REASON_T reason,
return VCHIQ_SUCCESS;
}
-static SHIM_SERVICE_T *service_alloc(VCHIQ_INSTANCE_T instance,
+static struct shim_service *service_alloc(VCHIQ_INSTANCE_T instance,
SERVICE_CREATION_T *setup)
{
- SHIM_SERVICE_T *service = kzalloc(sizeof(SHIM_SERVICE_T), GFP_KERNEL);
+ struct shim_service *service = kzalloc(sizeof(struct shim_service),
GFP_KERNEL);
(void)instance;
@@ -657,7 +657,7 @@ static SHIM_SERVICE_T *service_alloc(VCHIQ_INSTANCE_T
instance,
return service;
}
-static void service_free(SHIM_SERVICE_T *servic
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:] =="_t" or T[-2:] == "_T":
> coccinelle.T2 = T[:-2];
> else:
> coccinelle.T2 = T;
>
> print T, coccinelle.T2
>
> @r2@
> type r1.T;
> identifier c1.T2;
> @@
> -typedef
> struct
> + T2
> { ... }
> -T
> ;
>
> @r3@
> type r1.T;
> identifier c1.T2;
> @@
> -T
> +struct T2
>
> Signed-off-by: Harsha Sharma
Acked-by: Julia Lawall
> ---
> Changes in v2:
> -Convert structure name to lowercase
>
> .../vc04_services/interface/vchiq_arm/vchiq_shim.c | 44
> +++---
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> index 8af95fc..2c09d5e 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
> @@ -41,14 +41,14 @@
>
> #define vchiq_status_to_vchi(status) ((int32_t)status)
>
> -typedef struct {
> +struct shim_service {
> VCHIQ_SERVICE_HANDLE_T handle;
>
> VCHIU_QUEUE_T queue;
>
> VCHI_CALLBACK_T callback;
> void *callback_param;
> -} SHIM_SERVICE_T;
> +};
>
> /* --
> * return pointer to the mphi message driver function table
> @@ -99,7 +99,7 @@ int32_t vchi_msg_peek(VCHI_SERVICE_HANDLE_T handle,
> uint32_t *msg_size,
> VCHI_FLAGS_T flags)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_HEADER_T *header;
>
> WARN_ON((flags != VCHI_FLAGS_NONE) &&
> @@ -131,7 +131,7 @@ int32_t vchi_msg_peek(VCHI_SERVICE_HANDLE_T handle,
> ***/
> int32_t vchi_msg_remove(VCHI_SERVICE_HANDLE_T handle)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_HEADER_T *header;
>
> header = vchiu_queue_pop(&service->queue);
> @@ -163,7 +163,7 @@ int32_t vchi_msg_queue(VCHI_SERVICE_HANDLE_T handle,
> void *context,
> uint32_t data_size)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_STATUS_T status;
>
> while (1) {
> @@ -262,7 +262,7 @@ int32_t vchi_bulk_queue_receive(VCHI_SERVICE_HANDLE_T
> handle,
> VCHI_FLAGS_T flags,
> void *bulk_handle)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_BULK_MODE_T mode;
> VCHIQ_STATUS_T status;
>
> @@ -322,7 +322,7 @@ int32_t vchi_bulk_queue_transmit(VCHI_SERVICE_HANDLE_T
> handle,
> VCHI_FLAGS_T flags,
> void *bulk_handle)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_BULK_MODE_T mode;
> VCHIQ_STATUS_T status;
>
> @@ -384,7 +384,7 @@ int32_t vchi_msg_dequeue(VCHI_SERVICE_HANDLE_T handle,
> uint32_t *actual_msg_size,
> VCHI_FLAGS_T flags)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_HEADER_T *header;
>
> WARN_ON((flags != VCHI_FLAGS_NONE) &&
> @@ -458,7 +458,7 @@ int32_t vchi_msg_hold(VCHI_SERVICE_HANDLE_T handle,
> VCHI_FLAGS_T flags,
> VCHI_HELD_MSG_T *message_handle)
> {
> - SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
> + struct shim_service *service = (struct shim_service *)handle;
> VCHIQ_HEADER_T *header;
>
> WARN_ON((flags != VCHI_FLAGS_NONE) &&
> @@ -579,8 +579,8 @@ int32_t vchi_disconnect(VCHI_INSTANCE_T instance_handle)
> static VCHIQ_STATUS_T shim_callback(VCHIQ_REASON_T reason,
> VCHIQ_HEADER_T *header, VCHIQ_SERVICE_HANDLE_T handle, void *bulk_user)
> {
> - SHIM_SERVICE_T *service =
> - (SHIM_SERVICE_T *)VCHIQ_GET_SERVICE_USERDATA(handle);
> + struct shim_service *service =
> + (struct shim_service *)VCHIQ_GET_SERVICE_USERDATA(handle);
>
> if (!service->callback)
> goto release;
> @@ -637,10 +637,10 @@ static VCHIQ_STATUS_T shim_callback(VCHIQ_REASON_T
> reason,
> return VCHIQ_SUCCESS;
> }
>
> -static SHIM_SERVICE_T *service_alloc(VCHIQ_INSTANCE_T instance,
> +static struct shim_service *service_alloc(VCHIQ_INSTANCE_T instance,
> SERVICE_CREATION_T *setup)
> {
> - SHIM_SERVICE_T *service = kzalloc(sizeof(SHIM_SERVICE_T), GFP_KERNEL);
> + struct shim_service *service =
[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:
- Patch was tested & built (ARCH=arm) on staging, next trees.
- No build issues reported.
---
drivers/staging/ccree/ssi_cipher.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index a462075..24dbe98 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -76,18 +76,18 @@ static int validate_keys_sizes(struct ssi_ablkcipher_ctx
*ctx_p, u32 size)
switch (size) {
case CC_AES_128_BIT_KEY_SIZE:
case CC_AES_192_BIT_KEY_SIZE:
- if (likely((ctx_p->cipher_mode != DRV_CIPHER_XTS) &&
- (ctx_p->cipher_mode != DRV_CIPHER_ESSIV) &&
- (ctx_p->cipher_mode !=
DRV_CIPHER_BITLOCKER)))
+ if (likely(ctx_p->cipher_mode != DRV_CIPHER_XTS &&
+ ctx_p->cipher_mode != DRV_CIPHER_ESSIV &&
+ ctx_p->cipher_mode != DRV_CIPHER_BITLOCKER))
return 0;
break;
case CC_AES_256_BIT_KEY_SIZE:
return 0;
case (CC_AES_192_BIT_KEY_SIZE * 2):
case (CC_AES_256_BIT_KEY_SIZE * 2):
- if (likely((ctx_p->cipher_mode == DRV_CIPHER_XTS) ||
- (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) ||
- (ctx_p->cipher_mode ==
DRV_CIPHER_BITLOCKER)))
+ if (likely(ctx_p->cipher_mode == DRV_CIPHER_XTS ||
+ ctx_p->cipher_mode == DRV_CIPHER_ESSIV ||
+ ctx_p->cipher_mode == DRV_CIPHER_BITLOCKER))
return 0;
break;
default:
@@ -115,8 +115,8 @@ static int validate_data_size(struct ssi_ablkcipher_ctx
*ctx_p, unsigned int siz
case S_DIN_to_AES:
switch (ctx_p->cipher_mode) {
case DRV_CIPHER_XTS:
- if ((size >= SSI_MIN_AES_XTS_SIZE) &&
- (size <= SSI_MAX_AES_XTS_SIZE) &&
+ if (size >= SSI_MIN_AES_XTS_SIZE &&
+ size <= SSI_MAX_AES_XTS_SIZE &&
IS_ALIGNED(size, AES_BLOCK_SIZE))
return 0;
break;
@@ -140,7 +140,7 @@ static int validate_data_size(struct ssi_ablkcipher_ctx
*ctx_p, unsigned int siz
break;
case S_DIN_to_DES:
if (likely(IS_ALIGNED(size, DES_BLOCK_SIZE)))
- return 0;
+ return 0;
break;
#if SSI_CC_HAS_MULTI2
case S_DIN_to_MULTI2:
@@ -337,9 +337,9 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
return -EINVAL;
}
- if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) ||
- (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) ||
- (ctx_p->cipher_mode == DRV_CIPHER_BITLOCKER)) {
+ if (ctx_p->cipher_mode == DRV_CIPHER_XTS ||
+ ctx_p->cipher_mode == DRV_CIPHER_ESSIV ||
+ ctx_p->cipher_mode == DRV_CIPHER_BITLOCKER) {
if (unlikely(hki->hw_key1 == hki->hw_key2)) {
SSI_LOG_ERR("Illegal hw key numbers (%d,%d)\n",
hki->hw_key1, hki->hw_key2);
return -EINVAL;
@@ -366,13 +366,13 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
return -EINVAL;
}
}
- if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) &&
+ if (ctx_p->cipher_mode == DRV_CIPHER_XTS &&
xts_check_key(tfm, key, keylen) != 0) {
SSI_LOG_DEBUG("weak XTS key");
return -EINVAL;
}
- if ((ctx_p->flow_mode == S_DIN_to_DES) &&
- (keylen == DES3_EDE_KEY_SIZE) &&
+ if (ctx_p->flow_mode == S_DIN_to_DES &&
+ keylen == DES3_EDE_KEY_SIZE &&
ssi_verify_3des_keys(key, keylen) != 0) {
SSI_LOG_DEBUG("weak 3DES key");
return -EINVAL;
@@ -401,6 +401,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
/* sha256 for key2 - use sw implementation */
int key_len = keylen >> 1;
int err;
+
SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm);
desc->tfm = ctx_p->shash_tfm;
@@ -457,8 +458,8 @@ static int ssi_blkc
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 > 1 file changed, 4 insertions(+), 4 deletions(-) You sent me 5 patches for the same driver, yet no way for me to determine what the order of the patches are. Please resend as a numbered patch series so I get it right. Remember, make it obvious what a maintainer is supposed to do... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 declarations Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 run some Android app on their desktop >> using anbox. > > I don't think the binder driver is present on any regular Linux box, > so things like anbox actually have to provide it as a module. It looks > like the current version of anbox is actually using the v8 interface, > and is also using a modified version of the binder driver (eg for > dkms, but also other hacks). The other popular one is Shashlik, but > looks like it uses a VM (just for binder). The v7 interface doesn't > work on 64-bit machines at all, so any container userspace using v7 > would be seriously limiting the number of machines it could be run on, > whereas v8 runs on both 32 and 64. So I'm not sure we have to be > concerned about things like this, certainly if we have communicated > earlier (as Greg said) that binder shouldn't be used outside Android > pre 4.14. Ok. >> The scenario I had in mind is like this: > > Thanks for clarifying! I think this works, but it's additional code to > maintain and support for a pretty rare (and unsupported?) scenario. I > understand that hiding ABI behind a config option is not a good > design, and that it must be removed. If we really can't remove v7 from > 4.14, I would actually prefer to leave the config option (but flip the > default to v8), and remove it as soon as we think it can be (eg once P > has been in the field for a while). How would waiting help? If we are reasonably sure that it's not a problem, then let's remove the v7 support now and see if anyone complains (and put it back if they did have a reason to need it). If we can assume that the upstream binder driver (unlike third-party modules for anbox, which are not affected as you say) is only ever used with a platform specific full Android build, the question is what upgrade scenarios a device might need to support. The relevant cases would seem to be: 1. updating a 32-bit Android Oreo (or earlier) OS from linux-4.9 (or earlier) to linux-4.14 (or later) without updating libbinder: This would require keeping around compile-time option at least, for as long new kernels are supported on Oreo. 2. updating a 32-bit kernel to a 64-bit kernel on hardware that allows this, without changing anything else: Theoretically fixable, but this would require significant code changes in the kernel module, similar to what I described above. 3. upgrading from Android Oreo (or earlier) to Android P while upgrading the kernel at the same time: should be no problem. 4. upgrading from Android Oreo (or earlier) to Android P libbinder without upgrading the kernel: this might require patching the old kernels to enable the v8 ABI. Not our problem here, as it only concerns older kernels. What assumptions can we make about the two problematic cases (1 and 2) here? Is it reasonable to require device makes to always update libbinder together with the kernel? Could that run into problems after a botched upgrade that reverts back to an older kernel but keeps the new user space or vice versa? Arnd ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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: Aishwarya Pant
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 2db2ca6..99f3d5c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -1196,7 +1196,7 @@ static void issue_assocreq(struct adapter *padapter)
}
/* when wait_ack is true, this function should be called at process context */
-static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
unsigned int power_mode, int wait_ack)
+static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
unsigned int power_mode, bool wait_ack)
{
int ret = _FAIL;
struct xmit_frame *pmgntframe;
@@ -1316,7 +1316,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
char *da, unsigned int pow
}
/* when wait_ack is true, this function should be called at process context */
-static int _issue_qos_nulldata(struct adapter *padapter, unsigned char *da,
u16 tid, int wait_ack)
+static int _issue_qos_nulldata(struct adapter *padapter, unsigned char *da,
u16 tid, bool wait_ack)
{
int ret = _FAIL;
struct xmit_frame *pmgntframe;
@@ -1442,7 +1442,7 @@ int issue_qos_nulldata(struct adapter *padapter, unsigned
char *da, u16 tid, int
return ret;
}
-static int _issue_deauth(struct adapter *padapter, unsigned char *da, unsigned
short reason, u8 wait_ack)
+static int _issue_deauth(struct adapter *padapter, unsigned char *da, unsigned
short reason, bool wait_ack)
{
struct xmit_frame *pmgntframe;
struct pkt_attrib *pattrib;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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 a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 52f31c7..2db2ca6 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -707,7 +707,7 @@ static int issue_probereq_ex(struct adapter *padapter,
unsigned long start = jiffies;
do {
- ret = issue_probereq(padapter, pssid, da, wait_ms > 0 ? true :
false);
+ ret = issue_probereq(padapter, pssid, da, wait_ms > 0);
i++;
@@ -1283,7 +1283,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
char *da, unsigned int pow
da = pnetwork->MacAddress;
do {
- ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0 ?
true : false);
+ ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0);
i++;
@@ -1410,7 +1410,7 @@ int issue_qos_nulldata(struct adapter *padapter, unsigned
char *da, u16 tid, int
da = pnetwork->MacAddress;
do {
- ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0 ? true
: false);
+ ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0);
i++;
@@ -1517,7 +1517,7 @@ static int issue_deauth_ex(struct adapter *padapter, u8
*da,
unsigned long start = jiffies;
do {
- ret = _issue_deauth(padapter, da, reason, wait_ms > 0 ? true :
false);
+ ret = _issue_deauth(padapter, da, reason, wait_ms > 0);
i++;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
> ---
> drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> index 52f31c7..2db2ca6 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> @@ -707,7 +707,7 @@ static int issue_probereq_ex(struct adapter *padapter,
> unsigned long start = jiffies;
>
> do {
> - ret = issue_probereq(padapter, pssid, da, wait_ms > 0 ? true :
> false);
> + ret = issue_probereq(padapter, pssid, da, wait_ms > 0);
>
> i++;
>
> @@ -1283,7 +1283,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
> char *da, unsigned int pow
> da = pnetwork->MacAddress;
>
> do {
> - ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0 ?
> true : false);
> + ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0);
>
> i++;
>
> @@ -1410,7 +1410,7 @@ int issue_qos_nulldata(struct adapter *padapter,
> unsigned char *da, u16 tid, int
> da = pnetwork->MacAddress;
>
> do {
> - ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0 ? true
> : false);
> + ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0);
>
> i++;
>
> @@ -1517,7 +1517,7 @@ static int issue_deauth_ex(struct adapter *padapter, u8
> *da,
> unsigned long start = jiffies;
>
> do {
> - ret = _issue_deauth(padapter, da, reason, wait_ms > 0 ? true :
> false);
> + ret = _issue_deauth(padapter, da, reason, wait_ms > 0);
>
> i++;
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170922094052.GA29313%40aishwarya.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 wait_ack a bool type in all usages.
These are two patches on the same file. They need to be in a series, so
Greg doesn't have to figure out whether they depend on each other.
Also, since you are changing the function headers, it would be very nice
if you could also change them to respect the 80 character limit.
julia
>
> Signed-off-by: Aishwarya Pant
> ---
> drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> index 2db2ca6..99f3d5c 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> @@ -1196,7 +1196,7 @@ static void issue_assocreq(struct adapter *padapter)
> }
>
> /* when wait_ack is true, this function should be called at process context
> */
> -static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
> unsigned int power_mode, int wait_ack)
> +static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
> unsigned int power_mode, bool wait_ack)
> {
> int ret = _FAIL;
> struct xmit_frame *pmgntframe;
> @@ -1316,7 +1316,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
> char *da, unsigned int pow
> }
>
> /* when wait_ack is true, this function should be called at process context
> */
> -static int _issue_qos_nulldata(struct adapter *padapter, unsigned char *da,
> u16 tid, int wait_ack)
> +static int _issue_qos_nulldata(struct adapter *padapter, unsigned char *da,
> u16 tid, bool wait_ack)
> {
> int ret = _FAIL;
> struct xmit_frame *pmgntframe;
> @@ -1442,7 +1442,7 @@ int issue_qos_nulldata(struct adapter *padapter,
> unsigned char *da, u16 tid, int
> return ret;
> }
>
> -static int _issue_deauth(struct adapter *padapter, unsigned char *da,
> unsigned short reason, u8 wait_ack)
> +static int _issue_deauth(struct adapter *padapter, unsigned char *da,
> unsigned short reason, bool wait_ack)
> {
> struct xmit_frame *pmgntframe;
> struct pkt_attrib *pattrib;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170922093939.GA29152%40aishwarya.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 in function declarations it is defined as an int type. Fix it by
> > defining wait_ack a bool type in all usages.
>
> These are two patches on the same file. They need to be in a series, so
> Greg doesn't have to figure out whether they depend on each other.
>
> Also, since you are changing the function headers, it would be very nice
> if you could also change them to respect the 80 character limit.
Okay I'll create a patch series on rtl8188eu cleanups. Please drop this patch.
>
> julia
>
> >
> > Signed-off-by: Aishwarya Pant
> > ---
> > drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > index 2db2ca6..99f3d5c 100644
> > --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > @@ -1196,7 +1196,7 @@ static void issue_assocreq(struct adapter *padapter)
> > }
> >
> > /* when wait_ack is true, this function should be called at process
> > context */
> > -static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
> > unsigned int power_mode, int wait_ack)
> > +static int _issue_nulldata(struct adapter *padapter, unsigned char *da,
> > unsigned int power_mode, bool wait_ack)
> > {
> > int ret = _FAIL;
> > struct xmit_frame *pmgntframe;
> > @@ -1316,7 +1316,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
> > char *da, unsigned int pow
> > }
> >
> > /* when wait_ack is true, this function should be called at process
> > context */
> > -static int _issue_qos_nulldata(struct adapter *padapter, unsigned char
> > *da, u16 tid, int wait_ack)
> > +static int _issue_qos_nulldata(struct adapter *padapter, unsigned char
> > *da, u16 tid, bool wait_ack)
> > {
> > int ret = _FAIL;
> > struct xmit_frame *pmgntframe;
> > @@ -1442,7 +1442,7 @@ int issue_qos_nulldata(struct adapter *padapter,
> > unsigned char *da, u16 tid, int
> > return ret;
> > }
> >
> > -static int _issue_deauth(struct adapter *padapter, unsigned char *da,
> > unsigned short reason, u8 wait_ack)
> > +static int _issue_deauth(struct adapter *padapter, unsigned char *da,
> > unsigned short reason, bool wait_ack)
> > {
> > struct xmit_frame *pmgntframe;
> > struct pkt_attrib *pattrib;
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/outreachy-kernel/20170922093939.GA29152%40aishwarya.
> > For more options, visit https://groups.google.com/d/optout.
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
>
> Acked-by: Julia Lawall
Dropping this patch to include it in a clean up patch set.
Julia, I can include this ack when I add it to the patch set?
>
>
> > ---
> > drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > index 52f31c7..2db2ca6 100644
> > --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > @@ -707,7 +707,7 @@ static int issue_probereq_ex(struct adapter *padapter,
> > unsigned long start = jiffies;
> >
> > do {
> > - ret = issue_probereq(padapter, pssid, da, wait_ms > 0 ? true :
> > false);
> > + ret = issue_probereq(padapter, pssid, da, wait_ms > 0);
> >
> > i++;
> >
> > @@ -1283,7 +1283,7 @@ int issue_nulldata(struct adapter *padapter, unsigned
> > char *da, unsigned int pow
> > da = pnetwork->MacAddress;
> >
> > do {
> > - ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0 ?
> > true : false);
> > + ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0);
> >
> > i++;
> >
> > @@ -1410,7 +1410,7 @@ int issue_qos_nulldata(struct adapter *padapter,
> > unsigned char *da, u16 tid, int
> > da = pnetwork->MacAddress;
> >
> > do {
> > - ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0 ? true
> > : false);
> > + ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0);
> >
> > i++;
> >
> > @@ -1517,7 +1517,7 @@ static int issue_deauth_ex(struct adapter *padapter,
> > u8 *da,
> > unsigned long start = jiffies;
> >
> > do {
> > - ret = _issue_deauth(padapter, da, reason, wait_ms > 0 ? true :
> > false);
> > + ret = _issue_deauth(padapter, da, reason, wait_ms > 0);
> >
> > i++;
> >
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/outreachy-kernel/20170922094052.GA29313%40aishwarya.
> > For more options, visit https://groups.google.com/d/optout.
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
> > >
> > > Signed-off-by: Aishwarya Pant
> >
> > Acked-by: Julia Lawall
>
> Dropping this patch to include it in a clean up patch set.
>
> Julia, I can include this ack when I add it to the patch set?
Yes, that part of the patch was fine.
julia
>
> >
> >
> > > ---
> > > drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > > b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > > index 52f31c7..2db2ca6 100644
> > > --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > > +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> > > @@ -707,7 +707,7 @@ static int issue_probereq_ex(struct adapter *padapter,
> > > unsigned long start = jiffies;
> > >
> > > do {
> > > - ret = issue_probereq(padapter, pssid, da, wait_ms > 0 ? true :
> > > false);
> > > + ret = issue_probereq(padapter, pssid, da, wait_ms > 0);
> > >
> > > i++;
> > >
> > > @@ -1283,7 +1283,7 @@ int issue_nulldata(struct adapter *padapter,
> > > unsigned char *da, unsigned int pow
> > > da = pnetwork->MacAddress;
> > >
> > > do {
> > > - ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0 ?
> > > true : false);
> > > + ret = _issue_nulldata(padapter, da, power_mode, wait_ms > 0);
> > >
> > > i++;
> > >
> > > @@ -1410,7 +1410,7 @@ int issue_qos_nulldata(struct adapter *padapter,
> > > unsigned char *da, u16 tid, int
> > > da = pnetwork->MacAddress;
> > >
> > > do {
> > > - ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0 ? true
> > > : false);
> > > + ret = _issue_qos_nulldata(padapter, da, tid, wait_ms > 0);
> > >
> > > i++;
> > >
> > > @@ -1517,7 +1517,7 @@ static int issue_deauth_ex(struct adapter
> > > *padapter, u8 *da,
> > > unsigned long start = jiffies;
> > >
> > > do {
> > > - ret = _issue_deauth(padapter, da, reason, wait_ms > 0 ? true :
> > > false);
> > > + ret = _issue_deauth(padapter, da, reason, wait_ms > 0);
> > >
> > > i++;
> > >
> > > --
> > > 2.7.4
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "outreachy-kernel" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > > To view this discussion on the web visit
> > > https://groups.google.com/d/msgid/outreachy-kernel/20170922094052.GA29313%40aishwarya.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 03:52:45PM +0530, Janani Sankara Babu wrote: > Hi Mr. Greg, > > The patches that I have sent are independent of each other. There is > nothing from one patch that will affect the other one and vice verse. I have > double checked the same. And how am I supposed to know that? :) > Kindly let me know if I have to do the ordering of patches. Please do, they are long-gone from my queue now. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 really hard to draw a line when it is "good enough", so I agree with you it doesn't really help, it just reduces the chance that somebody will be affected by it. > The relevant cases would seem to be: > > 1. updating a 32-bit Android Oreo (or earlier) OS from linux-4.9 > (or earlier) to linux-4.14 (or later) without updating libbinder: > This would require keeping around compile-time option > at least, for as long new kernels are supported on Oreo. I think it is unlikely a vendor would upgrade their kernel from linux-4.9 to linux-4.14 on an already launched Android device - it is just too much work. Vendors ideally should pick an LTS kernel and stick with it. But of course we can't rule it out. If it does happen, I don't think it would be strange to expect vendors to upgrade their userspace along with it. Many vendors (sadly) have a ton of patches on top of mainline, that may contain non-ABI-stable interfaces in the first place, and therefore would require a userspace push anyway. > 2. updating a 32-bit kernel to a 64-bit kernel on hardware > that allows this, without changing anything else: > Theoretically fixable, but this would require significant > code changes in the kernel module, similar to what I > described above. This is an issue independent of what we do here; if you used the v7 interface in your pre-4.14 32-bit kernel, you have to migrate to v8 simply because the v7 interface can't work with a (pre-4.14) 64-bit kernel. If you upgrade to a 4.14 kernel from which v7 is removed, you fall back to the previous case. Such a change would anyway require building and deploying a new Android userspace, assuming you'd want to allow running 64-bit userspace applications on such a kernel. I'm not sure whether there are good reasons to switch to a 64-bit kernel while maintaining a 32-bit only userspace. > What assumptions can we make about the two problematic > cases (1 and 2) here? Is it reasonable to require device > makes to always update libbinder together with the kernel? I personally think this is reasonable. Rolling out an update to an Android device involves a lot of work; if you're going to update the kernel, you'll often want to use the opportunity to update userspace as well for things like security fixes. Project Treble has made it significantly easier to update individual parts of Android. Unfortunately binder is so pervasive that it touches pretty much everything - migrating from v7 to v8 will require a full userspace push. Again, I don't think this is a problem, because: 1) Launched Android devices tend to stick with the kernel version they launched with (so v7 will stay available to them) 2) If they do want to upgrade, I don't think it's unreasonable to ask them to do a userspace push along with it 3) New devices launching with 4.14 (and P) will have no choice to use anything but v8 > Could that run into problems after a botched upgrade that > reverts back to an older kernel but keeps the new user space > or vice versa? Our current A/B partition scheme keeps a complete copy of both the old kernel and userspace when upgrading; if the upgrade doesn't boot, we revert both back to the old state. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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.
So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST
and TYPEC_MUX_USB_DEVICE and makes tcpm_set_roles() set the mux
accordingly.
Likewise TCPC_MUX_DP gets renamed to TCPC_MUX_DP_SRC to make clear that
this is for configuring the Type-C port as a Display Port source, not a
sink.
Last this commit makes tcpm_reset_port() to set the mux to
TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT so that it does not and up
staying in host (and with this commit also device) mode after a detach.
This sentence is hard to understand.
Ok, changed to:
"Last this commit makes tcpm_reset_port() call tcpm_mux_set(port,
TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT) so that the mux does _not_
stay in its last mode after a detach."
For v3 of this patchset.
Signed-off-by: Hans de Goede
Otherwise
Reviewed-by: Guenter Roeck
And added your Reviewed-by.
Thanks & Regards,
Hans
---
drivers/staging/typec/tcpm.c | 7 ---
drivers/staging/typec/tcpm.h | 22 ++
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 8af62e74d54c..ffe7e26d4ed3 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -752,11 +752,11 @@ static int tcpm_set_roles(struct tcpm_port *port, bool
attached,
int ret;
if (data == TYPEC_HOST)
- ret = tcpm_mux_set(port, TYPEC_MUX_USB,
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_HOST,
TCPC_USB_SWITCH_CONNECT);
else
- ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
- TCPC_USB_SWITCH_DISCONNECT);
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_DEVICE,
+ TCPC_USB_SWITCH_CONNECT);
if (ret < 0)
return ret;
@@ -2025,6 +2025,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
index 7e9a6b7b5cd6..f662eed48c86 100644
--- a/drivers/staging/typec/tcpm.h
+++ b/drivers/staging/typec/tcpm.h
@@ -83,17 +83,23 @@ enum tcpc_usb_switch {
};
/* Mux state attributes */
-#define TCPC_MUX_USB_ENABLED BIT(0) /* USB enabled */
-#define TCPC_MUX_DP_ENABLED BIT(1) /* DP enabled */
-#define TCPC_MUX_POLARITY_INVERTED BIT(2) /* Polarity inverted */
+#define TCPC_MUX_USB_DEVICE_ENABLED BIT(0) /* USB device enabled */
+#define TCPC_MUX_USB_HOST_ENABLED BIT(1) /* USB host enabled */
+#define TCPC_MUX_DP_SRC_ENABLED BIT(2) /* DP enabled */
+#define TCPC_MUX_POLARITY_INVERTED BIT(3) /* Polarity inverted */
/* Mux modes, decoded to attributes */
enum tcpc_mux_mode {
- TYPEC_MUX_NONE = 0, /* Open switch */
- TYPEC_MUX_USB = TCPC_MUX_USB_ENABLED, /* USB only */
- TYPEC_MUX_DP = TCPC_MUX_DP_ENABLED, /* DP only */
- TYPEC_MUX_DOCK = TCPC_MUX_USB_ENABLED | /* Both USB and DP */
- TCPC_MUX_DP_ENABLED,
+ /* Open switch */
+ TYPEC_MUX_NONE = 0,
+ /* USB device only */
+ TYPEC_MUX_USB_DEVICE = TCPC_MUX_USB_DEVICE_ENABLED,
+ /* USB host only */
+ TYPEC_MUX_USB_HOST = TCPC_MUX_USB_HOST_ENABLED,
+ /* DP source only */
+ TYPEC_MUX_DP = TCPC_MUX_DP_SRC_ENABLED,
+ /* Both USB host and DP source */
+ TYPEC_MUX_DOCK = TCPC_MUX_USB_HOST_ENABLED | TCPC_MUX_DP_SRC_ENABLED,
};
struct tcpc_mux_dev {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
After:
textdata bss dec hex filename
6380683041216 73326 11e6e rtllib_softmac.o
(gcc 6.3.0, x86-64)
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8192e/rtllib_softmac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index e4be85af31e7..1e308dfd7f74 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2811,8 +2811,9 @@ static void rtllib_associate_retry_wq(void *data)
static struct sk_buff *rtllib_get_beacon_(struct rtllib_device *ieee)
{
- const u8 broadcast_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-
+ static const u8 broadcast_addr[] = {
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ };
struct sk_buff *skb;
struct rtllib_probe_response *b;
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
After:
textdata bss dec hex filename
179503224 320 2149453f6 drivers/net/hyperv/netvsc.o
(gcc 6.3.0, x86-64)
Signed-off-by: Colin Ian King
---
drivers/net/hyperv/netvsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 8d5077fb0492..b0d323e24978 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -484,7 +484,7 @@ static int netvsc_connect_vsp(struct hv_device *device,
struct netvsc_device *net_device,
const struct netvsc_device_info *device_info)
{
- const u32 ver_list[] = {
+ static const u32 ver_list[] = {
NVSP_PROTOCOL_VERSION_1, NVSP_PROTOCOL_VERSION_2,
NVSP_PROTOCOL_VERSION_4, NVSP_PROTOCOL_VERSION_5
};
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [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: >text data bss dec hex filename > 18444 3168 320 2193255ac > drivers/net/hyperv/netvsc.o > > After: >text data bss dec hex filename > 17950 3224 320 2149453f6 > drivers/net/hyperv/netvsc.o > > (gcc 6.3.0, x86-64) > > Signed-off-by: Colin Ian King > --- Reviewed-by: Haiyang Zhang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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 add
a mux_control_get_optional() API that allows the driver to
differentiate errors getting the mux from there not being a mux
for the driver to use at all.
Signed-off-by: Stephen Boyd
Signed-off-by: Hans de Goede
---
Documentation/driver-model/devres.txt | 1 +
drivers/mux/core.c| 104 +++---
include/linux/mux/consumer.h | 4 ++
3 files changed, 89 insertions(+), 20 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 69f08c0f23a8..5e41f3ac8a05 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -343,6 +343,7 @@ MUX
devm_mux_chip_alloc()
devm_mux_chip_register()
devm_mux_control_get()
+ devm_mux_control_get_optional()
PER-CPU MEM
devm_alloc_percpu()
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 6e5cf9d9cd99..244bceb17877 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -289,6 +289,9 @@ EXPORT_SYMBOL_GPL(devm_mux_chip_register);
*/
unsigned int mux_control_states(struct mux_control *mux)
{
+ if (!mux)
+ return 0;
+
return mux->states;
}
EXPORT_SYMBOL_GPL(mux_control_states);
@@ -338,6 +341,9 @@ int mux_control_select(struct mux_control *mux, unsigned
int state)
{
int ret;
+ if (!mux)
+ return 0;
+
ret = down_killable(&mux->lock);
if (ret < 0)
return ret;
@@ -370,6 +376,9 @@ int mux_control_try_select(struct mux_control *mux,
unsigned int state)
{
int ret;
+ if (!mux)
+ return 0;
+
if (down_trylock(&mux->lock))
return -EBUSY;
@@ -398,6 +407,9 @@ int mux_control_deselect(struct mux_control *mux)
{
int ret = 0;
+ if (!mux)
+ return 0;
+
if (mux->idle_state != MUX_IDLE_AS_IS &&
mux->idle_state != mux->cached_state)
ret = mux_control_set(mux, mux->idle_state);
@@ -423,14 +435,8 @@ static struct mux_chip *of_find_mux_chip_by_node(struct
device_node *np)
return dev ? to_mux_chip(dev) : NULL;
}
-/**
- * mux_control_get() - Get the mux-control for a device.
- * @dev: The device that needs a mux-control.
- * @mux_name: The name identifying the mux-control.
- *
- * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
- */
-struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
+static struct mux_control *
+__mux_control_get(struct device *dev, const char *mux_name, bool optional)
{
struct device_node *np = dev->of_node;
struct of_phandle_args args;
@@ -442,16 +448,22 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
if (mux_name) {
index = of_property_match_string(np, "mux-control-names",
mux_name);
+ if ((index == -EINVAL || index == -ENODATA) && optional)
+ return NULL;
if (index < 0) {
dev_err(dev, "mux controller '%s' not found\n",
mux_name);
return ERR_PTR(index);
}
+ /* OF does point to a mux, so it's no longer optional */
+ optional = false;
}
ret = of_parse_phandle_with_args(np,
"mux-controls", "#mux-control-cells",
index, &args);
+ if (ret == -ENOENT && optional)
+ return NULL;
if (ret) {
dev_err(dev, "%pOF: failed to get mux-control %s(%i)\n",
np, mux_name ?: "", index);
@@ -484,8 +496,35 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
return &mux_chip->mux[controller];
}
+
+/**
+ * mux_control_get() - Get the mux-control for a device.
+ * @dev: The device that needs a mux-control.
+ * @mux_name: The name identifying the mux-control.
+ *
+ * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno.
+ */
+struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
+{
+ return __mux_control_get(dev, mux_name, false);
+}
EXPORT_SYMBOL_GPL(mux_control_get);
+/**
+ * mux_control_get_optional() - Get the optional mux-control for a device.
+ * @dev: The device that needs a mux-control.
+ * @mux_name: The name identifying the mux-control.
+ *
+ * Return: NULL if no mux with the provided name is found, a pointer to
+ * the named mux-control or an ERR_PTR with a negative errno.
+ */
+struct mux_control *
+mux_control_get_op
[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 controller on a non DT platform
following this pattern. It is based on a simplified version of the pwm
subsys lookup code, the dev_id and mux_name parts of a lookup table entry
are mandatory in the mux-core implementation.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fixup some kerneldoc comments, add kerneldoc comment to structs
-Minor code-style tweaks
---
drivers/mux/core.c | 93 +++-
include/linux/mux/consumer.h | 19 +
2 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 8c0a4c83cdc5..c9afc79196f0 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -24,6 +24,9 @@
#include
#include
+static DEFINE_MUTEX(mux_lookup_lock);
+static LIST_HEAD(mux_lookup_list);
+
/*
* The idle-as-is "state" is not an actual state that may be selected, it
* only implies that the state should not be changed. So, use that state
@@ -423,6 +426,23 @@ int mux_control_deselect(struct mux_control *mux)
}
EXPORT_SYMBOL_GPL(mux_control_deselect);
+static int parent_name_match(struct device *dev, const void *data)
+{
+ const char *parent_name = dev_name(dev->parent);
+ const char *name = data;
+
+ return strcmp(parent_name, name) == 0;
+}
+
+static struct mux_chip *mux_chip_get_by_name(const char *name)
+{
+ struct device *dev;
+
+ dev = class_find_device(&mux_class, NULL, name, parent_name_match);
+
+ return dev ? to_mux_chip(dev) : NULL;
+}
+
static int of_dev_node_match(struct device *dev, const void *data)
{
return dev->of_node == data;
@@ -503,12 +523,83 @@ of_mux_control_get(struct device *dev, const char
*mux_name, bool optional)
static struct mux_control *
__mux_control_get(struct device *dev, const char *mux_name, bool optional)
{
+ struct mux_lookup *m, *chosen = NULL;
+ const char *dev_id = dev_name(dev);
+ struct mux_chip *mux_chip;
+
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) && dev->of_node)
return of_mux_control_get(dev, mux_name, optional);
- return optional ? NULL : ERR_PTR(-ENODEV);
+ /*
+* For non DT we look up the provider in the static table typically
+* provided by board setup code.
+*
+* If a match is found, the provider mux chip is looked up by name
+* and a mux-control is requested using the table provided index.
+*/
+ mutex_lock(&mux_lookup_lock);
+ list_for_each_entry(m, &mux_lookup_list, list) {
+ if (WARN_ON(!m->dev_id || !m->mux_name || !m->provider))
+ continue;
+
+ if (!strcmp(m->dev_id, dev_id) &&
+ !strcmp(m->mux_name, mux_name))
+ {
+ chosen = m;
+ break;
+ }
+ }
+ mutex_unlock(&mux_lookup_lock);
+
+ if (!chosen)
+ return optional ? NULL : ERR_PTR(-ENODEV);
+
+ mux_chip = mux_chip_get_by_name(chosen->provider);
+ if (!mux_chip)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ if (chosen->index >= mux_chip->controllers) {
+ dev_err(dev, "Mux lookup table index out of bounds %u >= %u\n",
+ chosen->index, mux_chip->controllers);
+ put_device(&mux_chip->dev);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return &mux_chip->mux[chosen->index];
+}
+
+/**
+ * mux_add_table() - Register consumer to mux-controller mappings
+ * @table: array of mappings to register
+ * @num: number of mappings in table
+ */
+void mux_add_table(struct mux_lookup *table, size_t num)
+{
+ mutex_lock(&mux_lookup_lock);
+
+ for (; num--; table++)
+ list_add_tail(&table->list, &mux_lookup_list);
+
+ mutex_unlock(&mux_lookup_lock);
+}
+EXPORT_SYMBOL_GPL(mux_add_table);
+
+/**
+ * mux_remove_table() - Unregister consumer to mux-controller mappings
+ * @table: array of mappings to unregister
+ * @num: number of mappings in table
+ */
+void mux_remove_table(struct mux_lookup *table, size_t num)
+{
+ mutex_lock(&mux_lookup_lock);
+
+ for (; num--; table++)
+ list_del(&table->list);
+
+ mutex_unlock(&mux_lookup_lock);
}
+EXPORT_SYMBOL_GPL(mux_remove_table);
/**
* mux_control_get() - Get the mux-control for a device.
diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
index fc98547bf494..eaa6d239c4f5 100644
--- a/include/linux/mux/consumer.h
+++ b/include/linux/mux/consumer.h
@@ -18,6 +18,25 @@
struct device;
struct mux_control;
+/**
+ * struct mux_lookup - Mux consumer to mux-control
[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 for getting muxes on
non DT platforms.
Signed-off-by: Hans de Goede
---
drivers/mux/core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index d0ad56abca2a..8c0a4c83cdc5 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -439,7 +439,7 @@ static struct mux_chip *of_find_mux_chip_by_node(struct
device_node *np)
}
static struct mux_control *
-__mux_control_get(struct device *dev, const char *mux_name, bool optional)
+of_mux_control_get(struct device *dev, const char *mux_name, bool optional)
{
struct device_node *np = dev->of_node;
struct of_phandle_args args;
@@ -500,6 +500,16 @@ __mux_control_get(struct device *dev, const char
*mux_name, bool optional)
return &mux_chip->mux[controller];
}
+static struct mux_control *
+__mux_control_get(struct device *dev, const char *mux_name, bool optional)
+{
+ /* look up via DT first */
+ if (IS_ENABLED(CONFIG_OF) && dev->of_node)
+ return of_mux_control_get(dev, mux_name, optional);
+
+ return optional ? NULL : ERR_PTR(-ENODEV);
+}
+
/**
* mux_control_get() - Get the mux-control for a device.
* @dev: The device that needs a mux-control.
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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 (reserved) This is useful when we want to loop through all capabilities. Signed-off-by: Mathias Nyman Signed-off-by: Hans de Goede --- drivers/usb/host/xhci-ext-caps.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h index 28deea584884..c1b404224839 100644 --- a/drivers/usb/host/xhci-ext-caps.h +++ b/drivers/usb/host/xhci-ext-caps.h @@ -96,7 +96,8 @@ * @base PCI MMIO registers base address. * @start address at which to start looking, (0 or HCC_PARAMS to start at * beginning of list) - * @id Extended capability ID to search for. + * @id Extended capability ID to search for, or 0 for the next + * capability * * Returns the offset of the next matching extended capability structure. * Some capabilities can occur several times, e.g., the XHCI_EXT_CAPS_PROTOCOL, @@ -122,7 +123,7 @@ static inline int xhci_find_next_ext_cap(void __iomem *base, u32 start, int id) val = readl(base + offset); if (val == ~0) return 0; - if (XHCI_EXT_CAPS_ID(val) == id && offset != start) + if (offset != start && (id == 0 || XHCI_EXT_CAPS_ID(val) == id)) return offset; next = XHCI_EXT_CAPS_NEXT(val); -- 2.14.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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 can
access it and set a state that destroys booting all the same.
2. The mux controller might linger in a state that is not the
preferred idle state indefinitely, if no mux consumer ever selects
and then deselects the mux.
Signed-off-by: Hans de Goede
---
drivers/mux/core.c | 3 +++
include/linux/mux/driver.h | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 244bceb17877..d0ad56abca2a 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -155,6 +155,9 @@ int mux_chip_register(struct mux_chip *mux_chip)
for (i = 0; i < mux_chip->controllers; ++i) {
struct mux_control *mux = &mux_chip->mux[i];
+ if (mux->init_as_is)
+ continue;
+
if (mux->idle_state == mux->cached_state)
continue;
diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
index 35c3579c3304..21cf6041a962 100644
--- a/include/linux/mux/driver.h
+++ b/include/linux/mux/driver.h
@@ -36,6 +36,9 @@ struct mux_control_ops {
* @states:The number of mux controller states.
* @idle_state:The mux controller state to use when inactive,
or one
* of MUX_IDLE_AS_IS and MUX_IDLE_DISCONNECT.
+ * @init_as_is:Set to true to have the core leave the mux
controller
+ * state as-is until first selection. If @idle_state is
+ * MUX_IDLE_AS_IS, @init_as_is is irrelevant.
*
* Mux drivers may only change @states and @idle_state, and may only do so
* between allocation and registration of the mux controller. Specifically,
@@ -50,6 +53,7 @@ struct mux_control {
unsigned int states;
int idle_state;
+ bool init_as_is;
};
/**
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform mux driver for the
mux.
Note this commit adds a call to the new xhci_ext_cap_init() function
to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must
be called only once. If in the future we also want to handle ext-caps
on non pci XHCI HCDs from xhci_ext_cap_init() a call to it should also
be added to other bus probe paths.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Check xHCI controller PCI device-id instead of only checking for the
Intel Extended capability ID, as the Extended capability ID is used on
other model Intel xHCI controllers too
Changes in v3:
-Add a new generic xhci_ext_cap_init() function and handle the new
XHCI_INTEL_CHT_USB_MUX quirk there.
---
drivers/usb/host/Makefile| 2 +-
drivers/usb/host/xhci-ext-caps.c | 88
drivers/usb/host/xhci-ext-caps.h | 2 +
drivers/usb/host/xhci-pci.c | 5 +++
drivers/usb/host/xhci.h | 2 +
5 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/xhci-ext-caps.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691fffcc0..59329a9cf392 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -10,7 +10,7 @@ fhci-y += fhci-mem.o fhci-tds.o fhci-sched.o
fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
-xhci-hcd-y := xhci.o xhci-mem.o
+xhci-hcd-y := xhci.o xhci-mem.o xhci-ext-caps.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
ifneq ($(CONFIG_USB_XHCI_MTK), )
diff --git a/drivers/usb/host/xhci-ext-caps.c b/drivers/usb/host/xhci-ext-caps.c
new file mode 100644
index ..8bc4787afdd0
--- /dev/null
+++ b/drivers/usb/host/xhci-ext-caps.c
@@ -0,0 +1,88 @@
+/*
+ * XHCI extended capability handling
+ *
+ * Copyright (c) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include "xhci.h"
+
+static void xhci_intel_unregister_pdev(void *arg)
+{
+ platform_device_unregister(arg);
+}
+
+static int xhci_create_intel_cht_mux_pdev(struct xhci_hcd *xhci, u32
cap_offset)
+{
+ struct usb_hcd *hcd = xhci_to_hcd(xhci);
+ struct device *dev = hcd->self.controller;
+ struct platform_device *pdev;
+ struct resource res = { 0, };
+ int ret;
+
+ pdev = platform_device_alloc("intel_cht_usb_mux", PLATFORM_DEVID_NONE);
+ if (!pdev) {
+ xhci_err(xhci, "couldn't allocate intel_cht_usb_mux pdev\n");
+ return -ENOMEM;
+ }
+
+ res.start = hcd->rsrc_start + cap_offset;
+ res.end = res.start + 0x3ff;
+ res.name = "intel_cht_usb_mux";
+ res.flags = IORESOURCE_MEM;
+
+ ret = platform_device_add_resources(pdev, &res, 1);
+ if (ret) {
+ dev_err(dev, "couldn't add resources to intel_cht_usb_mux
pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ pdev->dev.parent = dev;
+
+ ret = platform_device_add(pdev);
+ if (ret) {
+ dev_err(dev, "couldn't register intel_cht_usb_mux pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, xhci_intel_unregister_pdev, pdev);
+ if (ret) {
+ dev_err(dev, "couldn't add unregister action for
intel_cht_usb_mux pdev\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+int xhci_ext_cap_init(struct xhci_hcd *xhci)
+{
+ void __iomem *base = &xhci->cap_regs->hc_capbase;
+ u32 cap_offset, val;
+ int ret;
+
+ cap_offset = xhci_find_next_ext_cap(base, 0, 0);
+
+ while (cap_offset) {
+ val = readl(base + cap_offset);
+
+ switch (XHCI_EXT_CAPS_ID(val)) {
+ case XHCI_EXT_CAPS_VENDOR_INTEL:
+ if (xhci->quirks & XHCI_INTEL_CHT_USB_MUX) {
+ ret = xhci_create_intel_cht_mux_pdev(
+ xhci, cap_offset);
+ if (ret)
+ return ret;
+ }
+ break;
+ }
+ cap_offset = xhci_find_next_ext_cap(base, cap_offset, 0);
+ }
+
+ return 0;
+}
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/
[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 --- Changes in v2: -Start numbering of defines at 0 not 1 -Use a new usb.h header, rather then adding these to consumer.h -Add separate MUX_USB_* and MUX_TYPEC_* defines Changes in v3: -Simplify MUX_TYPEC_* states, drop having separate USB HOST / DEVICE states --- include/linux/mux/usb.h | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 include/linux/mux/usb.h diff --git a/include/linux/mux/usb.h b/include/linux/mux/usb.h new file mode 100644 index ..2fec06846e14 --- /dev/null +++ b/include/linux/mux/usb.h @@ -0,0 +1,31 @@ +/* + * mux/usb.h - definitions for USB multiplexers + * + * Copyright (C) 2017 Hans de Goede + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef _LINUX_MUX_USB_H +#define _LINUX_MUX_USB_H + +/* Mux state values for USB device/host role muxes */ +#define MUX_USB_DEVICE (0) /* USB device mode */ +#define MUX_USB_HOST (1) /* USB host mode */ +#define MUX_USB_STATES (2) + +/* + * Mux state values for Type-C polarity/role/altmode muxes. + * + * MUX_TYPEC_POLARITY_INV may be or-ed together with any other mux-state as + * inverted-polarity (Type-C plugged in upside down) can happen with any + * other mux-state. + */ +#define MUX_TYPEC_POLARITY_INV BIT(0) /* Polarity inverted bit */ +#define MUX_TYPEC_USB (0 << 1) /* USB only mode */ +#define MUX_TYPEC_USB_AND_DP (1 << 1) /* USB host + 2 lanes DP */ +#define MUX_TYPEC_DP (2 << 1) /* 4 lanes Display Port */ +#define MUX_TYPEC_STATES (3 << 1) + +#endif /* _LINUX_MUX_TYPEC_H */ -- 2.14.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
handle for the mux and set the mux through the mux-subsys rather then
through a GPIO.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Drop || COMPILE_TEST from Kconfig depends on, as we will now fail to
compile on !X86
-Minor code style tweaks
---
drivers/extcon/Kconfig| 3 +-
drivers/extcon/extcon-intel-int3496.c | 59 +++
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..168f9d710ea0 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -44,7 +44,8 @@ config EXTCON_GPIO
config EXTCON_INTEL_INT3496
tristate "Intel INT3496 ACPI device extcon driver"
- depends on GPIOLIB && ACPI && (X86 || COMPILE_TEST)
+ depends on GPIOLIB && ACPI && X86
+ select MULTIPLEXER
help
Say Y here to enable extcon support for USB OTG ports controlled by
an Intel INT3496 ACPI device.
diff --git a/drivers/extcon/extcon-intel-int3496.c
b/drivers/extcon/extcon-intel-int3496.c
index 1a45e745717d..3c8e17449c12 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -23,8 +23,13 @@
#include
#include
#include
+#include
+#include
#include
+#include
+#include
+
#define INT3496_GPIO_USB_ID0
#define INT3496_GPIO_VBUS_EN 1
#define INT3496_GPIO_USB_MUX 2
@@ -37,6 +42,8 @@ struct int3496_data {
struct gpio_desc *gpio_usb_id;
struct gpio_desc *gpio_vbus_en;
struct gpio_desc *gpio_usb_mux;
+ struct mux_control *usb_mux;
+ bool usb_mux_set;
int usb_id_irq;
};
@@ -56,11 +63,32 @@ static const struct acpi_gpio_mapping
acpi_int3496_default_gpios[] = {
{ },
};
+static struct mux_lookup acpi_int3496_cht_mux_lookup[] = {
+ {
+ .provider = "intel_cht_usb_mux",
+ .dev_id = "INT3496:00",
+ .mux_name = "usb-role-mux",
+ },
+};
+
+#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
+
+static const struct x86_cpu_id cht_cpu_ids[] = {
+ ICPU(INTEL_FAM6_ATOM_AIRMONT), /* Braswell, Cherry Trail */
+ {}
+};
+
+static bool int3496_soc_has_mux(void)
+{
+ return x86_match_cpu(cht_cpu_ids);
+}
+
static void int3496_do_usb_id(struct work_struct *work)
{
struct int3496_data *data =
container_of(work, struct int3496_data, work.work);
int id = gpiod_get_value_cansleep(data->gpio_usb_id);
+ int ret;
/* id == 1: PERIPHERAL, id == 0: HOST */
dev_dbg(data->dev, "Connected %s cable\n", id ? "PERIPHERAL" : "HOST");
@@ -72,6 +100,22 @@ static void int3496_do_usb_id(struct work_struct *work)
if (!IS_ERR(data->gpio_usb_mux))
gpiod_direction_output(data->gpio_usb_mux, id);
+ if (data->usb_mux) {
+ /*
+* The mux framework expects multiple competing users, we must
+* release our previous setting before applying the new one.
+*/
+ if (data->usb_mux_set)
+ mux_control_deselect(data->usb_mux);
+
+ ret = mux_control_select(data->usb_mux,
+id ? MUX_USB_DEVICE : MUX_USB_HOST);
+ if (ret)
+ dev_err(data->dev, "Error setting mux: %d\n", ret);
+
+ data->usb_mux_set = ret == 0;
+ }
+
if (!IS_ERR(data->gpio_vbus_en))
gpiod_direction_output(data->gpio_vbus_en, !id);
@@ -107,6 +151,21 @@ static int int3496_probe(struct platform_device *pdev)
data->dev = dev;
INIT_DELAYED_WORK(&data->work, int3496_do_usb_id);
+ if (int3496_soc_has_mux()) {
+ mux_add_table(acpi_int3496_cht_mux_lookup,
+ ARRAY_SIZE(acpi_int3496_cht_mux_lookup));
+ data->usb_mux = devm_mux_control_get(dev, "usb-role-mux");
+ /* Doing this here keeps our error handling clean. */
+ mux_remove_table(acpi_int3496_cht_mux_lookup,
+ARRAY_SIZE(acpi_int3496_cht_mux_lookup));
+ if (IS_ERR(data->usb_mux)) {
+ ret = PTR_ERR(data->usb_mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "can't get mux: %d\n", ret);
+ return ret;
+ }
+ }
+
data->gpio_usb_id = devm_gpiod_get(dev, "id", GPIOD_IN);
if (IS_ERR(data->gpio_usb_id)) {
ret = PTR_ERR(data->gpio_usb_id);
--
2.14.1
_
[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 and makes tcpm_set_roles() set the mux
accordingly.
Likewise TCPC_MUX_DP gets renamed to TCPC_MUX_DP_SRC to make clear that
this is for configuring the Type-C port as a Display Port source, not a
sink.
Last this commit makes tcpm_reset_port() call tcpm_mux_set(port,
TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT) so that the mux does _not_
stay in its last mode after a detach.
Signed-off-by: Hans de Goede
Reviewed-by: Guenter Roeck
---
Changes in v3:
-Improve / reword last paragraph of the commit message
-Add Guenter's Reviewed-by
---
drivers/usb/typec/tcpm.c | 7 ---
include/linux/usb/tcpm.h | 22 ++
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f557c479fdc2..e104c218cb4a 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -751,11 +751,11 @@ static int tcpm_set_roles(struct tcpm_port *port, bool
attached,
int ret;
if (data == TYPEC_HOST)
- ret = tcpm_mux_set(port, TYPEC_MUX_USB,
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_HOST,
TCPC_USB_SWITCH_CONNECT);
else
- ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
- TCPC_USB_SWITCH_DISCONNECT);
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB_DEVICE,
+ TCPC_USB_SWITCH_CONNECT);
if (ret < 0)
return ret;
@@ -1995,6 +1995,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 073197f0d2bb..bc76389ee257 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -103,17 +103,23 @@ enum tcpc_usb_switch {
};
/* Mux state attributes */
-#define TCPC_MUX_USB_ENABLED BIT(0) /* USB enabled */
-#define TCPC_MUX_DP_ENABLEDBIT(1) /* DP enabled */
-#define TCPC_MUX_POLARITY_INVERTED BIT(2) /* Polarity inverted */
+#define TCPC_MUX_USB_DEVICE_ENABLEDBIT(0) /* USB device enabled */
+#define TCPC_MUX_USB_HOST_ENABLED BIT(1) /* USB host enabled */
+#define TCPC_MUX_DP_SRC_ENABLEDBIT(2) /* DP enabled */
+#define TCPC_MUX_POLARITY_INVERTED BIT(3) /* Polarity inverted */
/* Mux modes, decoded to attributes */
enum tcpc_mux_mode {
- TYPEC_MUX_NONE = 0,/* Open switch */
- TYPEC_MUX_USB = TCPC_MUX_USB_ENABLED, /* USB only */
- TYPEC_MUX_DP= TCPC_MUX_DP_ENABLED, /* DP only */
- TYPEC_MUX_DOCK = TCPC_MUX_USB_ENABLED |/* Both USB and DP */
- TCPC_MUX_DP_ENABLED,
+ /* Open switch */
+ TYPEC_MUX_NONE = 0,
+ /* USB device only */
+ TYPEC_MUX_USB_DEVICE = TCPC_MUX_USB_DEVICE_ENABLED,
+ /* USB host only */
+ TYPEC_MUX_USB_HOST = TCPC_MUX_USB_HOST_ENABLED,
+ /* DP source only */
+ TYPEC_MUX_DP = TCPC_MUX_DP_SRC_ENABLED,
+ /* Both USB host and DP source */
+ TYPEC_MUX_DOCK = TCPC_MUX_USB_HOST_ENABLED | TCPC_MUX_DP_SRC_ENABLED,
};
struct tcpc_mux_dev {
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/intel_cht_int33fe.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 312d2472b8b3..830ff8d0a1eb 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -794,6 +794,7 @@ config ACPI_CMPC
config INTEL_CHT_INT33FE
tristate "Intel Cherry Trail ACPI INT33FE Driver"
depends on X86 && ACPI && I2C && REGULATOR
+ select MULTIPLEXER
---help---
This driver add support for the INT33FE ACPI device found on
some Intel Cherry Trail devices.
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index b2925d996613..89ba510dac78 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,6 +36,19 @@ struct cht_int33fe_data {
struct i2c_client *pi3usb30532;
};
+static struct mux_lookup cht_int33fe_mux_lookup[] = {
+ {
+ .provider = "i2c-pi3usb30532",
+ .dev_id = "i2c-fusb302",
+ .mux_name = "type-c-mode-mux",
+ },
+ {
+ .provider = "intel_cht_usb_mux",
+ .dev_id = "i2c-fusb302",
+ .mux_name = "usb-role-mux",
+ },
+};
+
/*
* Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
* the max17047 both through the INT33FE ACPI device (it is right there
@@ -177,6 +191,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
board_info.properties = fusb302_props;
board_info.irq = fusb302_irq;
+ mux_add_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
data->fusb302 = i2c_acpi_new_device(dev, 2, &board_info);
if (!data->fusb302)
goto out_unregister_max17047;
@@ -200,6 +217,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ mux_remove_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
}
@@ -212,6 +232,9 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ mux_remove_table(cht_int33fe_mux_lookup,
+ ARRAY_SIZE(cht_int33fe_mux_lookup));
+
return 0;
}
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
---
Changes in v3:
-Use new devm_mux_control_get_optional()
-Simplify tcpc_gen_mux_set as we now no longer need to worry about the muxes
being present
-Adjust for updated MUX_TYPEC_* defines
---
drivers/usb/typec/Makefile | 2 +-
drivers/usb/typec/tcpc_gen_mux.c | 122 +++
include/linux/usb/tcpm.h | 2 +
3 files changed, 125 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/typec/tcpc_gen_mux.c
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b77688ce1f16..95a7d9c4527b 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_TYPEC)+= typec.o
-obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
+obj-$(CONFIG_TYPEC_TCPM) += tcpm.o tcpc_gen_mux.o
obj-y += fusb302/
obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
obj-$(CONFIG_TYPEC_UCSI) += ucsi/
diff --git a/drivers/usb/typec/tcpc_gen_mux.c b/drivers/usb/typec/tcpc_gen_mux.c
new file mode 100644
index ..ea40b52ef6a6
--- /dev/null
+++ b/drivers/usb/typec/tcpc_gen_mux.c
@@ -0,0 +1,122 @@
+/*
+ * Generic TCPC mux driver using the mux subsys
+ *
+ * Copyright (c) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct tcpc_gen_mux_data {
+ struct tcpc_mux_dev mux;
+ struct device *dev;
+ struct mux_control *type_c_mode_mux; /* Type-C cross switch / mux */
+ struct mux_control *usb_role_mux;/* USB Device / Host mode mux */
+ bool muxes_set;
+};
+
+static int tcpc_gen_mux_set(struct tcpc_mux_dev *mux_dev,
+ enum tcpc_mux_mode mux_mode,
+ enum tcpc_usb_switch usb_config,
+ enum typec_cc_polarity polarity)
+{
+ struct tcpc_gen_mux_data *data =
+ container_of(mux_dev, struct tcpc_gen_mux_data, mux);
+ unsigned int typec_state = MUX_TYPEC_USB;
+ unsigned int usb_state = MUX_USB_DEVICE;
+ int ret;
+
+ /* Put the muxes back in their open (idle) state */
+ if (data->muxes_set) {
+ mux_control_deselect(data->type_c_mode_mux);
+ mux_control_deselect(data->usb_role_mux);
+ data->muxes_set = false;
+ }
+
+ switch (mux_mode) {
+ case TYPEC_MUX_NONE:
+ /* Muxes are in their open state, done. */
+ return 0;
+ case TYPEC_MUX_USB_DEVICE:
+ typec_state = MUX_TYPEC_USB;
+ usb_state = MUX_USB_DEVICE;
+ break;
+ case TYPEC_MUX_USB_HOST:
+ typec_state = MUX_TYPEC_USB;
+ usb_state = MUX_USB_HOST;
+ break;
+ case TYPEC_MUX_DP:
+ typec_state = MUX_TYPEC_DP;
+ break;
+ case TYPEC_MUX_DOCK:
+ typec_state = MUX_TYPEC_USB_AND_DP;
+ usb_state = MUX_USB_HOST;
+ break;
+ }
+
+ if (polarity)
+ typec_state |= MUX_TYPEC_POLARITY_INV;
+
+ ret = mux_control_select(data->type_c_mode_mux, typec_state);
+ if (ret) {
+ dev_err(data->dev, "Error setting Type-C mode mux: %d\n", ret);
+ return ret;
+ }
+
+ ret = mux_control_select(data->usb_role_mux, usb_state);
+ if (ret) {
+ dev_err(data->dev, "Error setting USB role mux: %d\n", ret);
+ mux_control_deselect(data->type_c_mode_mux);
+ return ret;
+ }
+
+ data->muxes_set = true;
+ return 0;
+}
+
+struct tcpc_mux_dev *devm_tcpc_gen_mux_create(struct device *dev)
+{
+ struct tcpc_gen_mux_data *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ /* The use of either mux is optional */
+ data->type_c_mode_mux =
+ devm_mux_control_get_optional(dev, "type-c-mode-mux");
+ if (IS_ERR(data->type_c_mode_mux)) {
+ ret = PTR_ERR(data->type_c_mode_mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Error getting Type-C mux: %d\n", ret);
+ return ERR_PTR(-ret);
+ }
+
+ data->usb_role_mux = devm_mux_control_get_optional(dev, "usb-role-mux");
+ if (IS_ERR(data->usb_role_mux)) {
+ ret = PTR_ERR(data->usb_role_mux);
+ if (ret != -EPR
[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 method) so things just work. But on other Cherrytrail systems we need to control the mux ourselves this driver exports the mux through the mux subsys, so that other drivers can control it if necessary. This driver also updates the vbus-valid reporting to the dwc3 gadget controller, as this uses the same registers as the mux. This is needed for gadget/device mode to work properly (even on systems which control the mux from their AML code). Note this depends on the xhci driver registering a platform device named "intel_cht_usb_mux", which has an IOMEM resource 0 which points to the Intel Vendor Defined XHCI extended capabilities region. Signed-off-by: Hans de Goede --- Changes in v2: -Complete rewrite as a stand-alone platform-driver rather then as a phy driver, since this is just a mux, not a phy Changes in v3: -Make this a mux subsys driver instead of listening to USB_HOST extcon cable events and responding to those Changes in v4 (of patch, v2 of new mux based series): -Rename C-file to use - in name -Add MAINTAINERS entry -Various code-style fixes Changes in v3 of new mux based series: -Various code-style fixes -Use new init_as_is mux flag --- MAINTAINERS | 5 + drivers/mux/Kconfig | 11 ++ drivers/mux/Makefile| 10 +- drivers/mux/intel-cht-usb-mux.c | 251 4 files changed, 273 insertions(+), 4 deletions(-) create mode 100644 drivers/mux/intel-cht-usb-mux.c diff --git a/MAINTAINERS b/MAINTAINERS index 04e7a5b9d6bd..6cfa0e5f2d2b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9176,6 +9176,11 @@ F: include/linux/dt-bindings/mux/ F: include/linux/mux/ F: drivers/mux/ +MULTIPLEXER SUBSYSTEM INTEL CHT USB MUX DRIVER +M: Hans de Goede +S: Maintained +F: drivers/mux/intel-cht-usb-mux.c + MULTISOUND SOUND DRIVER M: Andrew Veliath S: Maintained diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig index 19e4e904c9bf..ebc04ae7ff30 100644 --- a/drivers/mux/Kconfig +++ b/drivers/mux/Kconfig @@ -34,6 +34,17 @@ config MUX_GPIO To compile the driver as a module, choose M here: the module will be called mux-gpio. +config MUX_INTEL_CHT_USB_MUX + tristate "Intel Cherrytrail USB Multiplexer" + depends on ACPI && X86 && EXTCON + help + This driver adds support for the internal USB mux for muxing the OTG + USB data lines between the xHCI host controller and the dwc3 gadget + controller found on Intel Cherrytrail SoCs. + + To compile the driver as a module, choose M here: the module will + be called mux-intel-cht-usb-mux. + config MUX_MMIO tristate "MMIO register bitfield-controlled Multiplexer" depends on (OF && MFD_SYSCON) || COMPILE_TEST diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile index 0e1e59760e3f..6cf41be2754f 100644 --- a/drivers/mux/Makefile +++ b/drivers/mux/Makefile @@ -5,9 +5,11 @@ mux-core-objs := core.o mux-adg792a-objs := adg792a.o mux-gpio-objs := gpio.o +mux-intel-cht-usb-mux-objs := intel-cht-usb-mux.o mux-mmio-objs := mmio.o -obj-$(CONFIG_MULTIPLEXER) += mux-core.o -obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o -obj-$(CONFIG_MUX_GPIO) += mux-gpio.o -obj-$(CONFIG_MUX_MMIO) += mux-mmio.o +obj-$(CONFIG_MULTIPLEXER) += mux-core.o +obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o +obj-$(CONFIG_MUX_GPIO) += mux-gpio.o +obj-$(CONFIG_MUX_INTEL_CHT_USB_MUX)+= mux-intel-cht-usb-mux.o +obj-$(CONFIG_MUX_MMIO) += mux-mmio.o diff --git a/drivers/mux/intel-cht-usb-mux.c b/drivers/mux/intel-cht-usb-mux.c new file mode 100644 index ..726facefd479 --- /dev/null +++ b/drivers/mux/intel-cht-usb-mux.c @@ -0,0 +1,251 @@ +/* + * Intel Cherrytrail USB OTG MUX driver + * + * Copyright (c) 2016-2017 Hans de Goede + * + * Loosely based on android x86 kernel code which is: + * + * Copyright (C) 2014 Intel Corp. + * + * Author: Wu, Hao + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation, or (at your option) + * any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* register definition */ +#define DUAL_ROLE_CFG0 0x68 +#define SW_VBUS_VALID (1 << 24) +#define SW_IDPIN_EN(1 << 21) +#define SW_IDPIN (1 << 20) + +#define DUAL_ROL
[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 new init_as_is mux flag
-Adjust for updated MUX_TYPEC_* defines
---
MAINTAINERS | 5 +++
drivers/mux/Kconfig | 10 ++
drivers/mux/Makefile | 2 ++
drivers/mux/pi3usb30532.c | 92 +++
4 files changed, 109 insertions(+)
create mode 100644 drivers/mux/pi3usb30532.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 6cfa0e5f2d2b..5c844fd3a23c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9181,6 +9181,11 @@ M: Hans de Goede
S: Maintained
F: drivers/mux/intel-cht-usb-mux.c
+MULTIPLEXER SUBSYSTEM PI3USB30532 DRIVER
+M: Hans de Goede
+S: Maintained
+F: drivers/mux/pi3usb30532.c
+
MULTISOUND SOUND DRIVER
M: Andrew Veliath
S: Maintained
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index ebc04ae7ff30..f94660229d20 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -58,4 +58,14 @@ config MUX_MMIO
To compile the driver as a module, choose M here: the module will
be called mux-mmio.
+config MUX_PI3USB30532
+ tristate "Pericom PI3USB30532 Type-C cross switch driver"
+ depends on I2C
+ help
+ This driver adds support for the Pericom PI3USB30532 Type-C cross
+ switch / mux chip found on some devices with a Type-C port.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-pi3usb30532.
+
endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 6cf41be2754f..df381c219708 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -7,9 +7,11 @@ mux-adg792a-objs := adg792a.o
mux-gpio-objs := gpio.o
mux-intel-cht-usb-mux-objs := intel-cht-usb-mux.o
mux-mmio-objs := mmio.o
+mux-pi3usb30532-objs := pi3usb30532.o
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
obj-$(CONFIG_MUX_INTEL_CHT_USB_MUX)+= mux-intel-cht-usb-mux.o
obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
+obj-$(CONFIG_MUX_PI3USB30532) += mux-pi3usb30532.o
diff --git a/drivers/mux/pi3usb30532.c b/drivers/mux/pi3usb30532.c
new file mode 100644
index ..13c7c4ec0047
--- /dev/null
+++ b/drivers/mux/pi3usb30532.c
@@ -0,0 +1,92 @@
+/*
+ * Pericom PI3USB30532 Type-C cross switch / mux driver
+ *
+ * Copyright (c) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define PI3USB30532_CONF 0x00
+
+#define PI3USB30532_CONF_OPEN 0x00
+#define PI3USB30532_CONF_SWAP 0x01
+#define PI3USB30532_CONF_4LANE_DP 0x02
+#define PI3USB30532_CONF_USB3 0x04
+#define PI3USB30532_CONF_USB3_AND_2LANE_DP 0x06
+
+static int pi3usb30532_set_mux(struct mux_control *mux, int state)
+{
+ struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
+ u8 conf = PI3USB30532_CONF_OPEN;
+
+ if (state == MUX_IDLE_DISCONNECT)
+ return i2c_smbus_write_byte_data(i2c, PI3USB30532_CONF, conf);
+
+ switch (state & ~MUX_TYPEC_POLARITY_INV) {
+ case MUX_TYPEC_USB:
+ conf = PI3USB30532_CONF_USB3;
+ break;
+ case MUX_TYPEC_USB_AND_DP:
+ conf = PI3USB30532_CONF_USB3_AND_2LANE_DP;
+ break;
+ case MUX_TYPEC_DP:
+ conf = PI3USB30532_CONF_4LANE_DP;
+ break;
+ }
+
+ if (state & MUX_TYPEC_POLARITY_INV)
+ conf |= PI3USB30532_CONF_SWAP;
+
+ return i2c_smbus_write_byte_data(i2c, PI3USB30532_CONF, conf);
+}
+
+static const struct mux_control_ops pi3usb30532_ops = {
+ .set = pi3usb30532_set_mux,
+};
+
+static int pi3usb30532_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct mux_chip *mux_chip;
+
+ mux_chip = devm_mux_chip_alloc(dev, 1, 0);
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ mux_chip->ops = &pi3usb30532_ops;
+ mux_chip->mux[0].idle_state = MUX_IDLE_DISCONNECT;
+ /* Keep initial state as is, for e.g. booting from an USB disk */
+ mux_chip->mux[0].init_as_is = true;
+ mux_chip->mux[0].states = MUX_TYPEC_STATES;
+
+ return devm_mux_chip_register(dev, mux_chip);
+}
+
+static const struct i2c_device_id pi3usb30532_table[] = {
+ { "pi
[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
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans de Goede
---
Changes in v3:
-Drop devicetree bindings documentation, since this is only used with
device-properties set by platform code on X86/ACPI now, we don't need
bindings yet
---
drivers/usb/typec/fusb302/fusb302.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index e790b67d4953..10415d6b2292 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1259,7 +1259,6 @@ static void init_tcpc_dev(struct tcpc_dev
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
fusb302_tcpc_dev->pd_transmit = tcpm_pd_transmit;
- fusb302_tcpc_dev->mux = NULL;
}
static const char * const cc_polarity_name[] = {
@@ -1817,6 +1816,10 @@ static int fusb302_probe(struct i2c_client *client,
return -EPROBE_DEFER;
}
+ chip->tcpc_dev.mux = devm_tcpc_gen_mux_create(dev);
+ if (IS_ERR(chip->tcpc_dev.mux))
+ return PTR_ERR(chip->tcpc_dev.mux);
+
cfg.drv_data = chip;
chip->psy = devm_power_supply_register(dev, &fusb302_psy_desc, &cfg);
if (IS_ERR(chip->psy)) {
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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:
rtl8192_usb_probe
--> rtl8192_init
--> rtl8192_usb_initendpoints
Signed-off-by: Christophe JAILLET
---
The error handling path in 'rtl8192_usb_probe' must also be fixed because
it is bogus. Will do that in another patch.
---
drivers/staging/rtl8192u/r8192U_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 46b3f19e0878..48b7fd071900 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1687,9 +1687,13 @@ static short rtl8192_usb_initendpoints(struct net_device
*dev)
#ifndef JACKSON_NEW_RX
for (i = 0; i < (MAX_RX_URB + 1); i++) {
priv->rx_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
+ if (!priv->rx_urb[i])
+ return -ENOMEM;
priv->rx_urb[i]->transfer_buffer =
kmalloc(RX_URB_SIZE, GFP_KERNEL);
+ if (!priv->rx_urb[i]->transfer_buffer)
+ return -ENOMEM;
priv->rx_urb[i]->transfer_buffer_length = RX_URB_SIZE;
}
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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 code is also duplicated in 'rtl8192_init()' and in
'rtl8192_usb_prob()'. This looks harmless because the freed pointers are
set to NULL but it looks confusing.
Fix all that by just moving the 'fail' label and removing duplicated
error handling code from 'rtl8192_ini()'. All this resources freeing will
be handled by 'rtl8192_usb_prob()' directly.
The calling graph is:
rtl8192_usb_probe
--> rtl8192_init
--> rtl8192_usb_initendpoints
Signed-off-by: Christophe JAILLET
---
This patch is compile tested and the corresponding looks a bit tricky.
So, review carefully :)
---
drivers/staging/rtl8192u/r8192U_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 48b7fd071900..8701ce25abe4 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2694,9 +2694,6 @@ static short rtl8192_init(struct net_device *dev)
err = rtl8192_read_eeprom_info(dev);
if (err) {
DMESG("Reading EEPROM info failed");
- kfree(priv->pFirmware);
- priv->pFirmware = NULL;
- free_ieee80211(dev);
return err;
}
rtl8192_get_channel_map(dev);
@@ -4998,11 +4995,11 @@ static int rtl8192_usb_probe(struct usb_interface *intf,
fail2:
rtl8192_down(dev);
+fail:
kfree(priv->pFirmware);
priv->pFirmware = NULL;
rtl8192_usb_deleteendpoints(dev);
mdelay(10);
-fail:
free_ieee80211(dev);
RT_TRACE(COMP_ERR, "wlan driver load failed\n");
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 yourself with 'please drop
this patch' (this lets
maintainers know to not worry further with it). Then submit the patch again
without the
'In-Reply-To' header i.e send the patch with `git send-email`. You don't need
v1 in the subject for
version 1, that is implicit.
On Thu, Sep 14, 2017 at 06:34:20PM -0700, Valentine Sinitsyn wrote:
> rtl8188eu contains some spelling errors in comment lines as well as in
> constants. Harmless as they are, they still make the code feel a bit
> unclean, which is not something we want in the kernel.
Nice description.
> Improve this by fixing typos so they won't catch eyes of future driver
> developers anymore.
This would be better in imperative mood i.e "Fix typos so they won't catch the
eyes of future
developers."
> Signed-off-by: Wolfgang Hartmann
> Signed-off-by: Manish Shrestha
> Signed-off-by: Valentine Sinitsyn
Reviewed-by: Tobin C. Harding
> ---
> drivers/staging/rtl8188eu/core/rtw_efuse.c| 2 +-
> drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
> drivers/staging/rtl8188eu/hal/odm_HWConfig.c | 4 ++--
> drivers/staging/rtl8188eu/include/odm.h | 2 +-
> drivers/staging/rtl8188eu/include/rtl8188e_spec.h | 4 ++--
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c
> b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> index b9bdff0..2c4c8c4 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> @@ -48,7 +48,7 @@ void Efuse_PowerSwitch(
> if (PwrState) {
> usb_write8(pAdapter, REG_EFUSE_ACCESS, EFUSE_ACCESS_ON);
>
> - /* 1.2V Power: From VDDON with Power Cut(0xh[15]), defualt
> valid */
> + /* 1.2V Power: From VDDON with Power Cut(0xh[15]), default
> valid */
> tmpV16 = usb_read16(pAdapter, REG_SYS_ISO_CTRL);
> if (!(tmpV16 & PWC_EV12V)) {
> tmpV16 |= PWC_EV12V;
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> index f663e6c..0d2381d 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> @@ -1329,7 +1329,7 @@ void rtw_cpwm_event_callback(struct adapter *padapter,
> u8 *pbuf)
> }
>
> /*
> - * _rtw_join_timeout_handler - Timeout/faliure handler for CMD JoinBss
> + * _rtw_join_timeout_handler - Timeout/failure handler for CMD JoinBss
> * @adapter: pointer to struct adapter structure
> */
> void _rtw_join_timeout_handler (unsigned long data)
> diff --git a/drivers/staging/rtl8188eu/hal/odm_HWConfig.c
> b/drivers/staging/rtl8188eu/hal/odm_HWConfig.c
> index 0555e42..5fcbe56 100644
> --- a/drivers/staging/rtl8188eu/hal/odm_HWConfig.c
> +++ b/drivers/staging/rtl8188eu/hal/odm_HWConfig.c
> @@ -109,7 +109,7 @@ static void odm_RxPhyStatus92CSeries_Parsing(struct
> odm_dm_struct *dm_odm,
>
> dm_odm->PhyDbgInfo.NumQryPhyStatusCCK++;
> /* (1)Hardware does not provide RSSI for CCK */
> - /* (2)PWDB, Average PWDB cacluated by hardware (for rate
> adaptive) */
> + /* (2)PWDB, Average PWDB calculated by hardware (for rate
> adaptive) */
>
> cck_highpwr = dm_odm->bCckHighPower;
>
> @@ -223,7 +223,7 @@ static void odm_RxPhyStatus92CSeries_Parsing(struct
> odm_dm_struct *dm_odm,
> pPhyInfo->RxSNR[i] = (s32)(pPhyStaRpt->path_rxsnr[i]/2);
> dm_odm->PhyDbgInfo.RxSNRdB[i] =
> (s32)(pPhyStaRpt->path_rxsnr[i]/2);
> }
> - /* (2)PWDB, Average PWDB cacluated by hardware (for rate
> adaptive) */
> + /* (2)PWDB, Average PWDB calculated by hardware (for rate
> adaptive) */
> rx_pwr_all = (((pPhyStaRpt->cck_sig_qual_ofdm_pwdb_all) >> 1) &
> 0x7f) - 110;
>
> PWDB_ALL = odm_QueryRxPwrPercentage(rx_pwr_all);
> diff --git a/drivers/staging/rtl8188eu/include/odm.h
> b/drivers/staging/rtl8188eu/include/odm.h
> index 4fb3bb0..50e2673 100644
> --- a/drivers/staging/rtl8188eu/include/odm.h
> +++ b/drivers/staging/rtl8188eu/include/odm.h
> @@ -478,7 +478,7 @@ enum odm_operation_mode {
>
> /* ODM_CMNINFO_WM_MODE */
> enum odm_wireless_mode {
> - ODM_WM_UNKNOW = 0x0,
> + ODM_WM_UNKNOWN = 0x0,
> ODM_WM_B= BIT(0),
> ODM_WM_G= BIT(1),
> ODM_WM_A= BIT(2),
> diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
> b/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
> index c93e19d..c33d312 100644
> --- a/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
> +++ b/drivers/staging/rtl8188eu/
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
