| Age | Commit message (Collapse) | Author |
|---|
|
The trigger child nodes are not necessary anymore as they are defined
directly by the driver, depending on the compatible string.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lore.kernel.org/r/20201128222818.1910764-7-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Move the available trigger definition back in the driver to stop cluttering
the device tree. There is no functional change except that it actually
fixes the available triggers for at91sam9rl as it inherited the list from
at91sam9260 but actually has the triggers from at91sam9x5.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-6-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
There are a few things we would do differently in an ADC binding if we
were starting from scratch but we are stuck with what we have (which
made sense back when this was written!)
We may be able to tighten up some elements of this binding in the future
by careful checking of what values properties can actually take.
Note the unusual sign off chain is representative of the path this patch
took.
Jonathan wrote the patch, which was then included in a series by
Alexandre and ultimately applied by Jonathan.
[Alexandre Belloni: add sama5d3, remove atmel,adc-res and atmel,adc-res-names]
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-5-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Remove atmel,adc-res and atmel,adc-res-names as they are not necessary and
are handled by the driver. Also add sama5d3 to the list of possible chips.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lore.kernel.org/r/20201128222818.1910764-4-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Move the possible resolution values back to the driver. This removes the
atmel,adc-res and atmel,adc-res-names properties, leaving only
atmel,adc-use-res. As atmel,adc-res-names had to contain "lowres" and
"highres", those where already the only allowed values for
atmel,adc-use-res.
Also introduce a new compatible string for the sama5d3 as this is the only
one with a different resolution. Also it doesn't even have the LOWRES
bit.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-3-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The driver is DT only since commit ead1c9f376db ("iio: adc: at91_adc:
remove platform data and move defs in driver file"). Remove the leftover
platform_device_id array.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201128222818.1910764-2-alexandre.belloni@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
There were a few parts of the example that did not conform to the
binding description and would not have worked with the Linux driver
as a result. Fixed them whilst doing this conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20201031181242.742301-11-jic23@kernel.org
|
|
Simple conversion using the new iio-consumers.yaml binding in the
dt-schema.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201031181242.742301-10-jic23@kernel.org
|
|
Simple binding so straight forward conversion, though did require
adding a separate binding document for the max1027 to reflect
its abilities to provide channels to consumers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-9-jic23@kernel.org
|
|
The afe/voltage-divider.yaml example uses this device with 2 properties
not provided by trivial-devices.yaml (spi-max-frequency and #io-channel-cells)
Solve that by creating a more specific binding doc.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Link: https://lore.kernel.org/r/20201031181242.742301-8-jic23@kernel.org
|
|
Very simple binding. As such straight forward conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-7-jic23@kernel.org
|
|
Note this includes a fix in the example where we had *-mul instead of
*-mult. The binding doc and driver agree that it should be *-mult
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-6-jic23@kernel.org
|
|
Straight forward format conversion. The example in here is fun in
that it has 2 separate provider / consumer pairs.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-5-jic23@kernel.org
|
|
We use this part in an example for the envelope detector. That showed
that we need to allow for the #io-channel-cells property which
trivial-devices.yaml does not.
It doesn't make sense to add that property to trivial-devices as
it only applies for those devices that can provide some sort of
DAC or ADC service to another device driver. Hence solution will
be to pull some IIO devices out to have their own file on a case
by case basis.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-4-jic23@kernel.org
|
|
Txt to yaml format conversion. I dropped the example section
describing the measurement ADC, as that isn't strictly part
of this binding.
Uses the new dt-schema/schema/iio/iio-consumer.yaml schema.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20201031181242.742301-3-jic23@kernel.org
|
|
File contained generic IIO wide bindings.
Now part of the external dt-schema repository.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031181242.742301-2-jic23@kernel.org
|
|
Also add additionalProperties: false for the child nodes.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20201031182423.742798-4-jic23@kernel.org
|
|
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: 5ada4ea9be16 ("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: af3008485ea03 ("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>
|
|
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/9579804f52ccab74a5ca5c7a55b5072b7304bea9.1606045688.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Like all other ST sensors, hts221 devices have VDD power line.
Introduce VDD voltage regulator to control it.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/6b3347e78f4f920c48eb6a66936d3b69cb9ff53a.1606045688.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201121185824.451477-1-vilhelm.gray@gmail.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>
|
|
Register 'RALINK_PCI_IMBASEBAR0_ADDR' contains internal memory
base address for BAR0. We don't really need to write anything
there at all since its initial value contains always a desired
valid value. Hence remove register definition and related code.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-8-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Instead of getting resources parsing from DT first and remaping
afterwards, this can be done in one step using the kernel function
'devm_platform_ioremap_resource'. Hence, update to use it.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-7-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
'mt7621_pci_parse_request_of_pci_ranges'
Remove 'mt7621_pcie_add_resources' where resources are added to the host
windows moving this code into the function where all the parsing and
preparing code is being done: 'mt7621_pci_parse_request_of_pci_ranges'.
The memory resource has been properly parsed for the PCI APIs so we
only need to retrieve it and use it in those places we need.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
PCI kernel apis now set some variables related with pci_host_bridge
by default and it is not necessary to setup them in driver code.
Host bridge parent device is set by default to the platform device
and 'swizzle_irq' is also set to its default function. These two
are not necessary to be set here. Hence remove them.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-5-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Because IO_SPACE_LIMIT for mips is 0xFFFF but this platform uses
PĈI IO resource at 0x001e160000. Hence instead of directly use
some more accurate functions from the PCI kernel for this driver
some things must be done in a different way to make things work.
Add this explanation as a comment where the IO resource is parsed
and virtually mapped into memory.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Offset contains resources size for both io and memory resources.
Those fields are directly initialized to zero and set up using
'pci_add_resource_offset' function. Instead of doing that remove
them and use directly function 'pci_add_resource' where zero is
passed directly to its internal call to 'pci_add_resource_offset'.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Bus ranges are now discovered by default. Hence remove
its related code from the driver.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-2-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/ae812b48528c48555a753c081acf1c9bb6376cc6.1605631305.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Like all other ST sensors, st_lsm6dsx devices have VDD and VDDIO power
lines. Introduce voltage regulators to control them.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/a0427a66360bdec73c3b1fb536a46240f96b2ae7.1605631305.git.lorenzo@kernel.org
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
|
