[PATCH 0/1] Fix cast to restricted __le16 in ks7010 driver

[PATCH 0/1] Fix cast to restricted __le16 in ks7010 driver

[Janusz Lisiecki]

This patch fixes Sparse warining found in ks_wlan_net.c. This seems
to be last of it reported by Sparse for that driver. 

Janusz Lisiecki (1):
  staging: ks7010: Fix warning of cast to restricted __le16 in
    ks_wlan_net.c

 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
Both sides of assignment are u16 so (as 'ap' is local_ap_t type and 'capability' member,
have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not needed

Signed-off-by: Janusz Lisiecki <janusz.lisiecki@gmail.com>
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c b/drivers/staging/ks7010/ks_wlan_net.c
index 0c778aa..9a7fbe2 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -1356,7 +1356,7 @@ static inline char *ks_wlan_translate_scan(struct net_device *dev,
 
 	/* Add mode */
 	iwe.cmd = SIOCGIWMODE;
-	capabilities = le16_to_cpu(ap->capability);
+	capabilities = ap->capability;
 	if (capabilities & (BSS_CAP_ESS | BSS_CAP_IBSS)) {
 		if (capabilities & BSS_CAP_ESS)
 			iwe.u.mode = IW_MODE_INFRA;
-- 
1.9.1

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Luc Van Oostenryck]

On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
<janusz.lisiecki@gmail.com> wrote:
> This patch fixes the following Sparse warnings in ks_wlan_net.c:
> drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
> Both sides of assignment are u16 so (as 'ap' is local_ap_t type and 'capability' member,
> have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not needed

It could be that it's ap->capability's type that is wrong (not
annotated with __le16).
Isn't it?

Is ap->capability supposed to hold a little-endian value or a native
order value?

-- Luc

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

W dniu 2017-07-02 o 21:38, Luc Van Oostenryck pisze:
> On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
> <janusz.lisiecki@gmail.com> wrote:
>> This patch fixes the following Sparse warnings in ks_wlan_net.c:
>> drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
>> Both sides of assignment are u16 so (as 'ap' is local_ap_t type and 'capability' member,
>> have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not needed
> It could be that it's ap->capability's type that is wrong (not
> annotated with __le16).
> Isn't it?
>
> Is ap->capability supposed to hold a little-endian value or a native
> order value?
>
> -- Luc
As I see in ks_hostif.c all assignments to link_ap_info_t->capability 
threat this value as native order (i.e get_ap_information, 
get_current_ap). As this is not a structure which comes from HW we can 
do the way you suggested. Still, as all other places in code threats 
this as native order value I decided to change only one place than many 
other around to fix Sparse warning.

Pozdrawiam,
Janusz Lisiecki

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Luc Van Oostenryck]

On Sun, Jul 2, 2017 at 10:49 PM, Janusz Lisiecki
<janusz.lisiecki@gmail.com> wrote:
> W dniu 2017-07-02 o 21:38, Luc Van Oostenryck pisze:
>
>> On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
>> <janusz.lisiecki@gmail.com> wrote:
>>>
>>> This patch fixes the following Sparse warnings in ks_wlan_net.c:
>>> drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted
>>> __le16
>>> Both sides of assignment are u16 so (as 'ap' is local_ap_t type and
>>> 'capability' member,
>>> have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not
>>> needed
>>
>> It could be that it's ap->capability's type that is wrong (not
>> annotated with __le16).
>> Isn't it?
>>
>> Is ap->capability supposed to hold a little-endian value or a native
>> order value?
>>
>> -- Luc
>
> As I see in ks_hostif.c all assignments to link_ap_info_t->capability threat
> this value as native order (i.e get_ap_information, get_current_ap). As this
> is not a structure which comes from HW we can do the way you suggested.
> Still, as all other places in code threats this as native order value I
> decided to change only one place than many other around to fix Sparse
> warning.

Fine, but then please put this explanation in the commit message.
In others words, be very clear that the change is because ap->capability is in
native order and thus the conversion le16_to_cpu() is wrong and must be removed.

-- Luc

[PATCH 0/1] Fix cast to restricted __le16 in ks7010 driver

[Janusz Lisiecki]

This patch fixes Sparse warining found in ks_wlan_net.c. This seems
to be last of it reported by Sparse for that driver.
link_ap_info_t structure field 'capability' has native order and is
used everywhere in the code in such way (i.e get_ap_information,
get_current_ap), so le16_to_cpu() on it is wrong and must be removed.
As this is not HW related structure we are free to choose its byte
order and it is easier just to remove one wrong casting than rework
all other places to treat it as __le16.

Janusz Lisiecki (1):
  staging: ks7010: Fix warning of cast to restricted __le16 in
    ks_wlan_net.c

 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

This patch fixes the following Sparse warnings in ks_wlan_net.c:
drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted __le16
link_ap_info_t structure field 'capability' has native order and is used everywhere
in the code in such way (i.e get_ap_information, get_current_ap). Both sides of
assignment are u16 (native order) so 'le16_to_cpu' is not needed and wrong.

Signed-off-by: Janusz Lisiecki <janusz.lisiecki@gmail.com>
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c b/drivers/staging/ks7010/ks_wlan_net.c
index 0c778aa..9a7fbe2 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -1356,7 +1356,7 @@ static inline char *ks_wlan_translate_scan(struct net_device *dev,
 
 	/* Add mode */
 	iwe.cmd = SIOCGIWMODE;
-	capabilities = le16_to_cpu(ap->capability);
+	capabilities = ap->capability;
 	if (capabilities & (BSS_CAP_ESS | BSS_CAP_IBSS)) {
 		if (capabilities & BSS_CAP_ESS)
 			iwe.u.mode = IW_MODE_INFRA;
-- 
1.9.1

Re: [PATCH 1/1] staging: ks7010: Fix cast to restricted __le16 in ks_wlan_net.c

[Janusz Lisiecki]

W dniu 2017-07-02 o 23:23, Luc Van Oostenryck pisze:
> On Sun, Jul 2, 2017 at 10:49 PM, Janusz Lisiecki
> <janusz.lisiecki@gmail.com> wrote:
>> W dniu 2017-07-02 o 21:38, Luc Van Oostenryck pisze:
>>
>>> On Sun, Jul 2, 2017 at 4:27 PM, Janusz Lisiecki
>>> <janusz.lisiecki@gmail.com> wrote:
>>>> This patch fixes the following Sparse warnings in ks_wlan_net.c:
>>>> drivers/staging/ks7010/ks_wlan_net.c:1359:24: warning: cast to restricted
>>>> __le16
>>>> Both sides of assignment are u16 so (as 'ap' is local_ap_t type and
>>>> 'capability' member,
>>>> have the same as local 'capabilities' type of u16) 'le16_to_cpu' is not
>>>> needed
>>> It could be that it's ap->capability's type that is wrong (not
>>> annotated with __le16).
>>> Isn't it?
>>>
>>> Is ap->capability supposed to hold a little-endian value or a native
>>> order value?
>>>
>>> -- Luc
>> As I see in ks_hostif.c all assignments to link_ap_info_t->capability threat
>> this value as native order (i.e get_ap_information, get_current_ap). As this
>> is not a structure which comes from HW we can do the way you suggested.
>> Still, as all other places in code threats this as native order value I
>> decided to change only one place than many other around to fix Sparse
>> warning.
> Fine, but then please put this explanation in the commit message.
> In others words, be very clear that the change is because ap->capability is in
> native order and thus the conversion le16_to_cpu() is wrong and must be removed.
>
> -- Luc
Done. I hope my message is more verbose and clear this time.

Pozdrawiam,
Janusz Lisiecki


Pozdrawiam,
Janusz Lisiecki