- 10 Oct, 2020 19 commits
-
-
Alexandru Ardelean authored
This change removes the old platform data for ad7298. It is only used to provide whether to use an external regulator as a reference. So, the logic is inverted a bit. The driver now tries to obtain a regulator. If one is provided, then the external ref is used. The rest of the logic should work as before. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201001141048.69050-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Anand Ashok Dumbre authored
Fixes IIO_VAL_FRACTIONAL for case when the result is negative and exponent is 0. example: if the result is -0.75, tmp0 will be 0 and tmp1 = 75 This causes the output to lose sign because of %d in snprintf which works for tmp0 <= -1. Reported-by: kernel test robot <lkp@intel.com> #error: uninitialized symbol tmp Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com> Link: https://lore.kernel.org/r/1601910316-24111-1-git-send-email-anand.ashok.dumbre@xilinx.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
dmitry.torokhov@gmail.com authored
The order in which 'users' counter is decremented vs calling drivers' close() method is implementation specific, and we should not rely on it. Let's introduce driver private flag and use it to signal ISR to exit when device is being closed. This has a side-effect of fixing issue of accessing inut->users outside of input->mutex protection. Reported-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201006215509.GA2556081@dtor-wsSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
These properties need to be set during driver probe. Parse any DT properties and replace the default register settings with the ones parsed from DT. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: <devicetree@vger.kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-7-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
We need to set various bits in the hardware registers for this device to operate properly depending on how it is installed. Add a handful of DT properties to configure these things. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: <devicetree@vger.kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-6-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
The rising and falling directions can be debounced in the hardware as "close" and "far" debounce settings. Add support for these as rising and falling debounce settings. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-5-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
Add support for setting the hysteresis as a shifted value of a channel's proximity threshold. Each channel can have a different threshold, but the hysteresis applies to all channels as a right shift factor. Therefore, duplicate the hysteresis value across all channels and make it depend on the channel's proximity threshold. This is sort of odd but seems to work in practice as most of the time only one channel is used. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-4-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
Add support to set the proximity thresholds for each channel. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-3-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stephen Boyd authored
Add support to set the hardware gain of the channels as a multiplier of 2x, 4x, or 8x. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Douglas Anderson <dianders@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20201007011735.1346994-2-swboyd@chromium.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Lorenzo Bianconi authored
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/05e4273f2544230049b2cd82c6bf1be788a8e483.1601985763.git.lorenzo@kernel.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Lorenzo Bianconi authored
Add support to STM LSM6DST (acc + gyro) Mems sensor https://www.st.com/resource/en/datasheet/lsm6dst.pdfSigned-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/835127b76ef5ad05aa2aac58298aee5f3073fb71.1601985763.git.lorenzo@kernel.orgSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change inverts/reworks the logic to use an external reference via a provided regulator. Now the driver tries to obtain a regulator. If one is found, then it is used. The rest of the driver logic already checks if there is a non-NULL reference to a regulator, so it should be fine. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201002082723.184810-1-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The AT91 ADC driver no longer uses the 'at91_add_device_adc' platform data type. This is no longer used (at least in mainline boards). This change removes the platform-data initialization from the driver, since it is mostly dead code now. Some definitions [from the platform data at91_adc.h include] have been moved in the driver, since they are needed in the driver. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-5-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This tries to solve a warning reported by the lkp bot: >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable >> 'at91_adc_dt_ids' [-Wunused-const-variable] static const struct of_device_id at91_adc_dt_ids[] = { ^ 1 warning generated. This warning has appeared after the AT91_ADC driver compilation has been enabled via the COMPILE_TEST symbol dependency. The warning is caused by the 'of_match_ptr()' helper which returns NULL if OF is undefined. This driver should build only for device-tree context, so a dependency on the OF Kconfig symbol has been added. Also, the usage of of_match_ptr() helper has been removed since it shouldn't ever return NULL (because the driver should not be built for the non-OF context). Fixes: 4027860d ("iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-4-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The main intent is to get rid of the cast for the void-pointer returned by of_device_get_match_data(). This requires const-ifying the 'caps' and 'registers' references on the at91_adc_state struct. The caps can be obtained also from the old platform_data (in the at91_adc_probe_pdata() function), but that cast is not touched in this patch, since the old platform_data should be removed/cleaned-away. Also, that cast deals with converting a kernel_ulong_t type to a pointer. So, updating that cast doesn't yield any benefit. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-3-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This is a small tidy-up. The of_device_get_match_data() helper retrieves the driver data from the OF table, without needed to explicitly know the table variable (since it can retrieve it from the driver object). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200930135048.11530-2-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Michael Auchter authored
Add a binding for AD5686 Signed-off-by: Michael Auchter <michael.auchter@ni.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200924195215.49443-3-michael.auchter@ni.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Michael Auchter authored
Add of_match_table to this driver, so devices can be probed based on device tree contents. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Link: https://lore.kernel.org/r/20200924195215.49443-2-michael.auchter@ni.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Michael Auchter authored
The AD5338R is a 10-bit DAC with 2 outputs and an internal 2.5V reference (enabled by default). The register configuration is nearly identical to the AD5696R DAC that's already supported by this driver, with the channel selection bits being the only thing different. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Link: https://lore.kernel.org/r/20200924195215.49443-1-michael.auchter@ni.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 09 Oct, 2020 1 commit
-
-
Fan Fei authored
This patch fix long lines found by checkpatch. Signed-off-by: Fan Fei <ffclaire1224@gmail.com> Link: https://lore.kernel.org/r/20201008185524.brl467kucslxoxci@ubuntu-T470Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 Oct, 2020 6 commits
-
-
Jérôme Pouiller authored
The device can be connected on SPI or on SDIO. The original file described the two options separately. So, most of the file had to be rewritten in order to match with the Yaml requirements. Some device requirements are still written in the comments since they cannot been expressed with the current scheme (e.g. reg must be set to 1 with SDIO, interrupt is mandatory with SPI, reset-gpio in SPI is replaced by mmc-pwrseq in SDIO, etc...). The examples provided have also been reworked in order to make dt_binding_check happy. Finally, also fix typo in the name of the file (siliabs instead of silabs) Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-7-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
Most of the files have been modified in 2020, so update the copyright notices. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-6-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
The device is in charge of respecting the QoS constraints. The driver have to ensure that all the queues contain data and the device choose the right queue to send. The things starts to be more difficult when the bandwidth of the bus is lower than the bandwidth of the WiFi. The device quickly sends the frames of the highest priority queue. Then, it starts to send frames from a lower priority queue. Though, there are still some high priority frames waiting in the driver. To work around this problem, this patch add some priorities to each queue. The weigh of the queue was (roughly) calculated experimentally by checking the speed ratio of each queue when the bus does not limit the traffic: - Be/Bk -> 20Mbps/10Mbps - Vi/Be -> 36Mbps/180Kbps - Vo/Be -> 35Mbps/600Kbps - Vi/Vo -> 24Mbps/12Mbps So, if we fix the weigh of the Background to 1, the weight of Best Effort should be 2. The weight of Video should be 116. However, since there is only 32 queues, it make no sense to use a value greater than 64[1]. And finally, the weight of the Voice is set to 128. [1] Because of this approximation, with very slow bus, we can still observe frame starvation when we measure the speed ratio of Vi/Be. It is around 35Mbps/1Mbps (instead of 36Mbps/180Kbps). However, it is still in accepted error range. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-5-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
Firmwares with API < 3.6 do not forward DELBA requests. Thus, when a Block Ack session is restarted, the reordering buffer is not flushed and the received sequence number is not contiguous. Therefore, mac80211 starts to wait some missing frames that it will never receive. This patch disables the reordering buffer for old firmware. It is harmless when the network is unencrypted. When the network is encrypted, the non-contiguous frames will be thrown away by the TKIP/CCMP replay protection. So, the user will observe some packet loss with UDP and performance drop with TCP. Fixes: e5da5fbd ("staging: wfx: fix CCMP/TKIP replay protection") Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-4-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
Commit e8d607ce ("staging: wfx: drop 'secure link' feature") had removed the 'secure link' feature. However, a few lines of codes were yet here. Fixes: e8d607ce ("staging: wfx: drop 'secure link' feature") Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-3-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
As expected, when the device detect a MMIC error, it returns a specific status. However, it also strip IV from the frame (don't ask me why). So, with the current code, mac80211 detects a corrupted frame and it drops it before it handle the MMIC error. The expected behavior would be to detect MMIC error then to renegotiate the EAP session. So, this patch correctly informs mac80211 that IV is not available. So, mac80211 correctly takes into account the MMIC error. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20201007101943.749898-2-Jerome.Pouiller@silabs.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 06 Oct, 2020 1 commit
-
-
Dan Carpenter authored
After a list_for_each_entry() loop, the list iterator is always non-NULL so these conditions don't work. If the "waiter" is not found then this results in an out of bounds access. I have fixed it by introducing a new "found" variable. In one case, I used an else statement for readability. Fixes: 46e4b9ec ("staging: vchiq_arm: use list_for_each_entry when accessing bulk_waiter_list") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20201006134748.GA2076872@mwandaSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 Oct, 2020 13 commits
-
-
Coiby Xu authored
(struct gb_audio_ctl_elem_info*)->type has the type of __u8 so there is no concern about the byte order. __force is safe to use. Found by sparse, $ make C=2 drivers/staging/greybus/ drivers/staging/greybus/audio_topology.c:185:24: warning: cast to restricted snd_ctl_elem_type_t Suggested-by: Alex Elder <elder@linaro.org> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Link: https://lore.kernel.org/r/20201002233057.74462-3-coiby.xu@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Coiby Xu authored
snd_soc_pcm_stream.formats should use the bitmask SNDRV_PCM_FMTBIT_* instead of the sequential integers SNDRV_PCM_FORMAT_* as explained by commit e712bfca ("ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask"). Found by sparse, $ make C=2 drivers/staging/greybus/ drivers/staging/greybus/audio_codec.c:691:36: warning: incorrect type in initializer (different base types) drivers/staging/greybus/audio_codec.c:691:36: expected unsigned long long [usertype] formats drivers/staging/greybus/audio_codec.c:691:36: got restricted snd_pcm_format_t [usertype] drivers/staging/greybus/audio_codec.c:701:36: warning: incorrect type in initializer (different base types) drivers/staging/greybus/audio_codec.c:701:36: expected unsigned long long [usertype] formats drivers/staging/greybus/audio_codec.c:701:36: got restricted snd_pcm_format_t [usertype] Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Link: https://lore.kernel.org/r/20201002233057.74462-2-coiby.xu@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Coiby Xu authored
This patch fix the following warnings from sparse, $ make C=2 drivers/staging/greybus/ drivers/staging/greybus/audio_module.c:222:25: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_module.c:222:25: expected restricted __le16 [usertype] data_cport drivers/staging/greybus/audio_module.c:222:25: got unsigned short [usertype] intf_cport_id drivers/staging/greybus/audio_topology.c:460:40: warning: restricted __le32 degrades to integer drivers/staging/greybus/audio_topology.c:691:41: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:691:41: expected unsigned int access drivers/staging/greybus/audio_topology.c:691:41: got restricted __le32 [usertype] access drivers/staging/greybus/audio_topology.c:746:44: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:746:44: expected unsigned int drivers/staging/greybus/audio_topology.c:746:44: got restricted __le32 drivers/staging/greybus/audio_topology.c:748:52: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:748:52: expected unsigned int drivers/staging/greybus/audio_topology.c:748:52: got restricted __le32 drivers/staging/greybus/audio_topology.c:802:42: warning: restricted __le32 degrades to integer drivers/staging/greybus/audio_topology.c:805:50: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:805:50: expected restricted __le32 drivers/staging/greybus/audio_topology.c:805:50: got unsigned int drivers/staging/greybus/audio_topology.c:814:50: warning: restricted __le32 degrades to integer drivers/staging/greybus/audio_topology.c:817:58: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:817:58: expected restricted __le32 drivers/staging/greybus/audio_topology.c:817:58: got unsigned int drivers/staging/greybus/audio_topology.c:889:25: warning: incorrect type in assignment (different base types) drivers/staging/greybus/audio_topology.c:889:25: expected unsigned int access drivers/staging/greybus/audio_topology.c:889:25: got restricted __le32 [usertype] access Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Link: https://lore.kernel.org/r/20201002233057.74462-1-coiby.xu@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ivan Safonov authored
Reduce line length, simplify refactoring. Signed-off-by: Ivan Safonov <insafonov@gmail.com> Link: https://lore.kernel.org/r/20201004060921.8908-1-insafonov@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Replace _cancel_timer with API function del_timer_sync. One instance of del_timer_sync is moved and an unnecessary pair of spin locks are removed. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-8-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Replace RTW_GET_BE16 macro with get_unlaligned_be16. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-7-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Replace RTW_GET_LE16 macro with get_unaligned_le16. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-6-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Replace RTW_GET_BE24 macro with get_unaligned_be24. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-5-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Remove several macros in osdep_service.h because they are not used. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-4-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Use round_up instead of inline _RND8. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-3-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Use round_up instead of inline _RND4. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-2-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ross Schmidt authored
Use round_up instead of define RND4. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201004011743.10750-1-ross.schm.dev@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Coiby Xu authored
This fixes commit 0107635e ("staging: qlge: replace pr_err with netdev_err") which introduced an build breakage of missing `struct ql_adapter *qdev` for some functions and a warning of type mismatch with dumping enabled, i.e., $ make CFLAGS_MODULE="-DQL_ALL_DUMP -DQL_OB_DUMP -DQL_CB_DUMP \ -DQL_IB_DUMP -DQL_REG_DUMP -DQL_DEV_DUMP" M=drivers/staging/qlge qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’: qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function); did you mean ‘cdev’? 2051 | netdev_err(qdev->ndev, "%s\n", __func__); | ^~~~ qlge_dbg.c: In function ‘ql_dump_routing_entries’: qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=] 1435 | "%s: Routing Mask %d = 0x%.08x\n", | ~^ | | | char * | %d 1436 | i, value); | ~ | | | int qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’ argument [-Wformat=] 1435 | "%s: Routing Mask %d = 0x%.08x\n", | ~~~~^ | | | unsigned int Note that now ql_dump_rx_ring/ql_dump_tx_ring won't check if the passed parameter is a null pointer. Fixes: 0107635e ("staging: qlge: replace pr_err with netdev_err") Reported-by: Benjamin Poirier <benjamin.poirier@gmail.com> Suggested-by: Benjamin Poirier <benjamin.poirier@gmail.com> Reviewed-by: Benjamin Poirier <benjamin.poirier@gmail.com> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Link: https://lore.kernel.org/r/20201002235941.77062-1-coiby.xu@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-