Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-04-10 Thread perry 
Hi Dan,

Can you clarify why the rx_buffer always holds little-endian data? It looks to 
me like this buffer is filled by
wilc_sdio_cmd53(), which uses sdio_memcpy_toio(), which ultimately sets the 
data with sg_set_buf(). This function
appears to use host-endian byte ordering.

Regards,
Perry

On Fri, 2017-03-24 at 11:57 +0300, Dan Carpenter wrote:
> On Thu, Mar 23, 2017 at 04:15:06PM -0600, Robert Perry Hooker wrote:
> > Well, yes, all data is 'endian' one way or another, right? I guess the byte 
> > order of the tx/rx_buffers is host
> > -endian
> > (which could be big), or _maybe_ network-endian...
> 
> The good news is this code is Open Source[tm] so we don't need to guess.
> It's full of little endian data.
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: use __le16_to_cpu instead of cast

2017-03-12 Thread Perry Hooker 
This patch fixes the following sparse warnings:
drivers/staging/rtl8192u/r8192U_dm.c:2307:49: warning: cast from restricted 
__le16
drivers/staging/rtl8192u/r8192U_dm.c:2308:44: warning: cast from restricted 
__le16
drivers/staging/rtl8192u/r8192U_dm.c:2309:44: warning: cast from restricted 
__le16

Signed-off-by: Perry Hooker 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 9209aad..33d105d 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -2304,9 +2304,9 @@ static void dm_check_edca_turbo(
/*  For Each time updating EDCA parameter, 
reset EDCA turbo mode status. */
dm_init_edca_turbo(dev);
u1bAIFS = qos_parameters->aifs[0] * 
((mode&(IEEE_G|IEEE_N_24G)) ? 9 : 20) + aSifsTime;
-   u4bAcParam = 
(((u32)(qos_parameters->tx_op_limit[0])) << AC_PARAM_TXOP_LIMIT_OFFSET)|
-   (((u32)(qos_parameters->cw_max[0])) << 
AC_PARAM_ECW_MAX_OFFSET)|
-   (((u32)(qos_parameters->cw_min[0])) << 
AC_PARAM_ECW_MIN_OFFSET)|
+   u4bAcParam = 
(((u32)__le16_to_cpu(qos_parameters->tx_op_limit[0])) << 
AC_PARAM_TXOP_LIMIT_OFFSET) |
+   
(((u32)__le16_to_cpu(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET) |
+   
(((u32)__le16_to_cpu(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET) |
((u32)u1bAIFS << AC_PARAM_AIFS_OFFSET);
/*write_nic_dword(dev, WDCAPARA_ADD[i], 
u4bAcParam);*/
write_nic_dword(dev, EDCAPARA_BE,  u4bAcParam);
-- 
2.4.11

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-21 Thread Perry Hooker 
This commit fixes the following sparse warnings:
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: incorrect 
type in argument 1 (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: incorrect 
type in assignment (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: incorrect 
type in assignment (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: incorrect 
type in assignment (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: incorrect 
type in assignment (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: incorrect 
type in assignment (different base types)
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: incorrect 
type in assignment (different base types)

Signed-off-by: Perry Hooker 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a37896f..d1c75c7 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, 
u32 size)
} else {
s32Freq = ieee80211_channel_to_frequency(curr_channel, 
NL80211_BAND_2GHZ);
 
-   if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
+   if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
if (priv->bCfgScanning && time_after_eq(jiffies, 
(unsigned long)pstrWFIDrv->p2p_timeout)) {
netdev_dbg(dev, "Receiving action wrong ch\n");
return;
@@ -2003,13 +2003,16 @@ static int add_station(struct wiphy *wiphy, struct 
net_device *dev,
strStaParams.ht_supported = false;
} else {
strStaParams.ht_supported = true;
-   strStaParams.ht_capa_info = params->ht_capa->cap_info;
+   strStaParams.ht_capa_info =
+   le16_to_cpu(params->ht_capa->cap_info);
strStaParams.ht_ampdu_params = 
params->ht_capa->ampdu_params_info;
memcpy(strStaParams.ht_supp_mcs_set,
   ¶ms->ht_capa->mcs,
   WILC_SUPP_MCS_SET_SIZE);
-   strStaParams.ht_ext_params = 
params->ht_capa->extended_ht_cap_info;
-   strStaParams.ht_tx_bf_cap = 
params->ht_capa->tx_BF_cap_info;
+   strStaParams.ht_ext_params =
+   
le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+   strStaParams.ht_tx_bf_cap =
+   le32_to_cpu(params->ht_capa->tx_BF_cap_info);
strStaParams.ht_ante_sel = 
params->ht_capa->antenna_selection_info;
}
 
@@ -2075,13 +2078,16 @@ static int change_station(struct wiphy *wiphy, struct 
net_device *dev,
strStaParams.ht_supported = false;
} else {
strStaParams.ht_supported = true;
-   strStaParams.ht_capa_info = params->ht_capa->cap_info;
+   strStaParams.ht_capa_info =
+   le16_to_cpu(params->ht_capa->cap_info);
strStaParams.ht_ampdu_params = 
params->ht_capa->ampdu_params_info;
memcpy(strStaParams.ht_supp_mcs_set,
   ¶ms->ht_capa->mcs,
   WILC_SUPP_MCS_SET_SIZE);
-   strStaParams.ht_ext_params = 
params->ht_capa->extended_ht_cap_info;
-   strStaParams.ht_tx_bf_cap = 
params->ht_capa->tx_BF_cap_info;
+   strStaParams.ht_ext_params =
+   
le16_to_cpu(params->ht_capa->extended_ht_cap_info);
+   strStaParams.ht_tx_bf_cap =
+   le32_to_cpu(params->ht_capa->tx_BF_cap_info);
strStaParams.ht_ante_sel = 
params->ht_capa->antenna_selection_info;
}
 
-- 
2.4.11

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ks7010: use little-endian types

2017-06-08 Thread Perry Hooker 
This patch fixes a number of sparse warnings of the form:
drivers/staging/ks7010/ks_hostif.c:2187:29:
warning: incorrect type in assignment (different base types)
generated when storing little-endian data in variables
that do not have a specified endianness.

Signed-off-by: Perry Hooker 
---
 drivers/staging/ks7010/ks_hostif.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 697347b..db01a48 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1821,7 +1821,7 @@ void hostif_receive(struct ks_wlan_private *priv, 
unsigned char *p,
 static
 void hostif_sme_set_wep(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_WEP_INDEX_REQUEST:
@@ -1870,13 +1870,13 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv, 
int type)
 }
 
 struct wpa_suite_t {
-   unsigned short size;
+   __le16 size;
unsigned char suite[4][CIPHER_ID_LEN];
 } __packed;
 
 struct rsn_mode_t {
-   u32 rsn_mode;
-   u16 rsn_capability;
+   __le32 rsn_mode;
+   __le16 rsn_capability;
 } __packed;
 
 static
@@ -1884,7 +1884,7 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 {
struct wpa_suite_t wpa_suite;
struct rsn_mode_t rsn_mode;
-   u32 val;
+   __le32 val;
 
memset(&wpa_suite, 0, sizeof(wpa_suite));
 
@@ -1936,7 +1936,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_UNICAST_CIPHER,
   sizeof(wpa_suite.size) +
-  CIPHER_ID_LEN * wpa_suite.size,
+  CIPHER_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, &wpa_suite);
break;
case SME_RSN_MCAST_REQUEST:
@@ -2028,7 +2029,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_AUTH_SUITE,
   sizeof(wpa_suite.size) +
-  KEY_MGMT_ID_LEN * wpa_suite.size,
+  KEY_MGMT_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, &wpa_suite);
break;
case SME_RSN_ENABLED_REQUEST:
@@ -2165,7 +2167,7 @@ void hostif_sme_multicast_set(struct ks_wlan_private 
*priv)
int mc_count;
struct netdev_hw_addr *ha;
char set_address[NIC_MAX_MCAST_LIST * ETH_ALEN];
-   unsigned long filter_type;
+   __le32 filter_type;
int i = 0;
 
DPRINTK(3, "\n");
@@ -2276,7 +2278,7 @@ void hostif_sme_sleep_set(struct ks_wlan_private *priv)
 static
 void hostif_sme_set_key(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_SET_FLAG:
@@ -2335,7 +2337,7 @@ static
 void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 {
struct pmk_cache_t {
-   u16 size;
+   __le16 size;
struct {
u8 bssid[ETH_ALEN];
u8 pmkid[IW_PMKID_LEN];
@@ -2366,7 +2368,7 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 static
 void hostif_sme_execute(struct ks_wlan_private *priv, int event)
 {
-   u32 val;
+   __le32 val;
 
DPRINTK(3, "event=%d\n", event);
switch (event) {
-- 
2.4.11

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lustre: libcfs: move assignment out of if condition

2015-07-12 Thread Perry Hooker 
Found by checkpatch.pl

Signed-off-by: Perry Hooker 
---
 drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..133ff34 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,8 +79,9 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
 {
int ret = 0;
 
-   if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
+   ret = __cfs_fail_check_set(id, value, set);
+
+   if (unlikely(CFS_FAIL_PRECHECK(id) && ret)) {
if (quiet) {
CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
   id, value);
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out of if condition

2015-07-12 Thread Perry Hooker 

Thank you - you're right. Apologies for the mistake.

On 07/12/2015 07:20 PM, Patrick Farrell wrote:

This changes the logic here;  the assignment is done conditionally based on the 
precheck.

From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry 
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 4:27 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com; 
gre...@linuxfoundation.org; de...@driverdev.osuosl.org; 
hpdd-disc...@lists.01.org
Cc: Perry Hooker
Subject: [HPDD-discuss] [PATCH] staging: lustre: libcfs: move assignment out
of if condition

Found by checkpatch.pl

Signed-off-by: Perry Hooker 
---
  drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..133ff34 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,8 +79,9 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
  {
 int ret = 0;

-   if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
+   ret = __cfs_fail_check_set(id, value, set);
+
+   if (unlikely(CFS_FAIL_PRECHECK(id) && ret)) {
 if (quiet) {
 CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
id, value);
--
2.1.4

___
HPDD-discuss mailing list
hpdd-disc...@lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lustre: libcfs: move assignment out of conditional

2015-07-12 Thread Perry Hooker 
Found by checkpatch.pl

Signed-off-by: Perry Hooker 

 Please enter the commit message for your changes. Lines starting
---
 .../staging/lustre/include/linux/libcfs/libcfs_fail.h  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..aa69c6a 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,14 +79,16 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
 {
int ret = 0;
 
-   if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
-   if (quiet) {
-   CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
-  id, value);
-   } else {
-   LCONSOLE_INFO("*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
+   if (unlikely(CFS_FAIL_PRECHECK(id))) {
+   ret = __cfs_fail_check_set(id, value, set);
+   if (ret) {
+   if (quiet) {
+   CDEBUG(D_INFO, "*** cfs_fail_loc=%x, 
val=%u***\n",
+  id, value);
+   } else {
+   LCONSOLE_INFO("*** cfs_fail_loc=%x, 
val=%u***\n",
+ id, value);
+   }
}
}
 
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3] staging: lustre: libcfs: move assignment out of conditional

2015-07-13 Thread Perry Hooker 
Found by checkpatch.pl

Signed-off-by: Perry Hooker 
---
 .../staging/lustre/include/linux/libcfs/libcfs_fail.h  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
index eea55d9..aa69c6a 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h
@@ -79,14 +79,16 @@ static inline int cfs_fail_check_set(__u32 id, __u32 value,
 {
int ret = 0;
 
-   if (unlikely(CFS_FAIL_PRECHECK(id) &&
-(ret = __cfs_fail_check_set(id, value, set {
-   if (quiet) {
-   CDEBUG(D_INFO, "*** cfs_fail_loc=%x, val=%u***\n",
-  id, value);
-   } else {
-   LCONSOLE_INFO("*** cfs_fail_loc=%x, val=%u***\n",
- id, value);
+   if (unlikely(CFS_FAIL_PRECHECK(id))) {
+   ret = __cfs_fail_check_set(id, value, set);
+   if (ret) {
+   if (quiet) {
+   CDEBUG(D_INFO, "*** cfs_fail_loc=%x, 
val=%u***\n",
+  id, value);
+   } else {
+   LCONSOLE_INFO("*** cfs_fail_loc=%x, 
val=%u***\n",
+ id, value);
+   }
}
}
 
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: r8712u: remove unnecessary le32_to_cpu

2017-02-09 Thread Perry Hooker 
This patch fixes the following sparse warning:
drivers/staging/rtl8712/usb_ops_linux.c:212:33: warning: cast to restricted 
__le32

Signed-off-by: Perry Hooker 
---
 drivers/staging/rtl8712/usb_ops_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/usb_ops_linux.c 
b/drivers/staging/rtl8712/usb_ops_linux.c
index fc6bb0b..259ef8f 100644
--- a/drivers/staging/rtl8712/usb_ops_linux.c
+++ b/drivers/staging/rtl8712/usb_ops_linux.c
@@ -209,7 +209,7 @@ static void r8712_usb_read_port_complete(struct urb *purb)
 
precvbuf->transfer_len = purb->actual_length;
pbuf = (uint *)precvbuf->pbuf;
-   isevt = le32_to_cpu(*(pbuf + 1)) & 0x1ff;
+   isevt = *(pbuf + 1) & 0x1ff;
if ((isevt & 0x1ff) == 0x1ff) {
r8712_rxcmd_event_hdl(padapter, pbuf);
skb_queue_tail(&precvpriv->rx_skb_queue, pskb);
-- 
2.4.11

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: r8712u: use __le32 type for little-endian data

2017-02-10 Thread Perry Hooker 
This patch fixes the following sparse warning:
drivers/staging/rtl8712/usb_ops_linux.c:212:33: warning: cast to restricted 
__le32

Signed-off-by: Perry Hooker 
---
 drivers/staging/rtl8712/usb_ops_linux.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/usb_ops_linux.c 
b/drivers/staging/rtl8712/usb_ops_linux.c
index fc6bb0b..df7c1aa 100644
--- a/drivers/staging/rtl8712/usb_ops_linux.c
+++ b/drivers/staging/rtl8712/usb_ops_linux.c
@@ -192,7 +192,8 @@ void r8712_usb_write_mem(struct intf_hdl *pintfhdl, u32 
addr, u32 cnt, u8 *wmem)
 
 static void r8712_usb_read_port_complete(struct urb *purb)
 {
-   uint isevt, *pbuf;
+   __le32 *pbuf;
+   uint isevt;
struct recv_buf *precvbuf = (struct recv_buf *)purb->context;
struct _adapter *padapter = (struct _adapter *)precvbuf->adapter;
struct recv_priv *precvpriv = &padapter->recvpriv;
@@ -208,7 +209,7 @@ static void r8712_usb_read_port_complete(struct urb *purb)
_pkt *pskb = precvbuf->pskb;
 
precvbuf->transfer_len = purb->actual_length;
-   pbuf = (uint *)precvbuf->pbuf;
+   pbuf = (__le32 *)precvbuf->pbuf;
isevt = le32_to_cpu(*(pbuf + 1)) & 0x1ff;
if ((isevt & 0x1ff) == 0x1ff) {
r8712_rxcmd_event_hdl(padapter, pbuf);
-- 
2.4.11

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8712u: remove unnecessary le32_to_cpu

2017-02-10 Thread Perry Hooker 
Ouch. My apologies. I'll take more care next time. I've supplied an
updated patch that uses the __le32 type for *(pbuf + 1).

On Fri, Feb 10, 2017 at 8:07 AM, Larry Finger  wrote:
> On 02/10/2017 08:58 AM, Greg KH wrote:
>>
>> On Fri, Feb 10, 2017 at 08:52:12AM -0600, Larry Finger wrote:
>>>
>>> On 02/10/2017 08:08 AM, Greg KH wrote:
>>>>
>>>> On Thu, Feb 09, 2017 at 08:51:55PM -0700, Perry Hooker wrote:
>>>>>
>>>>> This patch fixes the following sparse warning:
>>>>> drivers/staging/rtl8712/usb_ops_linux.c:212:33: warning: cast to
>>>>> restricted __le32
>>>>>
>>>>> Signed-off-by: Perry Hooker 
>>>>> ---
>>>>>  drivers/staging/rtl8712/usb_ops_linux.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>>
>>>> Does not apply to my tree :(
>>>
>>>
>>> That is good. Yes the patch silenced the Sparse warning, but it would
>>> BREAK
>>> the driver on every big-endian machine. Variable pbuf is a pointer to a
>>> string of bytes *in little-endian order* that is to be converted into a
>>> cpu-ordered 32-bit quantity. The correct way to silence the warning is to
>>> make sure the compiler understands what *(pbuf + 1) really is.
>>>
>>> BTW, that driver has been tested on BE hardware. Please be careful about
>>> endian changes.
>>>
>>> NACK.
>>
>>
>> Care to comment this somehow so that I don't accidentally take a patch
>> for this in the future?
>
>
> My recollection is that a number of patches had been submitted to clean up
> the endian warnings, but I do not remember the details.
>
> I will try to reproduce those again, and get them resubmitted to clean up
> the warnings in a manner that does not break the driver. I do have a BE
> machine for testing.
>
> Larry
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8712u: use __le32 type for little-endian data

2017-02-11 Thread Perry Hooker 
Thank you all for taking the time to look at this. I'm sorry for
filling your inboxes with my mistakes - as you probably guessed, I'm
new to kernel development, so I really appreciate the feedback.

Perry

On Fri, Feb 10, 2017 at 1:55 PM, Larry Finger  wrote:
> On 02/10/2017 12:23 PM, Perry Hooker wrote:
>>
>> This patch fixes the following sparse warning:
>> drivers/staging/rtl8712/usb_ops_linux.c:212:33: warning: cast to
>> restricted __le32
>>
>> Signed-off-by: Perry Hooker 
>> ---
>>  drivers/staging/rtl8712/usb_ops_linux.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>
>
> Are you using the staging branch of Greg's tree? If so, you should be using
> staging-next. The exact patch that you submitted has already been applied as
> commit 6839bc81478f entitled "staging: rtl8712: changed uint to __le32" and
> authored by Jannik Becher . The patch was applied
> on Tue Dec 20.
>
> Sorry that I did not remember about that earlier patch with the first reply;
> however, you did get the fix right this time. Congratulations as these
> endian issues can be difficult.
>
> In a quick look at the code, I see that there are a number of endian
> problems in the headers for the 802.11 packets, and in the macros that read
> and write the TX and RX descriptors. It is surprising that the driver
> actually works on big-endian hardware. I do not know how much experience you
> have, but the macros are tricky. I will try to get them cleaned up.
>
> Larry
>
>
> staging: rtl8712: changed uint to __le32
>
>
>>
>> diff --git a/drivers/staging/rtl8712/usb_ops_linux.c
>> b/drivers/staging/rtl8712/usb_ops_linux.c
>> index fc6bb0b..df7c1aa 100644
>> --- a/drivers/staging/rtl8712/usb_ops_linux.c
>> +++ b/drivers/staging/rtl8712/usb_ops_linux.c
>> @@ -192,7 +192,8 @@ void r8712_usb_write_mem(struct intf_hdl *pintfhdl,
>> u32 addr, u32 cnt, u8 *wmem)
>>
>>  static void r8712_usb_read_port_complete(struct urb *purb)
>>  {
>> -   uint isevt, *pbuf;
>> +   __le32 *pbuf;
>> +   uint isevt;
>> struct recv_buf *precvbuf = (struct recv_buf *)purb->context;
>> struct _adapter *padapter = (struct _adapter *)precvbuf->adapter;
>> struct recv_priv *precvpriv = &padapter->recvpriv;
>> @@ -208,7 +209,7 @@ static void r8712_usb_read_port_complete(struct urb
>> *purb)
>> _pkt *pskb = precvbuf->pskb;
>>
>> precvbuf->transfer_len = purb->actual_length;
>> -   pbuf = (uint *)precvbuf->pbuf;
>> +   pbuf = (__le32 *)precvbuf->pbuf;
>> isevt = le32_to_cpu(*(pbuf + 1)) & 0x1ff;
>> if ((isevt & 0x1ff) == 0x1ff) {
>> r8712_rxcmd_event_hdl(padapter, pbuf);
>>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-21 Thread Robert Perry Hooker 
Thanks for taking a look, Dan. Sorry if I missed the mark here.

Can you tell me a bit more about the bug this would introduce?

I see that ieee80211_is_action is defined like this: static inline bool 
ieee80211_is_action(__le16 fc)

...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).

Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered by 
implicitly casting a u8 to __le16? Or am I
missing something else?

Regards,
Perry

On Tue, 2017-03-21 at 23:19 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 01:55:40PM -0600, Perry Hooker wrote:
> > This commit fixes the following sparse warnings:
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:1473:45: warning: 
> > incorrect type in argument 1 (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2006:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2011:52: warning: 
> > incorrect type in assignment (different base > > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2012:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2078:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2083:52: warning: 
> > incorrect type in assignment (different base 
> > types)
> > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2084:51: warning: 
> > incorrect type in assignment (different base 
> > types)
> > 
> > Signed-off-by: Perry Hooker 
> > ---
> >  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 +---
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > index a37896f..d1c75c7 100644
> > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > @@ -1470,7 +1470,7 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 
> > *buff, u32 size)
> > } else {
> > s32Freq = ieee80211_channel_to_frequency(curr_channel, 
> > NL80211_BAND_2GHZ);
> >  
> > -   if (ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > +   if (ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> 
> Nah...  You're just introducing bugs here.  Please be more careful.
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-22 Thread Robert Perry Hooker 
I don't think buff is an ieee80211_hdr struct. I think it's the rx_buffer 
allocated at wilc_wlan.c:1417.

Regards,
Perry

On Wed, 2017-03-22 at 12:24 +0300, Dan Carpenter wrote:
> On Tue, Mar 21, 2017 at 03:40:10PM -0600, Robert Perry Hooker wrote:
> > Thanks for taking a look, Dan. Sorry if I missed the mark here.
> > 
> > Can you tell me a bit more about the bug this would introduce?
> > 
> > I see that ieee80211_is_action is defined like this: static inline bool 
> > ieee80211_is_action(__le16 fc)
> > 
> > ...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID = 0).
> > 
> > Is there an issue with calling cpu_to_le16 on a u8 that isn't encountered 
> > by implicitly casting a u8 to __le16? Or 
> > am I
> > missing something else?
> > 
> 
> Oh...  Hm.  You're right.  I just was thinking that since buff was a
> little endian buffer but it's only reading a u8.  It should probably
> be reading a le16...  The buff likely is just a regular ieee80211_hdr
> struct.
> 
> So you're fixing a bug, but probably not in the right way.  We should
> instead just say "struct ieee80211_hdr *hdr = buff;" and instead of
> treating it like an array of u8.  Probably it requires testing...
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

2017-03-23 Thread Robert Perry Hooker 
Well, yes, all data is 'endian' one way or another, right? I guess the byte 
order of the tx/rx_buffers is host-endian
(which could be big), or _maybe_ network-endian...

Regards,
Perry

On Thu, 2017-03-23 at 11:33 +0300, Dan Carpenter wrote:
> On Wed, Mar 22, 2017 at 07:53:28PM -0600, Robert Perry Hooker wrote:
> > I don't think buff is an ieee80211_hdr struct. I think it's the rx_buffer 
> > allocated at wilc_wlan.c:1417.
> > 
> 
> The rx_buffer is going to end up filled with endian data, right?
> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel