- 14 Jun, 2020 35 commits
-
-
Chuhong Yuan authored
Since if there is no GPIO, nothing happens, replace devm_gpiod_get() with devm_gpiod_get_optional(). Also add IS_ERR() to fix the missing-check warning. Fixes: cee211f4 ("iio: amplifiers: ad8366: Add support for the ADA4961 DGA") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Acked-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Tomasz Duszynski authored
IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting raw concentrations of pollutants. Raw value should be meaningless before being properly scaled. Because of that description shouldn't mention raw value unit whatsoever. Fix this by rephrasing existing description so it follows conventions used throughout IIO ABI docs. Fixes: 8ff6b3bc ("iio: chemical: Add IIO_CONCENTRATION channel type") Signed-off-by:
Tomasz Duszynski <tomasz.duszynski@octakon.com> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Alexandru Ardelean authored
Since changes can come from all sort of places, it may make sense to have this symbol as a dependency to make sure that the 'make allmodconfig' && 'make allyesconfig' build rules cover this driver as well for a compile-build/test. It seemed useful [recently] when trying to apply a change for this. Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Jonathan Cameron authored
As this just calls dev_get_drvdata underneath which is happy with a const struct device * we should change and avoid potentially casting away a const in order to then put it back again. Signed-off-by:
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information. Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by:
-
Alexandru Ardelean authored
This was partially removed when the mlock cleanup was done. Only one more call is left in the ad5592r_alloc_channels() function. This one is simple. We just need to pass the iio_dev object and get the state via iio_priv(). Signed-off-by:
-
Jonathan Albrieux authored
Add mount-matrix binding support. As chip could have different orientations a mount matrix support is needed to correctly translate these differences. Signed-off-by:
Jonathan Albrieux <jonathan.albrieux@gmail.com> Signed-off-by:
-
Jonathan Albrieux authored
Add vdd-supply and vddio-supply support. While working on an msm8916 device and having explicit declarations for regulators, without setting these regulators to regulators-always-on it happened those lines weren't ready because they could have been controlled by other components, causing failure in module's probe. This patch aim is to solve this situation by adding regulators control during bmi160_chip_init() and bmi160_chip_uninit(), assuring power to this component. Signed-off-by:
-
Jonathan Albrieux authored
Fix a typo in MODULE_AUTHOR() argument. Signed-off-by:
-
Jonathan Albrieux authored
Add vdd-supply and vddio-supply support. Add mount-matrix support. Signed-off-by:
-
Gwendal Grignou authored
EC does not currently preserve range across sensor reinit. If sensor is powered down at suspend, it will default to the EC default range at resume, not the range set by the host. Save range if modified, and apply at resume. Signed-off-by:
Gwendal Grignou <gwendal@chromium.org> Signed-off-by:
-
Christian Oder authored
The mxc6655 is fully working with the existing mxc4005 driver. Add support for it. Signed-off-by:
Christian Oder <me@myself5.de> Signed-off-by:
-
Rikard Falkeborn authored
mmc35240_reg_defaults is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 9759 3288 128 13175 3377 drivers/iio/magnetometer/mmc35240.o After: text data bss dec hex filename 9823 3224 128 13175 3377 drivers/iio/magnetometer/mmc35240.o Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Rikard Falkeborn authored
stk3310_regmap_config is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 16027 5424 128 21579 544b drivers/iio/light/stk3310.o After: text data bss dec hex filename 16347 5104 128 21579 544b drivers/iio/light/stk3310.o Signed-off-by:
-
Rikard Falkeborn authored
ad5592r_ext_info is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 13293 2088 256 15637 3d15 drivers/iio/dac/ad5592r-base.o After: text data bss dec hex filename 13421 1960 256 15637 3d15 drivers/iio/dac/ad5592r-base.o Signed-off-by:
-
Rikard Falkeborn authored
ad5380_ext_info is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 12060 3280 192 15532 3cac drivers/iio/dac/ad5380.o After: text data bss dec hex filename 12252 3088 192 15532 3cac drivers/iio/dac/ad5380.o Signed-off-by:
-
Rikard Falkeborn authored
max11100_channels is not modified and can therefore be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 3776 1168 0 4944 1350 drivers/iio/adc/max11100.o After: text data bss dec hex filename 3968 976 0 4944 1350 drivers/iio/adc/max11100.o Signed-off-by:
-
Andy Shevchenko authored
acpi_dev_get_resources() does perform the NULL pointer check against ACPI companion device which is given as function parameter. Thus, there is no need to duplicate this check in the caller. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Jonathan Albrieux authored
According to AK09911 datasheet, if reset gpio is provided then deassert reset on ak8975_power_on() and assert reset on ak8975_power_off(). Without reset's deassertion during ak8975_power_on(), driver's probe fails on ak8975_who_i_am() while checking for device identity for AK09911 chip. AK09911 has an active low reset gpio to handle register's reset. AK09911 datasheet says that, if not used, reset pin should be connected to VID. This patch emulates this situation. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
Jonathan Albrieux authored
Minor comment style edits. Signed-off-by:
-
Jonathan Albrieux authored
Add reset-gpio support. Without reset's deassertion during ak8975_power_on(), driver's probe fails on ak8975_who_i_am() while checking for device identity for AK09911 chip. AK09911 has an active low reset gpio to handle register's reset. AK09911 datasheet says that, if not used, reset pin should be connected to VID. This patch emulates this situation. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jonathan Albrieux authored
Converts documentation from txt format to yaml. Signed-off-by:
-
Jonathan Albrieux authored
Reword gpios documentation, add interrupt documentation and fix styles. Update example to use interrupts instead of gpios. Signed-off-by:
-
Jishnu Prakash authored
Change pr_err/pr_debug statements to dev_err/dev_dbg for increased clarity. Signed-off-by:
Jishnu Prakash <jprakash@codeaurora.org> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Jishnu Prakash authored
Clean up some return value checks to make code more compact. Signed-off-by:
-
Jishnu Prakash authored
The ADC architecture on PMIC7 is changed as compared to PMIC5. The major change from PMIC5 is that all SW communication to ADC goes through PMK8350, which communicates with other PMICs through PBS when the ADC on PMK8350 works in master mode. The SID register is used to identify the PMICs with which the PBS needs to communicate. Add support for the same. Signed-off-by:
-
Jishnu Prakash authored
Add info property under adc_data to support adding ADC variants which may use different iio_info than the one defined for PMIC5. Signed-off-by:
-
Jishnu Prakash authored
Add documentation for PMIC7 ADC peripheral. For the PMIC7-type PMICs, ADC peripheral is present in HW for the following PMICs: PMK8350, PM8350, PM8350b, PMR735a and PMR735b. Of these, only the ADC peripheral on PMK8350 is exposed directly to SW. If SW needs to communicate with ADCs on other PMICs, it specifies the PMIC to PMK8350 through the newly added SID register and communication between PMK8350 ADC and other PMIC ADCs is carried out through PBS(Programmable Boot Sequence) at the firmware level. In addition, add definitions for ADC channels and virtual channel definitions (combination of ADC channel number and PMIC SID number) per PMIC, to be used by ADC clients for PMIC7. Signed-off-by:
Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by:
-
Jishnu Prakash authored
Convert the adc bindings from .txt to .yaml format. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Robertson authored
Add basic support for the Bosch Sensortec BMA400 3-axes ultra-low power accelerometer when configured to use SPI. Signed-off-by:
Dan Robertson <dan@dlrobertson.com> Signed-off-by:
-
Matt Ranostay authored
Move ret variable to the IIO_CHAN_INFO_RAW switch since currently only used within that scope. Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, removing the iio_priv_to_dev() helper means passing the iio_dev object on hts221_allocate_buffers() & hts221_allocate_trigger(). Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, removing iio_priv_to_dev() also means keeping a reference on the state struct. Signed-off-by:
Jeff LaBundy <jeff@labundy.com> Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, removing iio_priv_to_dev() means keeping a reference on the state struct. Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. That's a bit uncertain at this point. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. For this driver, it implies passing the IIO device on the i2c client private data. The implementation of iio_priv() will not be affected by the rework/hiding of iio_priv_to_dev(). Signed-off-by:
-
- 12 Jun, 2020 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull the Kernel Concurrency Sanitizer from Thomas Gleixner: "The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which relies on compile-time instrumentation, and uses a watchpoint-based sampling approach to detect races. The feature was under development for quite some time and has already found legitimate bugs. Unfortunately it comes with a limitation, which was only understood late in the development cycle: It requires an up to date CLANG-11 compiler CLANG-11 is not yet released (scheduled for June), but it's the only compiler today which handles the kernel requirements and especially the annotations of functions to exclude them from KCSAN instrumentation correctly. These annotations really need to work so that low level entry code and especially int3 text poke handling can be completely isolated. A detailed discussion of the requirements and compiler issues can be found here: https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com/ We came to the conclusion that trying to work around compiler limitations and bugs again would end up in a major trainwreck, so requiring a working compiler seemed to be the best choice. For Continous Integration purposes the compiler restriction is manageable and that's where most xxSAN reports come from. For a change this limitation might make GCC people actually look at their bugs. Some issues with CSAN in GCC are 7 years old and one has been 'fixed' 3 years ago with a half baken solution which 'solved' the reported issue but not the underlying problem. The KCSAN developers also ponder to use a GCC plugin to become independent, but that's not something which will show up in a few days. Blocking KCSAN until wide spread compiler support is available is not a really good alternative because the continuous growth of lockless optimizations in the kernel demands proper tooling support" * tag 'locking-kcsan-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (76 commits) compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining compiler.h: Move function attributes to compiler_types.h compiler.h: Avoid nested statement expression in data_race() compiler.h: Remove data_race() and unnecessary checks from {READ,WRITE}_ONCE() kcsan: Update Documentation to change supported compilers kcsan: Remove 'noinline' from __no_kcsan_or_inline kcsan: Pass option tsan-instrument-read-before-write to Clang kcsan: Support distinguishing volatile accesses kcsan: Restrict supported compilers kcsan: Avoid inserting __tsan_func_entry/exit if possible ubsan, kcsan: Don't combine sanitizer with kcov on clang objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn() kcsan: Add __kcsan_{enable,disable}_current() variants checkpatch: Warn about data_race() without comment kcsan: Use GFP_ATOMIC under spin lock Improve KCSAN documentation a bit kcsan: Make reporting aware of KCSAN tests kcsan: Fix function matching in report kcsan: Change data_race() to no longer require marking racing accesses kcsan: Move kcsan_{disable,enable}_current() to kcsan-checks.h ... -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull atomics rework from Thomas Gleixner: "Peter Zijlstras rework of atomics and fallbacks. This solves two problems: 1) Compilers uninline small atomic_* static inline functions which can expose them to instrumentation. 2) The instrumentation of atomic primitives was done at the architecture level while composites or fallbacks were provided at the generic level. As a result there are no uninstrumented variants of the fallbacks. Both issues were in the way of fully isolating fragile entry code pathes and especially the text poke int3 handler which is prone to an endless recursion problem when anything in that code path is about to be instrumented. This was always a problem, but got elevated due to the new batch mode updates of tracing. The solution is to mark the functions __always_inline and to flip the fallback and instrumentation so the non-instrumented variants are at the architecture level and the instrumentation is done in generic code. The latter introduces another fallback variant which will go away once all architectures have been moved over to arch_atomic_*" * tag 'locking-urgent-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/atomics: Flip fallbacks and instrumentation asm-generic/atomic: Use __always_inline for fallback wrappers -
Linus Torvalds authored
Pull updates from Andrew Morton: "A few fixes and stragglers. Subsystems affected by this patch series: mm/memory-failure, ocfs2, lib/lzo, misc" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: amdgpu: a NULL ->mm does not mean a thread is a kthread lib/lzo: fix ambiguous encoding bug in lzo-rle ocfs2: fix build failure when TCP/IP is disabled mm/memory-failure: send SIGBUS(BUS_MCEERR_AR) only to current thread mm/memory-failure: prioritize prctl(PR_MCE_KILL) over vm.memory_failure_early_kill
-
Christoph Hellwig authored
Use the proper API instead. Fixes: 70539bd7 ("drm/amd: Update MEC HQD loading code for KFD") Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
Jens Axboe <axboe@kernel.dk> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dave Rodgman authored
In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Signed-off-by:
Dave Rodgman <dave.rodgman@arm.com> Signed-off-by:
-
