The device does not answer to the command hif_shutdown. Therefore,
hif_shutdown() is a bit special. It bypasses some of work normally made
by wfx_cmd_send(). In particularly, it unlock hif_cmd.lock and
hif_cmd.key_renew_lock.
However, if the driver notice that the device is frozen, wfx_cmd_send()
stops to send data and doesn't lock the mutexes. Then, it produced a
warning when hif_shutdown() tried to unlock these mutexes.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200515083325.378539-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is removing definition of CFLAGS in Makefile of vt6656 and
vt6655, as those are defining macros that are not used. This will remove
undef of one macro from vt6655/device_main.c, as it is only undef and it is
not used anywhere else, so it is safe to remove it.
Macros are removed from vt665x/Makefile and vt6655/device_main.c.
Signed-off-by: Matej Dujava <mdujava@kocurkovo.cz>
Link: https://lore.kernel.org/r/1589397351-24655-2-git-send-email-mdujava@kocurkovo.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drop the driver version of the line-coding request and use the protocol
definition directly as was originally intended instead.
This specifically avoids having the two versions of what is supposed to
be the same struct ever getting out of sync.
Note that this has in fact already happened once when the protocol
definition had its implicit padding removed while the driver struct
wasn't updated. The fact that we used the size of the then larger driver
struct when memcpying its content to the stack didn't exactly make
things better. A later addition of a flow-control field incidentally
made the structures match again.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200514070548.4423-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the start of the "vnt_rf_set_txpower" function the "power" variable
is set at most to VNT_RF_MAX_POWER (hex = 0x3f, dec = 63). Then, in the
switch statement there are four comparisons with the "power" variable
against AL7230_PWR_IDX_LEN (dec = 64), VT3226_PWR_IDX_LEN (dec = 64),
VT3342_PWR_IDX_LEN (dec = 64). Due to all the commented comparisons are
to check if the "power" variable is "greater than or equal" to 64, this
never happens. So, remove the logically dead code.
Also, remove all the defines that are no longer required.
Addresses-Coverity-ID: 1230228 ("Logically dead code")
Fixes: f53d9f12c5 ("staging: vt6656: rf.c additional power.")
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Link: https://lore.kernel.org/r/20200510090950.7633-1-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rsvtime is the time needed in firmware to process the received
frame time in firmware so they can be the same as vnt_get_rts_duration
or vnt_get_cts_duration where appropriate.
The rts_rrv_time are now all the same timing in vnt_rxtx_rts.
So vnt_get_rtscts_rsvtime_le and and vnt_get_frame_time are no longer
required.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/4c0fe356-7e08-bf66-58b7-5ab683ba9536@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The field 'channel_number' from the structs hif_ind_rx and hif_req_start
is a __le32. Sparse complains this field is not always correctly
accessed:
drivers/staging/wfx/data_rx.c:95:55: warning: incorrect type in argument 1 (different base types)
drivers/staging/wfx/data_rx.c:95:55: expected int chan
drivers/staging/wfx/data_rx.c:95:55: got restricted __le16 const [usertype] channel_number
However, the value of channel_number cannot be greater than 14 (this
device only support 2.4Ghz band). So, we only have to access to the
least significant byte. It is finally easier to declare it as an array
of bytes and only access to the first one.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-17-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The field 'num_tx_confs' from the struct hif_cnf_multi_transmit is a
__le32. Sparse complains this field is not always correctly accessed:
drivers/staging/wfx/hif_rx.c:82:9: warning: restricted __le32 degrades to integer
drivers/staging/wfx/hif_rx.c:87:29: warning: restricted __le32 degrades to integer
However, the value of num_tx_confs cannot be greater than 15. So, we
only have to access to the least significant byte. It is finally easier
to declare it as an array of bytes and only access to the first one.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-16-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The field 'status' appears in most of structs returned by the hardware.
This field is encoded as little endian. Sparse complains this field is
not always correctly accessed:
drivers/staging/wfx/data_rx.c:53:16: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_rx.c:84:16: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_tx.c:526:24: warning: restricted __le32 degrades to integer
drivers/staging/wfx/data_tx.c:569:23: warning: restricted __le32 degrades to integer
drivers/staging/wfx/hif_rx.c:128:33: warning: restricted __le32 degrades to integer
drivers/staging/wfx/./traces.h:401:1: warning: restricted __le32 degrades to integer
drivers/staging/wfx/./traces.h:401:1: warning: restricted __le32 degrades to integer
In most of cases, this field is only compared with HIF_STATUS values.
Finally, it is more convenient to solve the problem by defining the
HIF_STATUS values directly in little endian.
It is also the right time to make some clean up in the HIF_STATUS names.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-15-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sparse complains about the accesses to the field 'len' from struct hif_msg:
drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:93:32: warning: cast to restricted __le16
drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:121:25: warning: incorrect type in argument 2 (different base types)
drivers/staging/wfx/bh.c:121:25: expected unsigned int len
drivers/staging/wfx/bh.c:121:25: got restricted __le16 [usertype] len
drivers/staging/wfx/hif_rx.c:27:22: warning: restricted __le16 degrades to integer
drivers/staging/wfx/hif_rx.c:347:39: warning: incorrect type in argument 7 (different base types)
drivers/staging/wfx/hif_rx.c:347:39: expected unsigned int [usertype] len
drivers/staging/wfx/hif_rx.c:347:39: got restricted __le16 const [usertype] len
drivers/staging/wfx/hif_rx.c:365:39: warning: incorrect type in argument 7 (different base types)
drivers/staging/wfx/hif_rx.c:365:39: expected unsigned int [usertype] len
drivers/staging/wfx/hif_rx.c:365:39: got restricted __le16 const [usertype] len
drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types)
drivers/staging/wfx/./traces.h:195:1: expected int msg_len
drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len
drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types)
drivers/staging/wfx/./traces.h:195:1: expected int msg_len
drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len
drivers/staging/wfx/debug.c:319:20: warning: restricted __le16 degrades to integer
drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer
drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer
Indeed, the attribute len is little-endian. We have to take to the
endianness when we access it.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct hif_ind_startup is received from the hardware. So it is
declared as little endian. However, it is also stored in the main driver
structure and used on different places in the driver. Sparse complains
about that:
drivers/staging/wfx/data_tx.c:388:43: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:199:9: warning: restricted __le16 degrades to integer
drivers/staging/wfx/bh.c:221:62: warning: restricted __le16 degrades to integer
In order to make Sparse happy and to keep access from the driver easy,
this patch declare hif_ind_startup with native endianness.
On reception of this struct, this patch takes care to do byte-swap and
keep Sparse happy.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
