aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-06-14Merge tag 'for-5.14-usb' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into usb-nextGreg Kroah-Hartman5-382/+2428
Thierry writes: usb: tegra: Changes for v5.14-rc1 Implements proper suspend/resume for the XUSB controller found on recent Tegra chips. * tag 'for-5.14-usb' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: usb: xhci: tegra: Enable ELPG for runtime/system PM usb: xhci: tegra: Unlink power domain devices phy: tegra: xusb: Add wake/sleepwalk for Tegra186 phy: tegra: xusb: Tegra210 host mode VBUS control phy: tegra: xusb: Add wake/sleepwalk for Tegra210 phy: tegra: xusb: Add sleepwalk and suspend/resume phy: tegra: xusb: Add Tegra210 lane_iddq operation phy: tegra: xusb: Rearrange UPHY init on Tegra210 phy: tegra: xusb: Move usb3 port init for Tegra210
2021-06-14usb: musb: Implement tracing for state change eventsTony Lindgren2-16/+35
The devctl register on musb is the only way to get state information on musb. The hardware can easily get confused because it tries to do things on it's own automagically, and things like slow VBUS rise can make things fail. Let's make it easier to debug the ongoing state change issues that keep popping up on regular basis and add tracing support. With these changes we can easily trace musb state change events with: echo 1 > /sys/kernel/debug/tracing/events/musb/musb_state/enable cat /sys/kernel/debug/tracing/trace_pipe echo 0 > /sys/kernel/debug/tracing/events/musb/musb_state/enable Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Andreas Kemnade <andreas@kemnade.info> Cc: Bhushan Shah <bshah@kde.org> Cc: Drew Fustini <drew@beagleboard.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210604080536.12185-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14usb: musb: Simplify cable state handlingTony Lindgren1-20/+20
Simplify cable state handling a bit to leave out duplicated code. We are just scheduling work and showing state info if a recheck is needed. No intended functional changes. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Andreas Kemnade <andreas@kemnade.info> Cc: Bhushan Shah <bshah@kde.org> Cc: Drew Fustini <drew@beagleboard.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210604080536.12185-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14Merge tag 'v5.13-rc6' into usb-nextGreg Kroah-Hartman266-1063/+2198
We want the usb fixes in here as well, and this resolves some merge issues with: drivers/usb/dwc3/debugfs.c drivers/usb/dwc3/gadget.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14Merge tag 'v5.13-rc6' into tty-nextGreg Kroah-Hartman268-1082/+2206
We want the tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14Merge tag 'v5.13-rc6' into staging-nextGreg Kroah-Hartman268-1082/+2206
We want the staging fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14Merge tag 'v5.13-rc6' into driver-core-nextGreg Kroah-Hartman268-1082/+2206
We need the driver core fix in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14Merge tag 'v5.13-rc6' into char-misc-nextGreg Kroah-Hartman268-1082/+2206
We need the fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14phy: phy-can-transceiver: Add support for generic CAN transceiver driverAswath Govindraju3-0/+156
The driver adds support for generic CAN transceivers. Currently the modes supported by this driver are standby and normal modes for TI TCAN1042 and TCAN1043 CAN transceivers. The transceiver is modelled as a phy with pins controlled by gpios, to put the transceiver in various device functional modes. It also gets the phy attribute max_link_rate for the usage of CAN drivers. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20210510051006.11393-4-a-govindraju@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-14phy: phy-mtk-hdmi: Remove redundant dev_err call in mtk_hdmi_phy_probe()He Ying1-3/+1
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210408115530.15673-1-heying24@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-14phy: phy-mtk-mipi-dsi: Remove redundant dev_err call in mtk_mipi_tx_probe()He Ying1-3/+1
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Link: https://lore.kernel.org/r/20210408114850.14422-1-heying24@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-14phy: phy-mmp3-hsic: Remove redundant dev_err call in mmp3_hsic_phy_probe()He Ying1-3/+1
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Link: https://lore.kernel.org/r/20210408090806.247325-1-heying24@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-14phy: bcm-ns-usb3: Remove redundant dev_err call in bcm_ns_usb3_mdio_probe()He Ying1-3/+1
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Link: https://lore.kernel.org/r/20210408090808.247368-1-heying24@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-14Merge tag 'tags/topic/i915-ttm-2021-06-11' into drm-misc-nextThomas Zimmermann23-249/+1038
drm-misc and drm-intel pull request for topic/i915-ttm: - Convert i915 lmem handling to ttm. - Add a patch to temporarily add a driver_private member to vma_node. - Use this to allow mixed object mmap handling for i915.
2021-06-14Merge drm/drm-next into drm-misc-nextThomas Zimmermann125-2788/+2062
Backmerge to prepare for i915-ttm topic branch. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-06-14soundwire: intel: move to auxiliary busPierre-Louis Bossart4-104/+199
Now that the auxiliary_bus exists, there's no reason to use platform devices as children of a PCI device any longer. This patch refactors the code by extending a basic auxiliary device with Intel link-specific structures that need to be passed between controller and link levels. This refactoring is much cleaner with no need for cross-pointers between device and link structures. Note that the auxiliary bus API has separate init and add steps, which requires more attention in the error unwinding paths. The main loop needs to deal with kfree() and auxiliary_device_uninit() for the current iteration before jumping to the common label which releases everything allocated in prior iterations. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210511052132.28150-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-06-13net: iosm: infrastructureM Chetan Kumar3-0/+39
1) Kconfig & Makefile changes for IOSM Driver compilation. 2) Add IOSM Driver documentation. 3) Modified MAINTAINER file for IOSM Driver addition. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: net driverM Chetan Kumar2-0/+406
1) Create net device & implement net operations for data/IP communication. 2) Bind IP Link to mux IP session for simultaneous IP traffic. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: uevent supportM Chetan Kumar2-0/+85
Report modem status via uevent. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: protocol operationsM Chetan Kumar2-0/+996
1) Update UL/DL transfer descriptors in message ring. 2) Define message set for pipe/sleep protocol. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory protocolM Chetan Kumar2-0/+520
1) Defines messaging protocol for handling Transfer Descriptor in both UL/DL direction. 2) Ring buffer management. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: power managementM Chetan Kumar2-0/+540
Implements state machine to handle host & device sleep. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: encode or decode datagramM Chetan Kumar2-0/+1103
1) Encode UL packet into datagram. 2) Decode DL datagram and route it to network layer. 3) Supports credit based flow control. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: multiplex IP sessionsM Chetan Kumar2-0/+798
Establish IP session between host-device & session management. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: bottom halfM Chetan Kumar2-0/+299
1) Bottom half(tasklet) for IRQ and task processing. 2) Tasks are processed asynchronous and synchronously. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: wwan port control deviceM Chetan Kumar2-0/+135
Implements wwan port for MBIM & AT protocol communication Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: channel configurationM Chetan Kumar2-0/+147
Defines pipes & channel configurations like channel type, pipe mappings, No. of transfer descriptors and transfer buffer size etc. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory I/O operationsM Chetan Kumar2-0/+444
1) Binds logical channel between host-device for communication. 2) Implements device specific(Char/Net) IO operations. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory IPC interfaceM Chetan Kumar2-0/+1942
1) Initializes shared memory for host-device communication. 2) Allocate resources required for control & data operations. 3) Transfers the Device IRQ to IPC execution thread. 4) Defines the timer cbs for async events. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: mmio scratchpadM Chetan Kumar2-0/+416
1) Initializes the Scratchpad region for Host-Device communication. 2) Exposes device capabilities like chip info and device execution stages. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: irq handlingM Chetan Kumar2-0/+123
1) Request interrupt vector, frees allocated resource. 2) Registers IRQ handler. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: entry pointM Chetan Kumar2-0/+788
1) Register IOSM driver with kernel to manage Intel WWAN PCIe device(PCI_VENDOR_ID_INTEL, INTEL_CP_DEVICE_7560_ID). 2) Exposes the EP PCIe device capability to Host PCIe core. 3) Initializes PCIe EP configuration and defines PCIe driver probe, remove and power management OPS. 4) Allocate and map(dma) skb memory for data communication from device to kernel and vice versa. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds1-21/+26
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-13ARM: 9093/1: drivers: firmwapsci: Register with kernel restart handlerGuenter Roeck1-2/+10
Register with kernel restart handler instead of setting arm_pm_restart directly. This enables support for replacing the PSCI restart handler with a different handler if necessary for a specific board. Select a priority of 129 to indicate a higher than default priority, but keep it as low as possible since PSCI reset is known to fail on some boards. Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2021-06-13counter: interrupt-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-3/+3
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-Budde1-5/+5
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 Lang1-3/+4
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 Lang1-1/+1
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 as volatile, tooMarc Kleine-Budde1-0/+6
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 Rix1-1/+1
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 Gerhold4-84/+18
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-13iio: accel: bmc150: Add device IDs for BMA253Stephan Gerhold4-2/+5
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-13iio: accel: bmc150: Sort all chip names alphabetically / by chip IDStephan Gerhold3-42/+42
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 Gerhold2-18/+2
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 Gerhold4-67/+37
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 Gerhold1-2/+5
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 Gerhold1-4/+5
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 Yongjun1-0/+1
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 Yingliang1-2/+4
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>
2021-06-13iio: accel: bma180: Fix BMA25x bandwidth register valuesStephan Gerhold1-2/+7
According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald <pmeerw@pmeerw.net> Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>