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>
split vnt_get_rtscts_duration_le into vnt_get_rts_duration and
vnt_get_cts_duration.
The duration's are all the same in vnt_rxtx_rts_g_head.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/d2983161-7935-48ce-c0ca-a26ebafa3997@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ieee80211_generic_frame_duration is the mac80211 equivalent to
vnt_get_rsvtime use this to get our frame time.
There is a change where there is rrv_time_a and rrv_time_b
the frame duration is always the same so both are equal.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/acff7fcc-0add-652b-7d07-22001b641257@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently channel is being sanity checked after it has been used as
an index into some arrays. Fix this by moving the sanity check of
channel before the arrays are indexed with it.
Addresses-Coverity: ("Negative array index read")
Fixes: 59ed0480b9 ("Staging: most: replace pr_*() functions by dev_*()")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200507150652.52238-1-colin.king@canonical.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>
The field packet_id is not interpreted by the device. It is only used as
identifier for the device answer. So it is not necessary to declare it
little endian. It fixes some warnings raised by Sparse without
complexifying the code.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The attribute ps_mode_error 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-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The structs hif_{req,cnf}_read_mib contain only little endian values.
Thus, it is necessary to fix byte ordering before to use them.
Especially, sparse detected wrong accesses to fields mib_id and length.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct hif_cnf_tx contains only little endian values. Thus, it is
necessary to fix byte ordering before to use them. Especially, sparse
detected wrong access to fields media_delay and tx_queue_delay.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct hif_rx_stats contains only little endian values. Thus, it is
necessary to fix byte ordering before to use them.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The field wakeup_period_max from struct hif_mib_beacon_wake_up_period is
a u8. So, assigning it a __le16 produces a nasty bug on big-endian
architectures.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sparse detects that le16_to_cpup() expects a __le16 * as argument.
Change the cast operator to be compliant with sparse.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200512150414.267198-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The kernel coding style promotes the use of kernel types (u8, u16, u32,
etc...) instead of the C99 ones.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-16-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The kernel coding style expects no space after cast operator. This patch
make the wfx driver compliant with this rule.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-15-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some function prototypes were not correctly aligned and/or exceed 80
columns.
In some other cases, the prototypes were written on more lines than
necessary.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-14-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to keep the compilation times reasonable, we try to only
include the necessary headers (especially header included from other
headers).
This patch clean up unnecessary headers inclusions.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When possible, we prefer to use the macro ARRAY_SIZE rather than hard
coding the number of elements.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sparse tool noticed that wfx_enable_beacon() is never used outside of
sta.c. Therefore, it can be declared static.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-11-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
IRQ) cannot be used before to configure it. Therefore, the first
exchanges with the chip have to be done without the OOB IRQ.
This patch allow to poll the data until the OOB IRQ is correctly setup.
In order to keep the code simpler, this patch also poll data even if OOB
IRQ is not used.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is possible to check if an IRQ is ending by polling the control
register. This function must used with care: if an IRQ fires while the
host reads control register, the IRQ can be lost. However, it could be
useful in some cases.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-8-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, the SPI implementation use a workqueue to acknowledge IRQ
while the SDIO-OOB implementation use a threaded IRQ.
The threaded also offers the advantage to allow level triggered IRQs.
Uniformize the code and use threaded IRQ in both case. Therefore, prefer
level triggered IRQs if the user does not specify it in the DT.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-7-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When used over SDIO bus, device is able to use an external line to
signal IRQs (also called Out-Of-Band IRQ). The current code have several
problems:
1. The ISR cannot directly acknowledge IRQ since access to the bus is
not atomic. This patch use a threaded IRQ to solve that issue.
2. On certain platforms, it is necessary to keep SDIO interruption
enabled (with register SDIO_CCCR_IENx) (this part has inspired from
the brcmfmac driver).
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, the ISR check if bus->core is not NULL. But, it is a useless
check. bus->core is initialiased before to request IRQ and it is not
assigned to NULL when it is released.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case of error in wfx_probe(), wdev->hw is freed. Since an error
occurred, wfx_free_common() is called, then wdev->hw is freed again.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Fixes: 4033714d6c ("staging: wfx: fix init/remove vs IRQ race")
Link: https://lore.kernel.org/r/20200505123757.39506-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The device take a few hundreds of milliseconds to start. However, the
current code wait up to 10 second for the chip. We can safely reduce
this value to 1 second. Thanks to that change, it is no more necessary
to use an interruptible timeout.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, the driver explicitly exclude support for chip with version
number it does not know. However, it unlikely that any futur hardware
change would break the driver. Therefore, we prefer to invert the test
and only exclude the versions we know the driver does not support.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200505123757.39506-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Constify some data structs that are never changed. In order to do so,
also update a couple of functions that now need to accept pointers to
const struct instead of struct. While at it, update a few more functions
to accept pointers to const struct instead of pointers.
This allows the compiler to put more data in the code segment instead of
the data segment, as seen by the output of the file command:
Before:
text data bss dec hex filename
27080 8144 192 35416 8a58 drivers/iio/light/ltr501.o
After:
text data bss dec hex filename
27688 7536 192 35416 8a58 drivers/iio/light/ltr501.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change makes the use of devm_iio_kfifo_allocate() to attach the
life-cycle of the kfifo buffer to the parent (client->dev) object.
This removes the need to explicitly free 'indio_dev->buffer' via
iio_kfifo_free(), which is the main intent.
Having done this, it is straight forward to move to devm_ calls throughout
and drop the remove function.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Limit the output of humidity compensation to the range between 0 and 100
percent.
Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.
Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.
Although this clamp is documented, it was never in the driver of the
kernel.
It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix integartion time typo and while at it improve the comment with
the typo a bit in general.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On ACPI based systems the CPLM3218 ACPI device node describing the
CM3218[1] sensor typically will have some extra tables with register
init values for initializing the sensor and calibration info.
This is based on a newer version of cm32181.c, with a copyright of:
* Copyright (C) 2014 Capella Microsystems Inc.
* Author: Kevin Tsai <ktsai@capellamicro.com>
*
* 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.
Which is floating around on the net in various places, but the changes
from this newer version never made it upstream.
This was tested on the following models: Acer Switch 10 SW5-012 (CM32181)
Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181).
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
