- 19 Jul, 2021 11 commits
-
-
Alexandru Ardelean authored
This change converts the driver to register via devm_iio_device_register(). For the tmp006_powerdown() hook, this uses a devm_add_action() hook to put the device in powerdown mode when it's unregistered. With these changes, the remove hook can be removed. The i2c_set_clientdata() call is staying around as the private data is used in the PM routines. Signed-off-by:
Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210624081924.15897-1-aardelean@deviqon.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The datasheet mentions that the suspend mode is toggled by reading the suspend register. The reading returns value 0xFF if the system was in suspend mode, otherwise it returns value 0x00. The bma220_deinit() function does up to 2 reads, in case the device was in suspend mode, which suggests a level of paranoia that makes the logic in bma220_suspend() and bma220_resume() look insufficient. This change implements a bma220_power() function which does up to 2 reads of the suspend register to make sure that the chip enters a desired (suspended or normal) mode. If the transition fails, then -EBUSY is returned. Since only a reference to SPI device is required, we can remove the spi_set_drvdata() call and get the SPI device object from the base device object in the suspend/resume routines. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the driver to use devm_iio_triggered_buffer_setup() and devm_iio_device_register() for initializing and registering the IIO device. The bma220_deinit() is converted into a callback for a devm_add_action_or_reset() hook, so that the device is put in stand-by when the driver gets uninitialized. The return value of the bma220_deinit() function isn't used as it does not add any value. On the error path of the probe function, this can just override the actual error with -EBUSY, or can even return 0 (no error), on the error path. Signed-off-by:
-
Jonathan Cameron authored
Simple binding for this family of microchip DACs. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210627163244.1090296-16-jic23@kernel.org
-
Jonathan Cameron authored
This device was missing a binding document. Simple binding with the ad8803 requiring two both low and high references whilst the 8801 only has a high reference. Signed-off-by:
-
Jonathan Cameron authored
Documenting existing bindings for this device. The Linux driver in theory 'works' without the two supplies that I have listed as required, but without a valid scale. As such I've documented it as required. Signed-off-by:
-
Jonathan Cameron authored
This binding covers the ad5744, ad5744r, ad5764 and ad5764r DACs. Note that the driver currently assumes the internal reference is used for the r parts. The binding as defined relaxes this constraint. There is no support in the binding or driver for the two digital IO signals. I do not propose to add that until we have a means to test any such binding. Signed-off-by:
-
Jonathan Cameron authored
Straight forward binding with vref optional for those part with internal regulators, but required for those without. Signed-off-by:
-
Jonathan Cameron authored
The use of vcc-supply for the reference voltage is unusual and should probably be deprecated as there is an explicit VREF pin on at least some of these parts. Signed-off-by:
-
Jonathan Cameron authored
Simple binding, with optional vref. Note that the Linux driver does support vcc-supply for historical reasons, but lets not let that get into any bindings that are checked going forwards. Hence I have deliberately not documented it. Signed-off-by:
-
Jonathan Cameron authored
The naming of the regulator is problematic. VCC is usually a supply voltage whereas these devices have a separate VREF pin. Secondly, the regulator core might have provided a stub regulator if a real regulator wasn't provided. That would in turn have failed to provide a voltage when queried. So reality was that there was no way to use the internal reference. In order to avoid breaking any dts out in the wild, make sure to fallback to the original vcc naming if vref is not available. Signed-off-by:
kernel test robot <lkp@intel.com> Acked-by:
-
- 17 Jul, 2021 17 commits
-
-
Jonathan Cameron authored
Binding for this high voltage DAC with temperature event signal. Signed-off-by:
-
Jonathan Cameron authored
Documenting existing binding, so little flexibility available. 2 channel devices that require separate reference voltages. Signed-off-by:
-
Jonathan Cameron authored
A simple binding for this particular DAC familly. Signed-off-by:
-
Jonathan Cameron authored
Bindings for the family of many channel DACs. Fairly straight forward with just a differing number of voltage references (an extra one for the 40 channel ad4371) Signed-off-by:
-
Jonathan Cameron authored
Note this is documenting bindings that have effectively existing ever since this driver was merged. The naming conventions for the ADI parts are inconsistent on the data sheets which has lead to a mixture of -X and -reference voltage part naming. We could attempt to clean this up, but as we are stuck supporting the existing binding it is probably not worthwhile. Signed-off-by:
-
Jonathan Cameron authored
This is documented what is currently the case. There are a number of things that could be added, but I don't feel the binding elements are obvious enough to document without a driver implementation to verify they are good choices. These include * Range * Regulators, both input and potentially output (if the loop being driven is ever described). I've listed Lars and myself as maintainers of the binding, but if anyone else wants to be added they would be most welcome! Signed-off-by:
-
Alexandru Ardelean authored
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by:
-
Alexandru Ardelean authored
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by:
-
Alexandru Ardelean authored
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the probe hook to register the IIO device with devm_iio_device_register() and register a hook with devm_add_action_or_reset() to put the device in powerdown when the driver gets unloaded. Since the PM suspend/resume functions need only a reference to the i2c_client object (which can be obtained from the base device object), the i2c_set_clientdata() call can be removed. Signed-off-by:
-
Alexandru Ardelean authored
These 2 functions only do I2C reads/writes and don't require any of the private data of the driver. They're also used in the PM suspend/resume part of the driver. Converting them to take an i2c_client object as parameter simplifies things a bit (especially in the suspend/resume) as the driver mostly needs the reference for i2c_client, so no need to jump through hoops to get it from the private data (as was done in many places). The rfd77402_measure() function has also been converted to take an i2c_client object, since it also does only I2C ops. Signed-off-by:
-
Alexandru Ardelean authored
Now that the driver's buffer is stored on the adjd_s311_data private object, the driver is a simple conversion to use only device-managed functions in the probe. The iio_triggered_buffer_setup() and iio_device_register() functions are the only ones needing conversion. And i2c_set_clientdata() is no longer required. Signed-off-by:
-
Alexandru Ardelean authored
This change moves the entire buffer on the private adjd_s311_data type. Since the device has 4 channels, it's not a big waste to just allocate the maximum possible buffer and use only what's needed. This is in contrast with free-ing and re-allocating the buffer on the update_scan_mode hook. Since the driver pushes buffer data with iio_push_to_buffers_with_timestamp(), the buffer must also include a 64-bit buffer for the timestamp, for each sample-set. With this change, the adjd_s311_update_scan_mode() is no longer needed. Signed-off-by:
-
Simon Xue authored
It is similar to other devices, but with 8 channels. Signed-off-by:
Simon Xue <xxm@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20210712014507.97477-1-xxm@rock-chips.comSigned-off-by:
-
Simon Xue authored
Add description for rk3568 saradc. Signed-off-by:
-
Christophe JAILLET authored
This is more standard to have sanity checks at the entry of a function, instead of allocating some memory first and having to free it if a condition is not met. Shuffle code a bit to check 'masklength' before calling 'bitmap_alloc()' Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/98a351adda1908c306e981b9cc86d3dbc79eb5ec.1626261211.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
Use 'bitmap_alloc()' instead of 'bitmap_zalloc()' because the bitmap is fully overridden by a 'bitmap_copy()' call just after its allocation. While at it, fix the style of a NULL check. Signed-off-by:
-
- 13 Jul, 2021 2 commits
-
-
Jarkko Nikula authored
0-DAY CI Kernel Test Service reported following iwyu warning: drivers/counter/intel-qep.c:11:1: iwyu: warning: superfluous #include <linux/bitops.h> Remove that include since we don't seem to use anything from it. Reported-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/20210629111657.2655688-1-jarkko.nikula@linux.intel.comSigned-off-by:
-
Alexandru Ardelean authored
Some HID drivers use devm_kmemdup() already to clone the template IIO channels information and update it. However, there are still some drivers that kmemdup() and kfree() the channels. This change converts them to use devm_kmemdup() and bind the life-time of this allocated object to the parent device object (in these drivers). Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210630123029.759609-1-aardelean@deviqon.comSigned-off-by:
-
- 11 Jul, 2021 10 commits
-
-
Linus Torvalds authored
-
Hugh Dickins authored
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Reviewed-by:
Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734c ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Hugh Dickins authored
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61b ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by:
-
Hugh Dickins authored
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Ingo Molnar: "Two fixes: - Fix a MIPS IRQ handling RCU bug - Remove a DocBook annotation for a parameter that doesn't exist anymore" * tag 'irq-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mips: Fix RCU violation when using irqdomain lookup on interrupt entry genirq/irqdesc: Drop excess kernel-doc entry @lookup -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Ingo Molnar: "Three fixes: - Fix load tracking bug/inconsistency - Fix a sporadic CFS bandwidth constraints enforcement bug - Fix a uclamp utilization tracking bug for newly woken tasks" * tag 'sched-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/uclamp: Ignore max aggregation if rq is idle sched/fair: Fix CFS bandwidth hrtimer expiry type sched/fair: Sync load_sum with load_avg after dequeue
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "A fix and a hardware-enablement addition: - Robustify uncore_snbep's skx_iio_set_mapping()'s error cleanup - Add cstate event support for Intel ICELAKE_X and ICELAKE_D" * tag 'perf-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/uncore: Clean up error handling path of iio mapping perf/x86/cstate: Add ICELAKE_X and ICELAKE_D support
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fixes from Ingo Molnar: - Fix a Sparc crash - Fix a number of objtool warnings - Fix /proc/lockdep output on certain configs - Restore a kprobes fail-safe * tag 'locking-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/atomic: sparc: Fix arch_cmpxchg64_local() kprobe/static_call: Restore missing static_call_text_reserved() static_call: Fix static_call_text_reserved() vs __init jump_label: Fix jump_label_text_reserved() vs __init locking/lockdep: Fix meaningless /proc/lockdep output of lock classes on !CONFIG_PROVE_LOCKING
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull more SCSI updates from James Bottomley: "This is a set of minor fixes and clean ups in the core and various drivers. The only core change in behaviour is the I/O retry for spinup notify, but that shouldn't impact anything other than the failing case" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (23 commits) scsi: virtio_scsi: Add validation for residual bytes from response scsi: ipr: System crashes when seeing type 20 error scsi: core: Retry I/O for Notify (Enable Spinup) Required error scsi: mpi3mr: Fix warnings reported by smatch scsi: qedf: Add check to synchronize abort and flush scsi: MAINTAINERS: Add mpi3mr driver maintainers scsi: libfc: Fix array index out of bound exception scsi: mvsas: Use DEVICE_ATTR_RO()/RW() macro scsi: megaraid_mbox: Use DEVICE_ATTR_ADMIN_RO() macro scsi: qedf: Use DEVICE_ATTR_RO() macro scsi: qedi: Use DEVICE_ATTR_RO() macro scsi: message: mptfc: Switch from pci_ to dma_ API scsi: be2iscsi: Fix some missing space in some messages scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe() scsi: ufs: Fix build warning without CONFIG_PM scsi: bnx2fc: Remove meaningless bnx2fc_abts_cleanup() return value assignment scsi: qla2xxx: Add heartbeat check scsi: virtio_scsi: Do not overwrite SCSI status scsi: libsas: Add LUN number check in .slave_alloc callback scsi: core: Inline scsi_mq_alloc_queue() ...
-
