This both ensures this binding is compliant with the generic properties
and reduces the amount we need to specify in this separate binding.
Whilst here mark the child node as additionalProperties: false
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031182423.742798-3-jic23@kernel.org
Each driver that uses this will need to use a $ref
We can't always enable it like most of the generic bindings due to
channel@X matching far more widely than IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031182423.742798-2-jic23@kernel.org
This basically has same questions as for the afe4403. We could combine
the two bindings, but as the drivers are separate and it would be a little
fiddly due to different buses let's keep the separating.
To repeat questions from the ti,afe4403 binding.
A few questions came up whilst converting this one.
1) What is actually required?
- Checking Linux driver, interrupt is not, and the tx-supply could
be supplied by a stub regulator as long as it's always on.
As such I have reduced the required list to just compatible and reg.
2) What is the regulator called?
- It's tx-supply in the binding doc, but the driver request tx_sup
I will shortly send out a fix for the driver to match the binding
doc which is the better choice of naming.
As Andrew's email is bouncing, I've put myself as temporary maintainer
for this binding until someone else steps up.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-9-jic23@kernel.org
A few questions came up whilst converting this one.
1) What is actually required?
- Checking Linux driver, interrupt is not, and the tx-supply could
be supplied by a stub regulator as long as it's always on.
As such I have reduced the required list to just compatible and reg.
2) What is the regulator called?
- It's tx-supply in the binding doc, but the driver requests tx_sup.
I'll post a fix patch to change the driver to fix this as it makes
little sense.
Andrew's email is bouncing so until someone else steps up I have
listed myself as maintainer for this binding.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-8-jic23@kernel.org
When updating the buffer demux, we will skip a scan element from the
device in the case `in_ind != out_ind` and we enter the while loop.
in_ind should only be refreshed with `find_next_bit()` in the end of the
loop.
Note, to cause problems we need a situation where we are skippig over
an element (channel not enabled) that happens to not have the same size
as the next element. Whilst this is a possible situation we haven't
actually identified any cases in mainline where it happens as most drivers
have consistent channel storage sizes with the exception of the timestamp
which is the last element and hence never skipped over.
Fixes: 5ada4ea9be ("staging:iio: add demux optionally to path from device to buffer")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio_format_list() has two branches in a switch statement that are almost
identical. They only differ in the stride that is used to iterate through
the item list.
Consolidate this into a common code path to simplify the code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201114120000.6533-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_format_avail_list() and iio_format_avail_range() functions are
almost identical. The only differences are that iio_format_avail_range()
expects a fixed amount of items and adds brackets "[ ]" around the output.
Refactor them into a common helper function. This improves the
maintainability of the code as it makes it easier to modify the
implementation of these functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201114120000.6533-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
io-channel-ranges is a property for consumers of io-channels, not
providers. Hence it is not relevant in this binding or the examples
given.
Recent changes to dt-schema result in this being reported as an error
as a dependency is enforced between this property and io-channels.
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201115192951.1073632-3-jic23@kernel.org
io-channel-ranges is a property for io-channel consumers. Here
it is in an example of a provider of channels so doesn't do anything
useful.
Recent additions to dt-schema check this property is only provided
alongside io-channels which is not true here and hence an error is
reported.
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Jishnu Prakash <jprakash@codeaurora.org>
Link: https://lore.kernel.org/r/20201115192951.1073632-2-jic23@kernel.org
The driver should assert reset by setting the gpio high, and
then release it by setting it the gpio low. This allows the
device tree (or other hardware definition) to specify how the
gpio is configured.
For example as open drain or push-pull depending on the
connected hardware.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Link: https://lore.kernel.org/r/20201124050014.4453-1-preid@electromag.com.au
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These Bosch accelerometers have two supplies, VDD and VDDIO.
Add some rudimentary support to obtain and enable these
regulators during probe() and disable them during remove()
or on the errorpath.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-3-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This adds support for the BMA222 version of this sensor,
found in for example the Samsung GT-I9070 mobile phone.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201115205745.618455-2-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These accelerometers have bindings used in the kernel and
several device trees but no proper bindings documentation.
Add it.
Also add a compatible for the BMA222 that I am right now
adding support for in the driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: devicetree@vger.kernel.org
Link: https://lore.kernel.org/r/20201115205745.618455-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Use a heap allocated memory for the SPI transfer buffer. Using stack memory
can corrupt stack memory when using DMA on some systems.
This change moves the buffer from the stack of the trigger handler call to
the heap of the buffer of the state struct. The size increases takes into
account the alignment for the timestamp, which is 8 bytes.
The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer
separation of which part of the buffer should be used for TX & RX.
Fixes: af3008485e ("iio:adc: Add common code for ADI Sigma Delta devices")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Return error in case no callback is provided to
`iio_channel_get_all_cb()`. There's no point in setting up a buffer-cb
if no callback is provided.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Olivier Moysan <olivier.moysan@st.com>
Link: https://lore.kernel.org/r/20201121161457.957-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adapt STM32 DFSDM driver to a change in iio_channel_get_all_cb() API.
The callback pointer becomes a requested parameter of this API,
so add a dummy callback to be given as parameter of this function.
However, the stm32_dfsdm_get_buff_cb() API is still used instead,
to optimize DMA transfers.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20201121161457.957-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
'st->ext_ref' & 'st->reg' are both non-zero/non-null at the same time, so
logically the code isn't broken.
But it is more correct to check that 'st->reg' is non-null, since we make
sure that the regulator is NULL (in probe) in case one isn't defined.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201127094038.91714-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change converts the probe of this driver to use device-managed
register functions, and a devm_add_action_or_reset() for the regulator
disable.
With this, the exit & error paths can be removed.
Another side-effect is that this should avoid some static-analyzer's check
with respect to a potential null dereference of the regulator. The null
dereference isn't likely to happen (under normal operation), so there isn't
a requirement to have this fixed/backported in other releases.
As a note: this is removing spi_set_drvdata() since there is no other
spi_get_drvdata() (or dev_get_drvdata()) call that need it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201127094038.91714-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
So far, the thermocouple-type property described in here is only
used in a single driver. Whilst I would like it to be more generally
used that hasn't happened yet and I don't see a reason to maintain
this small file in the hope that it happens.
I pushed for this generic binding in the first place. Hopefully
we can bring it back at somepoint.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Link: https://lore.kernel.org/r/20201031184854.745828-47-jic23@kernel.org
This is a large but fairly simple binding.
It may well be possible to constrain some of the properties more than
currently done, but that would involve diving into datasheets for the
supported parts. Hence for this initial conversion just use the
information that was in the txt file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-46-jic23@kernel.org
This binding document covers a very large number of different sensors.
As such the existing documentation is less specific than it could
be (such as which devices have 2 interrupt pin options).
That can be improved later.
Denis, are you happy to be listed as maintainer for this one?
If not feel free to suggestion someone else.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Link: https://lore.kernel.org/r/20201031184854.745828-45-jic23@kernel.org
Very simple direct conversion of existing txt file.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/20201031184854.745828-44-jic23@kernel.org
Simple binding so mostly straight forward to convert.
Original binding was unclear on how many interrupts there are.
The device has two such lines, whilst I believe the driver currently
only uses one at a time. The binding should allow both to be specified.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Martin Kepplinger <martin.kepplinger@theobroma-systems.com>
Link: https://lore.kernel.org/r/20201031184854.745828-43-jic23@kernel.org
Very simple binding hence a straight forward conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Robert Yang <decatf@gmail.com>
Link: https://lore.kernel.org/r/20201031184854.745828-42-jic23@kernel.org
One question in here is whether we want to constrain the number of
interrupts. Some parts definitely only have 1 such pin, and others
2 pins but I can not find information on the bma254.
Oleksandr's email address is bouncing so I've listed myself as
maintainer for this binding until someone else steps up.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-41-jic23@kernel.org
This is a more complex binding. Whilst conversion is straight forward
I am unsure if the full nature of required properties has been captured.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031184854.745828-39-jic23@kernel.org
Simple binding so straight forward format conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20201031184854.745828-38-jic23@kernel.org
Straight forward conversion. Not heard from Ivan in a while so if the
email bounces, I'll change the maintainer to myself for this binding unless
anyone else comes forwards.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-37-jic23@kernel.org
Renamed to match a listed compatible rather than relying on wildcards
with all their usual problems.
Dropped the reference supply as a requirement as at least one dtsi doesn't
include it and the example never did.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201031184854.745828-36-jic23@kernel.org
Simple conversion of the binding doc for this subnode of the palmas
PMIC.
Given age of driver and lack interaction with original authors,
I've guessed at Tony for a maintainer on this one. Tony, if you
are happy with that great, otherwise I can default back to myself.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20201031184854.745828-35-jic23@kernel.org
The current driver and indeed binding are named after a part that they
do not list in the compatible. Hence renamed the binding to reflect
one that does.
>From the driver it looks like there is a lot more backwards compatibility
than the binding currently reflects. We could consider expressing that
more explicitly in the yaml for the compatible property. I have
added one explicit pair that was present in the upstream dtsi files.
I added Matthias alongside Zhiyong Tao because I don't think
Zhiyong Tao has reviewed recent patches. Please let me know if this
isn't the right thing to do.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Zhiyong Tao <zhiyong.tao@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20201031184854.745828-34-jic23@kernel.org
A few questions came up in this one.
1) Why does the txt file document io-channel-ranges as a required property.
That property is for iio-channel consumers, and this is a provider.
I have dropped it.
2) The example had an @180a6000 for the ADC but given it uses syscon for
all access, it doesn't have its own reg etc. I've dropped that from
the binding example.
Note this example was lifted directly from bcm-cygnus.dtsi so both
issues are present there as well.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
Link: https://lore.kernel.org/r/20201031184854.745828-33-jic23@kernel.org
Usual mixed bag of new drivers / device support + cleanups etc with the
addition of a fairly big set of yaml conversions.
Txt to yaml format conversions.
In some cases dropped separate binding and moved to trivial devices (drop).
Listed by manufacturer
- dht11 temperature(drop)
- adi,ad2s90 adi,ad5272 adi,ad5592r adi,ad5758 adi,ad5933 adi,ad7303
adi,adis16480 adi,adf4350
- ams,as3935
- asahi-kasei,ak8974
- atmel,sama5d2-adc
- avago,apds9300 avago,apds9960
- bosch,bma180 bosch,bmc150_magn bosch,bme680 bosch,bmg180
- brcm,iproc-static-adc
- capella,cm36651
- domintech,dmard06(drop)
- fsl,mag3110 fsl,mma8452 fsl,vf610-dac
- hoperf,hp03
- honeywell,hmc5843
- kionix,kxcjk1013
- maxim,ds1803(drop) maxim,ds4424 maxim,max30100 maxim,max30102
maxim,max31856 maxim,max31855k maxim,max44009
maxim,max5481 maxim,max5821
- meas,htu21(drop) meas,ms5367(drop) meas,ms5611 meas,tsys01(drop)
- mediatek,mt2701-auxadc
- melexis,mlx90614 melexis,mlx90632
- memsic,mmc35240(drop)
- microchip,mcp41010 microchip,mcp4131 microchip,mcp4725
- murata,zap2326
- nxp,fxas21002c nxp,lpc1850-dac
- pni,rm3100
- qcom,pm8018-adc qcom,spmi-iadc
- renesas,isl29501 renesas,rcar-gyroadc
- samsung,sensorhub-rinato
- sensiron,sgp30
- sentech,sx9500
- sharp,gp2ap020a00f
- st,hts221 st,lsm6dsx st,st-sensors(many!) st,uvis25 st,vcl53l0x st,vl6180
- ti,adc084s021 ti,ads124s08
ti,dac5571 ti,dac7311 ti,dac7512 ti,dac7612
ti,hdc1000(drop) ti,palmas-gpadc ti,opt3001 ti,tmp07
- upisemi,us51882
- vishay,vcnl4035
- x-powers,axp209
New device support
* adi,ad5685
- Add support for AD5338R dual output 10-bit DAC
- Add DT-binding doc.
* mediatek,mt6360
- New driver for this SoC ADC with bindings and using new channel label
support in the IIO core.
* st,lsm6dsx
- Add support for LSM6DST
Core:
* Add "label" to device channels, provided via a new core callback. Including
DT docs for when that is the source, and ABI docs.
* Add devm_iio_triggered_buffer_setup_ext to take extra attributes.
* dmaengine, unwrap use of iio_buffer_set_attrs()
* Drop iio_buffer_set_attrs()
* Centralize ioctl call handling. Later fix to ensure -EINVAL returned if
no handler has run.
* Fix an issue with IIO_VAL_FRACTIONAL and negative values - doesn't affect
any known existing drivers, but will impact a future one.
* kernel-doc fix in trigger.h
* file-ops ordering cleanup
Features
* semtech,sx9310
- Add control of hardware gain, proximity thresholds, hysteresis and
debounce.
- Increase what information on hardware configuration can be provided
via DT.
Cleanup and minor features
* adi,ad5685
- Add of_match_table
* adi,ad7292
- Drop pointless spi_set_drvdata() call
* adi,ad7298
- Drop platform data and tidy up external reference config.
* adi,ad7303
- Drop platform data handling as unused.
* adi,ad7768
- Add new label attribute for channels provided from dt.
* adi,ad7887
- devm_ usage in probe simplifying remove and error handling.
* adi,adis16201
- Drop pointless spi_set_drvdata() call
* adi,adis16209
- Drop pointless spi_set_drvdata() call
* adi,adis16240
- White space fixup
* adi,adxl372
- use new devm_iio_triggered-buffer_setup_ext()
* amlogic,meson-saradc
- Drop pointless semicolon.
* amstaos,tsl2563
- Put back i2c_device_id table as needed for greybus probing.
* atmel,at91_adc
- Use of_device_get_match_data() instead of open coding it.
- Constify some driver data
- Add KCONFIG dep on CONFIG_OF and drop of_match_ptr()
- Drop platform data as mostly dead code.
- Tidy up reference voltage logic
* atmel-sama5d2
- Drop a pointless semicolon
- Merge buffer and trigger init into a separate function
- Use new devm_iio_triggered_buff_setup_ext()
* avago,apds9960
- Drop a pointless semicolon
* bosch,bmc150
- Drop a pointless semicolon
- Use new iio_triggered_buffer_setup_ext()
* bosch,bmp280
- Drop a pointless semicolon
* fsl,mma8452
- Constification
* (google),cros_ec
- Use new devm_iio_triggered_buffer_setup_ext()
* hid-sensors
- Use new iio_triggered_buffer_setup_ext()
* ingenic,adc
- Drop a pointless semicolon
* invensense,icm426xx
- Fix MAINTAINERS entry missing :
* mediatek,mt6577_audxac
- Add binding doc for mt8516 compatible with mt8173
* motorola,cpcap-adc
- Fix an implicit fallthrough marking that clang needs to avoid warning.
* samsung,exynos-adc
- Stop relying on users counter form input device in ISR.
* st,lsm6dsx
- add vdd and vddio regulator control (including binding update)
* st,stm32-adc
- Tidy up code for dma transfers.
- Adapt clock duty cycle for proper functioning. Note no known problems
with existing boards.
* st,vl53l0x-i2c
- Put back i2c_device_id table as needed for greybus probing.
* vishay,vcnl4035
- Put back i2c_device_id table as needed for greybus probing.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAl+8H3IRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FogLLA//cE+rUI0ztkE5KD1DY5mu8dy3GotLJe2y
kVlYao/8H4n3qL9Sm+i47v7pZZfB6UH5jaPa3BqXcGU3HaBaTSza5VhP/hDyfpgD
Nt46UyE0FxcNEpwqiiyVuVFFx9ifUOayzKwL9ckyPs7n1X6ecZA+sPdmSQLmFzoZ
IYDR148UxlAr33j7DVF1DLiIdObCIpNc3pn7YDflT/NnXvRY2XgIjqeOiPbldVgm
8nGgeSQXTyYBKaSyv6seE2qaxyDAhjkz7SVOidWZxPgMjiJJmpRdL3yCn2wVCCCy
eLh9Ez0zPhywOhsRImICZ9ds0+Wq1Ke2kVqo0N8FJtB+JVZig+R1ElTaUKhES7B2
zKW1PR3nknP2oo3LWoXL6QR4vm0RcasRYnE2Qmtv6y04Hv3vbdyx6ZW+WCwrlsM8
fCxHV/m/NN4piTHEFFFkW912GMZM4XqnJ/H4bLd4oA+HP/2vzMuzdBLKZPZRdYYf
Xd2YTF+iyNYlbN+ZLDd9840cAcKabPsd+ptaJh7lb0MUPPcv5qukhwIBs1/vqrE6
9/AnJ/Wj/oQZoDbcrgnMVoRn8dxqnQkd883sxiHZAvztEn1CQ9dDyUfKlHHB5BOD
GhtrEyMn87VWM19yqArW/3ZU7dPBbXHkzlw6FQ67gIYbqaCRwfRi26FCJh0C6Kzi
auCmjubaALo=
=kkcj
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.11a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First set of new device support, features and cleanups for IIO in the 5.11 cycle
Usual mixed bag of new drivers / device support + cleanups etc with the
addition of a fairly big set of yaml conversions.
Txt to yaml format conversions.
In some cases dropped separate binding and moved to trivial devices (drop).
Listed by manufacturer
- dht11 temperature(drop)
- adi,ad2s90 adi,ad5272 adi,ad5592r adi,ad5758 adi,ad5933 adi,ad7303
adi,adis16480 adi,adf4350
- ams,as3935
- asahi-kasei,ak8974
- atmel,sama5d2-adc
- avago,apds9300 avago,apds9960
- bosch,bma180 bosch,bmc150_magn bosch,bme680 bosch,bmg180
- brcm,iproc-static-adc
- capella,cm36651
- domintech,dmard06(drop)
- fsl,mag3110 fsl,mma8452 fsl,vf610-dac
- hoperf,hp03
- honeywell,hmc5843
- kionix,kxcjk1013
- maxim,ds1803(drop) maxim,ds4424 maxim,max30100 maxim,max30102
maxim,max31856 maxim,max31855k maxim,max44009
maxim,max5481 maxim,max5821
- meas,htu21(drop) meas,ms5367(drop) meas,ms5611 meas,tsys01(drop)
- mediatek,mt2701-auxadc
- melexis,mlx90614 melexis,mlx90632
- memsic,mmc35240(drop)
- microchip,mcp41010 microchip,mcp4131 microchip,mcp4725
- murata,zap2326
- nxp,fxas21002c nxp,lpc1850-dac
- pni,rm3100
- qcom,pm8018-adc qcom,spmi-iadc
- renesas,isl29501 renesas,rcar-gyroadc
- samsung,sensorhub-rinato
- sensiron,sgp30
- sentech,sx9500
- sharp,gp2ap020a00f
- st,hts221 st,lsm6dsx st,st-sensors(many!) st,uvis25 st,vcl53l0x st,vl6180
- ti,adc084s021 ti,ads124s08
ti,dac5571 ti,dac7311 ti,dac7512 ti,dac7612
ti,hdc1000(drop) ti,palmas-gpadc ti,opt3001 ti,tmp07
- upisemi,us51882
- vishay,vcnl4035
- x-powers,axp209
New device support
* adi,ad5685
- Add support for AD5338R dual output 10-bit DAC
- Add DT-binding doc.
* mediatek,mt6360
- New driver for this SoC ADC with bindings and using new channel label
support in the IIO core.
* st,lsm6dsx
- Add support for LSM6DST
Core:
* Add "label" to device channels, provided via a new core callback. Including
DT docs for when that is the source, and ABI docs.
* Add devm_iio_triggered_buffer_setup_ext to take extra attributes.
* dmaengine, unwrap use of iio_buffer_set_attrs()
* Drop iio_buffer_set_attrs()
* Centralize ioctl call handling. Later fix to ensure -EINVAL returned if
no handler has run.
* Fix an issue with IIO_VAL_FRACTIONAL and negative values - doesn't affect
any known existing drivers, but will impact a future one.
* kernel-doc fix in trigger.h
* file-ops ordering cleanup
Features
* semtech,sx9310
- Add control of hardware gain, proximity thresholds, hysteresis and
debounce.
- Increase what information on hardware configuration can be provided
via DT.
Cleanup and minor features
* adi,ad5685
- Add of_match_table
* adi,ad7292
- Drop pointless spi_set_drvdata() call
* adi,ad7298
- Drop platform data and tidy up external reference config.
* adi,ad7303
- Drop platform data handling as unused.
* adi,ad7768
- Add new label attribute for channels provided from dt.
* adi,ad7887
- devm_ usage in probe simplifying remove and error handling.
* adi,adis16201
- Drop pointless spi_set_drvdata() call
* adi,adis16209
- Drop pointless spi_set_drvdata() call
* adi,adis16240
- White space fixup
* adi,adxl372
- use new devm_iio_triggered-buffer_setup_ext()
* amlogic,meson-saradc
- Drop pointless semicolon.
* amstaos,tsl2563
- Put back i2c_device_id table as needed for greybus probing.
* atmel,at91_adc
- Use of_device_get_match_data() instead of open coding it.
- Constify some driver data
- Add KCONFIG dep on CONFIG_OF and drop of_match_ptr()
- Drop platform data as mostly dead code.
- Tidy up reference voltage logic
* atmel-sama5d2
- Drop a pointless semicolon
- Merge buffer and trigger init into a separate function
- Use new devm_iio_triggered_buff_setup_ext()
* avago,apds9960
- Drop a pointless semicolon
* bosch,bmc150
- Drop a pointless semicolon
- Use new iio_triggered_buffer_setup_ext()
* bosch,bmp280
- Drop a pointless semicolon
* fsl,mma8452
- Constification
* (google),cros_ec
- Use new devm_iio_triggered_buffer_setup_ext()
* hid-sensors
- Use new iio_triggered_buffer_setup_ext()
* ingenic,adc
- Drop a pointless semicolon
* invensense,icm426xx
- Fix MAINTAINERS entry missing :
* mediatek,mt6577_audxac
- Add binding doc for mt8516 compatible with mt8173
* motorola,cpcap-adc
- Fix an implicit fallthrough marking that clang needs to avoid warning.
* samsung,exynos-adc
- Stop relying on users counter form input device in ISR.
* st,lsm6dsx
- add vdd and vddio regulator control (including binding update)
* st,stm32-adc
- Tidy up code for dma transfers.
- Adapt clock duty cycle for proper functioning. Note no known problems
with existing boards.
* st,vl53l0x-i2c
- Put back i2c_device_id table as needed for greybus probing.
* vishay,vcnl4035
- Put back i2c_device_id table as needed for greybus probing.
* tag 'iio-for-5.11a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (126 commits)
dt-bindings:iio:adc:x-powers,axp209-adc: txt to yaml conversion
dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to yaml conversion.
dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml conversion
dt-bindings:iio:magnetometer:pni,rm3100: txt to yaml conversion.
dt-bindings:iio:magnetometer:honeywell,hmc5843: txt to yaml format conversion
dt-bindings:iio:magnetometer:bosch,bmc150_magn: txt to yaml conversion.
dt-bindings:iio:magnetometer:asahi-kasei,ak8974: txt to yaml format conversion
dt-bindings:iio:magnetometer:fsl,mag3110: txt to yaml conversion
dt-bindings:iio:light:st,vl6180: txt to yaml format conversion.
dt-bindings:iio:light:vishay,vcnl4035: txt to yaml conversion
dt-bindings:iio:light:st,uvis25: txt to yaml conversion for this UV sensor
dt-bindings:iio:light:upisemi,us51882: txt to yaml conversion.
dt-bindings:iio:light:ti,opt3001: txt to yaml conversion
dt-bindings:iio:light:maxim,max44009: txt to yaml conversion.
dt-bindings:iio:light:sharp,gp2ap020a00f: txt to yaml conversion.
dt-bindings:iio:light:capella,cm36651: txt to yaml conversion.
dt-bindings:iio:light:avago,apds9960: txt to yaml conversion
dt-bindings:iio:light:avago,apds9300: txt to yaml conversion.
dt-bindings:iio:imu:st,lsm6dsx: txt to yaml conversion
dt-bindings:iio:imu:adi,adis16480: txt to yaml conversion
...
This is a very small binding. It might make sense at some stage
to just roll it into the parent mfd. For now, converted as is.
The main advantage of this document is the identification of the
channel index values when this is used as a provider of ADC channels
to consumers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031184854.745828-32-jic23@kernel.org
The structures defined in the dpsw-cmd.h header file describe exactly
the layout of commands accepted by the MC firmware. Make sure that all
these structures are packed.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20201119165017.806696-4-ciorneiioana@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When in the PREPARE state of a switchdev transaction, check if the
requested VLAN is not already configured on the switch port. This keeps
us from getting into a WARNING as below.
[ 1389.683296] dpaa2_ethsw dpsw.0 eth0: VLAN 2 already configured
[ 1389.689125] ------------[ cut here ]------------
[ 1389.694084] eth0: Commit of object (id=1) failed.
[ 1389.698863] WARNING: CPU: 0 PID: 613 at net/switchdev/switchdev.c:277 switchdev_port_obj_add_now+0xcc/0x110
[ 1389.708589] Modules linked in:
[ 1389.711634] CPU: 0 PID: 613 Comm: bridge Not tainted 5.9.0-rc2-next-20200828-00112-g7172078477c5 #59
[ 1389.720753] Hardware name: NXP Layerscape LX2160ARDB (DT)
[ 1389.726139] pstate: 40000005 (nZcv daif -PAN -UAO BTYPE=--)
[ 1389.731698] pc : switchdev_port_obj_add_now+0xcc/0x110
[ 1389.736824] lr : switchdev_port_obj_add_now+0xcc/0x110
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20201119165017.806696-3-ciorneiioana@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Export the DPSW_CNT_ING_NO_BUFFER_DISCARD counter in ethtool for each
switch interface. This is useful for debugging purposes.
Signed-off-by: Ionut-robert Aron <ionut-robert.aron@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20201119165017.806696-2-ciorneiioana@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The bool variable is2T is true, so the if statement is redundant.
we can directly set the variable bound to 8 and remove the if
statement.
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Link: https://lore.kernel.org/r/1605961041-12875-1-git-send-email-kaixuxia@tencent.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two bool variables singletone and carrier_sup are always false
and the following if statement can't be true, these code are useless,
so remove them.
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Link: https://lore.kernel.org/r/1605442400-16108-1-git-send-email-kaixuxia@tencent.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 4524ac56cd ("staging: mfd: add a PMIC driver for HiSilicon 6421 SPMI version")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Link: https://lore.kernel.org/r/20201118103724.57451-1-wanghai38@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MFD_CORE is selected by MFD_HI6421_SPMI, and MFD_CORE depends on
HAS_IOMEM. If HAS_IOMEM is not set, this can cause a conflict in Kconfig
resolution, yielding the following error:
WARNING: unmet direct dependencies detected for MFD_CORE
Depends on [n]: HAS_IOMEM [=n]
Selected by [y]:
- MFD_HI6421_SPMI [=y] && STAGING [=y] && OF [=y] && SPMI [=y]
By specifying HAS_IOMEM as a dependency for MFD_HI6421_SPMI (as
SPMI_HISI3670 already dows), this issue is resolved, and no such warning
appears when building on architectures without HAS_IOMEM.
Signed-off-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20201119082903.3601758-1-davidgow@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the following warnings reported by sparse, by adding
missing __force annotations.
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:239:25: warning: cast from restricted __be32
Rationale for #164:
data is declared as u32, and it is read and then converted by means of
be32_to_cpu(). Said function expects a __be32 but data is u32, therefore
there's a type missmatch here.
Rationale for #239:
Is the dual of #164. This time data going to be written so it
needs to be converted from cpu to __be32, but writel() expects u32 and the
output of cpu_to_be32 returns a __be32.
Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com>
Link: https://lore.kernel.org/r/20201119122737.189675-1-juant.aldea@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
