summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_ieee80211.cPhillip Potter
Remove all DBG_88E calls from core/rtw_ieee80211.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-8-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_pwrctrl.cPhillip Potter
Remove all DBG_88E calls from core/rtw_pwrctrl.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Also remove pmlmepriv declaration from within rtw_ps_processor as it is now no longer used. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-7-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_ap.cPhillip Potter
Remove all DBG_88E calls from core/rtw_ap.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-6-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_wlan_util.cPhillip Potter
Remove all DBG_88E calls from core/rtw_wlan_util.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-5-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_mlme_ext.cPhillip Potter
Remove all DBG_88E calls from core/rtw_mlme_ext.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Also remove variable declarations for variables which now go unused as a result of this change with core/rtw_mlme_ext.c Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-4-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_xmit.cPhillip Potter
Remove all DBG_88E calls from core/rtw_xmit.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Also remove static rtw_sctx_chk_warning_status function, as it no longer has any callers. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-3-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: rtl8188eu: remove all DBG_88E calls from core/rtw_efuse.cPhillip Potter
Remove all DBG_88E calls from core/rtw_efuse.c as this macro is unnecessary, and many of these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210615001507.1171-2-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-15staging: unisys: visorhba: Convert module from IDR to XArrayFabio M. De Francesco
Converted visorhba from IDR to XArray. The abstract data type XArray is more memory-efficient, parallelizable, and cache friendly. It takes advantage of RCU to perform lookups without locking. Furthermore, IDR is deprecated because XArray has a better (cleaner and more consistent) API. Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210514081112.19542-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8712: fix memory leak in rtl871x_load_fw_cbPavel Skripkin
There is a leak in rtl8712 driver. The problem was in non-freed adapter data if firmware load failed. This leak can be reproduced with this code: https://syzkaller.appspot.com/text?tag=ReproC&x=16612f02d00000, Autoload must fail (to not hit memory leak reported by syzkaller) There are 2 possible ways how rtl871x_load_fw_cb() and r871xu_dev_remove() can be called (in case of fw load error). 1st case: r871xu_dev_remove() then rtl871x_load_fw_cb() In this case r871xu_dev_remove() will wait for completion and then will jump to the end, because rtl871x_load_fw_cb() set intfdata to NULL: if (pnetdev) { struct _adapter *padapter = netdev_priv(pnetdev); /* never exit with a firmware callback pending */ wait_for_completion(&padapter->rtl8712_fw_ready); pnetdev = usb_get_intfdata(pusb_intf); usb_set_intfdata(pusb_intf, NULL); if (!pnetdev) goto firmware_load_fail; ... clean up code here ... } 2nd case: rtl871x_load_fw_cb() then r871xu_dev_remove() In this case pnetdev (from code snippet above) will be zero (because rtl871x_load_fw_cb() set it to NULL) And clean up code won't be executed again. So, in all cases we need to free adapted data in rtl871x_load_fw_cb(), because disconnect function cannot take care of it. And there won't be any race conditions, because complete() call happens after setting intfdata to NULL. In previous patch I moved out free_netdev() from r8712_free_drv_sw() and that's why now it's possible to free adapter data and then call complete. Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/81e68fe0194499cc2e7692d35bc4dcf167827d8f.1623620630.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8712: fix error handling in r871xu_drv_initPavel Skripkin
Previous error handling path was unique for all possible errors and there was unnecessary branching. Also, one step for freeing drv_sw was missing. All these problems was fixed by restructuring error handling path. Also, moved out free_netdev() from r8712_free_drv_sw() for correct error handling. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/febb00f72354449bb4d305f373d6d2f47e539ab4.1623620630.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8712: remove redundant check in r871xu_drv_initPavel Skripkin
padapter->dvobj_init is initialized rigth before initialization check. There is no need for any branching here. Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/d367e5f39f22af44c545f8710cc18fb00f10e66c.1623620630.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: remove another write-only memberMartin Kaiser
bAPKThermalMeterIgnore in struct hal_data_8188e is never read and can be removed. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210612180019.20387-5-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: remove a write-only power-index membersMartin Kaiser
Remove power index members of struct hal_data_8188e that are written to but never read. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210612180019.20387-4-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: remove a write-only struct memberMartin Kaiser
FwRsvdPageStartOffset in struct hal_data_8188e is never read. Remove it. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210612180019.20387-3-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: remove unused hal_data_8188e membersMartin Kaiser
Remove some members of struct hal_data_8188e which are not used in this driver. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210612180019.20387-1-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: qlge: change msleep to usleep_rangeTobias Alam
This patch changes msleep() to usleep_range() based on Documentation/timers/timers-howto.txt. It suggests using usleep_range() for small msec(1ms - 20ms) because msleep() will often sleep longer than the desired value. Issue found by checkpatch. Signed-off-by: Tobias Alam <tobiasalam@gmail.com> Link: https://lore.kernel.org/r/YMa60p5dl0LMV/9D@tobias-VirtualBox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: convert DBG_88E calls in core/rtw_recv.cPhillip Potter
Convert all calls to the DBG_88E macro in core/rtw_recv.c into netdev_dbg calls. The DBG_88E macro is unnecessary, as visibility of debug messages can be controlled more precisely by just using debugfs. It is important to keep these messages still, as they are displayable via a kernel module parameter when using DBG_88E. One such converted call is after a failed skb allocation, but as it prints additional information besides just stating failure, I've left it in despite the checkpatch warning. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210613102459.7532-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: convert DBG_88E calls in core/rtw_sta_mgt.cPhillip Potter
Convert both calls to the DBG_88E macro in core/rtw_sta_mgt.c into netdev_dbg calls. The DBG_88E macro is unnecessary, as visibility of debug messages can be controlled more precisely by just using debugfs. It is important to keep these messages still, as they are displayable via a kernel module parameter when using DBG_88E. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210613102454.7480-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: rtl8188eu: remove HW_DEF_ODM_DBG_FLAG enum valuePhillip Potter
Remove HW_DEF_ODM_DBG_FLAG definition from the hal_def_variable enum in include/hal_intf.h, and remove its usage from the switch statement in rtw_hal_get_def_var inside hal/usb_halinit.c - this is dead code and no longer used, now that ODM_RT_TRACE and include/odm_debug.h have been removed. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210612181942.33817-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: gdm724x: check for overflow in gdm_lte_netif_rx()Dan Carpenter
This code assumes that "len" is at least 62 bytes, but we need a check to prevent a read overflow. Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YMcoTPsCYlhh2TQo@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14staging: gdm724x: check for buffer overflow in gdm_lte_multi_sdu_pkt()Dan Carpenter
There needs to be a check to verify that we don't read beyond the end of "buf". This function is called from do_rx(). The "buf" is the USB transfer_buffer and "len" is "urb->actual_length". Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YMcnl4zCwGWGDVMG@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14iio: light: vcnl4000: Fix buffer alignment in ↵Jonathan Cameron
iio_push_to_buffers_with_timestamp() Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a kernel data leak, making for a less minimal fix. Found during an audit of all callers of iio_push_to_buffers_with_timestamp() Fixes: 8fe78d5261e7 ("iio: vcnl4000: Add buffer support for VCNL4010/20.") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Mathieu Othacehe <m.othacehe@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-7-jic23@kernel.org
2021-06-14iio: magn: rm3100: Fix alignment of buffer in ↵Jonathan Cameron
iio_push_to_buffers_with_timestamp() Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because this buffer is used in a non-trivial way for data repacking. Fixes: 121354b2eceb ("iio: magnetometer: Add driver support for PNI RM3100") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Song Qiang <songqiang1304521@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-6-jic23@kernel.org
2021-06-14iio: adc: ti-ads8688: Fix alignment of buffer in ↵Jonathan Cameron
iio_push_to_buffers_with_timestamp() Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Fixes: f214ff521fb1 ("iio: ti-ads8688: Update buffer allocation for timestamps") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-5-jic23@kernel.org
2021-06-14iio: adc: mxs-lradc: Fix buffer alignment in ↵Jonathan Cameron
iio_push_to_buffers_with_timestamp() To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Add a comment on why the buffer is the size it is as not immediately obvious. Found during an audit of all calls of this function. Fixes: 6dd112b9f85e ("iio: adc: mxs-lradc: Add support for ADC driver") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-4-jic23@kernel.org
2021-06-14iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp()Jonathan Cameron
To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: d3bf60450d47 ("iio: hx711: add triggered buffer support") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-3-jic23@kernel.org
2021-06-14iio: adc: at91-sama5d2: Fix buffer alignment in ↵Jonathan Cameron
iio_push_to_buffers_with_timestamp() To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210613152301.571002-2-jic23@kernel.org
2021-06-14Merge tag 'v5.13-rc6' into staging-nextGreg Kroah-Hartman
We want the staging fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-13Linux 5.13-rc6v5.13-rc6Linus Torvalds
2021-06-13Merge tag 'perf-tools-fixes-for-v5.13-2021-06-13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Correct buffer copying when peeking events - Sync cpufeatures/disabled-features.h header with the kernel sources * tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: tools headers cpufeatures: Sync with the kernel sources perf session: Correct buffer copying when peeking events
2021-06-13Merge tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds
Pull NFS client bugfixes from Trond Myklebust: "Highlights include: Stable fixes: - Fix use-after-free in nfs4_init_client() Bugfixes: - Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode() - Fix second deadlock in nfs4_evict_inode() - nfs4_proc_set_acl should not change the value of NFS_CAP_UIDGID_NOMAP - Fix setting of the NFS_CAP_SECURITY_LABEL capability" * tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Fix second deadlock in nfs4_evict_inode() NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode() NFS: FMODE_READ and friends are C macros, not enum types NFS: Fix a potential NULL dereference in nfs_get_client() NFS: Fix use-after-free in nfs4_init_client() NFS: Ensure the NFS_CAP_SECURITY_LABEL capability is set when appropriate NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.
2021-06-13Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Four reasonably small fixes to the core for scsi host allocation failure paths. The root problem is that we're not freeing the memory allocated by dev_set_name(), which involves a rejig of may of the free on error paths to do put_device() instead of kfree which, in turn, has several other knock on ramifications and inspection turned up a few other lurking bugs" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: core: Only put parent device if host state differs from SHOST_CREATED scsi: core: Put .shost_dev in failure path if host state changes to RUNNING scsi: core: Fix failure handling of scsi_add_host_with_dma() scsi: core: Fix error handling of scsi_host_alloc()
2021-06-13counter: interrupt-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch renames interrupt_cnt_synapse_actionss to interrupt_cnt_synapse_actions and adds a const qualifier to match actions_list. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20210610013642.149961-1-vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: ltr501: mark ltr501_chip_info as constMarc Kleine-Budde
This patch marks the struct ltr501_chip_info as constant. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-5-mkl@pengutronix.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: ltr501: ltr501_read_ps(): add missing endianness conversionOliver Lang
The PS ADC Channel data is spread over 2 registers in little-endian form. This patch adds the missing endianness conversion. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTROliver Lang
The ltr559 chip uses only the lowest bit of the ALS_CONTR register to configure between active and stand-by mode. In the original driver BIT(1) is used, which does a software reset instead. This patch fixes the problem by using BIT(0) as als_mode_active for the ltr559 chip. Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip") Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA ↵Marc Kleine-Budde
as volatile, too The regmap is configured for 8 bit registers, uses a RB-Tree cache and marks several registers as volatile (i.e. do not cache). The ALS and PS data registers in the chip are 16 bit wide and spans two regmap registers. In the current driver only the base register is marked as volatile, resulting in the upper register only read once. Further the data sheet notes: | When the I2C read operation starts, all four ALS data registers are | locked until the I2C read operation of register 0x8B is completed. Which results in the registers never update after the 2nd read. This patch fixes the problem by marking the upper 8 bits of the ALS and PS registers as volatile, too. Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") Reported-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: scmi: fix spelling of SPDX tagTom Rix
checkpatch looks for SPDX-License-Identifier. Remove the extra spaces. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210610214438.3161140-7-trix@redhat.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bma180/bmc150: Move BMA254 to bmc150-accel driverStephan Gerhold
Commit c1d1c4a62db5 ("iio: accel: bma180: BMA254 support") added BMA254 support to the bma180 driver and changed some naming to BMA25x to make it easier to add support for BMA253 and BMA255. Unfortunately, there is quite some overlap between the bma180 driver and the bmc150-accel driver. Back when the commit was made, the bmc150-accel driver actually already had support for BMA255, and adding support for BMA254 would have been as simple as adding a new compatible to bmc150-accel. The bmc150-accel driver is a bit better for BMA254 since it also supports the motion trigger/interrupt functionality. Fortunately, moving BMA254 support over to bmc150-accel is fairly simple because the drivers have compatible device tree bindings. Revert most of the changes for BMA254 support in bma180 and move BMA254 over to bmc150-accel. This has the following advantages: - Support for motion trigger/interrupt - Fix incorrect scale values (BMA254 currently uses the same as BMA250 but actually they're different because of 10 vs 12 bits data size) - Less code than before :) BMA250 could be potentially also moved but it's more complicated because its chip_id conflicts with the one for BMA222 in bmc150-accel. Perhaps there are also other register differences, I did not investigate further yet (and I have no way to test it). Cc: Peter Meerwald <pmeerw@pmeerw.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-11-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13dt-bindings: iio: accel: bma180/bma255: Move bma254 to bma255 schemaStephan Gerhold
BMA254 is very similar to BMA253/BMA255 which are both supported by the bmc150-accel driver. In general, there is quite some overlap between the bma180 and bmc150-accel driver, but the bmc150-accel driver has a few more features (e.g. motion trigger/interrupt). Let's move bma254 over to the bma255 schema (bmc150-accel driver). Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-10-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13dt-bindings: iio: bma255: Allow multiple interruptsStephan Gerhold
BMA253 has two interrupt pins (INT1 and INT2) that can be configured independently. At the moment the bmc150-accel driver does not make use of them but it might be able to in the future, so it's useful to already specify all available interrupts in the device tree. Set maxItems: 2 for interrupts to allow specifying a second one. This is necessary as preparation to move the bosch,bma254 compatible from bosch,bma180.yaml to bosch,bma255.yaml since bma180 allows two interrupts, but BMA254 is better supported by the bmc150-accel driver. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-9-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Add device IDs for BMA253Stephan Gerhold
BMA253 is mostly like BMA255 and has exactly the same register layout as used by the bmc150-accel driver as far I can tell. Making it work is as simple as adding new device IDs for it since it has the same chip_id = 0xFA (250) as BMA255 and others. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-8-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13dt-bindings: iio: accel: bma255: Document bosch,bma253Stephan Gerhold
BMA253 is mostly like BMA255 that is already supported by the bmc150-accel driver. Document an extra bosch,bma253 compatible for it. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-7-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Sort all chip names alphabetically / by chip IDStephan Gerhold
Right now all the device IDs are listed in seemingly random order, make this consistent by ordering those alphabetically. Also, order bmc150_accel_chip_info_tbl by chip ID for the same reason. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-6-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Drop duplicated documentation of supported chipsStephan Gerhold
The chips supported by the bmc150-accel driver are clearly documented in Kconfig, in the bmc150_accel_chip_info_tbl as well as in all the device ID tables in the I2C/SPI drivers. It's easy to forget to update the lists in the file header. Drop those entirely to reduce the amount of changes required to add new chip variants. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Drop misleading/duplicate chip identifiersStephan Gerhold
Commit 0ad4bf370176 ("iio:accel:bmc150-accel: Use the chip ID to detect sensor variant") stopped using the I2C/ACPI match data to look up the bmc150_accel_chip_info. However, the bmc150_accel_chip_info_tbl remained as-is, with multiple entries with the same chip_id (e.g. 0xFA for BMC150/BMI055/BMA255). This is redundant now because actually the driver will always select the first entry with a matching chip_id. So even if a device probes e.g. with BMA0255 it will end up using the chip_info for BMC150. And in general that's fine for now, the entries for BMC150/BMI055/BMA255 were exactly the same anyway (except for the name, which is replaced with the more accurate one later). But in this case it's misleading because it suggests that one should add even more entries with the same chip_id when adding support for new variants. Let's make that more clear by removing the enum with the chip identifiers entirely and instead have only one entry per chip_id. Note that we may need to bring back some mechanism to differentiate between different chips with the same chip_id in the future. For example, BMA250 (currently supported by the bma180 driver) has the same chip_id = 0x03 as BMA222 even though they have different channel sizes (8 bits vs 10 bits). But in any case, that mechanism would need to look quite different from what we have right now. Cc: Bastien Nocera <hadess@hadess.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Clarify combo modules in KconfigStephan Gerhold
The Kconfig option currently says that all Bosch accelerometers supported by the bmc150-accel driver are combo chips with both accelerometer and magnetometer. This is wrong: actually only BMC150 is such a combo. The BMA* variants only contain an accelerometer and the BMI055 actually is a accelerometer + gyroscope combo. Clarify this in the help text and also make the list of supported variants complete and sorted for consistency. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-3-stephan@gerhold.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: accel: bmc150: Fix bma222 scale unitStephan Gerhold
According to sysfs-bus-iio documentation the unit for accelerometer values after applying scale/offset should be m/s^2, not g, which explains why the scale values for the other variants in bmc150-accel do not match exactly the values given in the datasheet. To get the correct values, we need to multiply the BMA222 scale values by g = 9.80665 m/s^2. Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: dummy: Fix build error when CONFIG_IIO_TRIGGERED_BUFFER is not setWei Yongjun
Gcc reports build error when CONFIG_IIO_TRIGGERED_BUFFER is not set: riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `iio_simple_dummy_configure_buffer': iio_simple_dummy_buffer.c:(.text+0x2b0): undefined reference to `iio_triggered_buffer_setup_ext' riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `.L0 ': iio_simple_dummy_buffer.c:(.text+0x2fc): undefined reference to `iio_triggered_buffer_cleanup' Fix it by select IIO_TRIGGERED_BUFFER for config IIO_SIMPLE_DUMMY_BUFFER. Fixes: 738f6ba11800 ("iio: dummy: iio_simple_dummy_buffer: use triggered buffer core calls") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-13iio: frequency: adf4350: disable reg and clk on error in adf4350_probe()Yang Yingliang
Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). Fixes:4a89d2f47ccd ("iio: adf4350: Convert to use GPIO descriptor") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 14:59:23 +0000