| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove iio_claim/release and change it on mutex accordingly in
vcnl3020_write_proxy_samp_freq.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-4-i.mikhaylov@yadro.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add the possibility to run proximity sensor in periodic measurement
mode with thresholds.
Reported-by: kernel test robot <lkp@intel.com> #repeated include
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-3-i.mikhaylov@yadro.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add DMA safe buffer for bulk transfers.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-2-i.mikhaylov@yadro.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The st-sensors drivers have changed in structure over time, and includes
have not always kept up with this. Let's bring them back to nearer
the ideal.
Identified with the include-what-you-use tool and careful checking of
its suggestions.
Note I haven't been particularly aggressive here, so this is just the
cases where the include obviously isn't needed rather than the more
subtle corners.
Note I took the opportunity to add mod_devicetable.h as I generally
prefer to see that when acpi or of match tables are present.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210608175149.4019289-1-jic23@kernel.org
|
|
In Linux the bma180 and bmc150-accel driver cover fairly similar chips
from Bosch (just with minor register differences). For the DT schema,
this does not make any difference: They both represent I2C/SPI devices,
have one or two interrupts plus a vdd/vddio-supply.
This means there is no need to duplicate the schema, we can just
document the compatibles for both drivers in a single DT schema.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-4-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Similar to recent rework in the bmc150-accel driver, sort the compatible
list in the DT schema so there is a consistent order.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-3-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Bosch accelerometers similar to BMA255 are initially configured to
emit an active-high interrupt signal. This is currently not re-configured
in the bmc150-accel driver so the interrupt should most certainly be
IRQ_TYPE_EDGE_RISING (or potentially IRQ_TYPE_LEVEL_HIGH).
(Unless there is some kind of inverter installed on the board...)
At the moment the bmc150-accel driver forcefully requests the IRQ
using IRQF_TRIGGER_RISING, which means that the IRQ type is currently
ignored in all existing device trees.
Fixes: 6259551cf19b ("iio: accel: bmc150-accel: Add DT bindings")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-2-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The continue statement at the end of a for-loop has no effect,
remove it.
Addresses-Coverity: ("Continue has no effect")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210617081312.151746-1-colin.king@canonical.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The point of this new change is to make the IIO tree actually parsable.
Before, given this attribute as a filename:
in_voltage0_aux_sample_rate
Userspace had no way to know if the attribute name was
"aux_sample_rate" with no extended name, or "sample_rate" with "aux" as
the extended name, or just "rate" with "aux_sample" as the extended
name.
This was somewhat possible to deduce when there was more than one
attribute present for a given channel, e.g:
in_voltage0_aux_sample_rate
in_voltage0_aux_frequency
There, it was possible to deduce that "aux" was the extended name. But
even with more than one attribute, this wasn't very robust, as two
attributes starting with the same prefix (e.g. "sample_rate" and
"sample_size") would result in the first part of the prefix being
interpreted as being part of the extended name.
To address the issue, knowing that channels will never have both a label
and an extended name, set the channel's label to the extended name.
In this case, the label's attribute will also have the extended name in
its filename, but we can live with that - userspace can open
in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain
the extended name.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Extended names are a problem for user-space as they make the filenames
in sysfs sometimes not parsable. They are now deprecated in favor of
labels.
This change makes sure that a device driver won't provide both labels
and extended names for its channels. It has never been the case and we
don't want it to happen.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add startup time for each chip familly. This allows a better behaviour of
the gyro and the accel. The gyro has now the time to stabilise itself
thus making initial data discarding for gyro irrelevant.
Signed-off-by: Baptiste Mansuy <bmansuy@invensense.com>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210621085731.9212-1-bmansuy@invensense.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This driver has two parts, one for i2c and one for spi, since the chip can
operate with both wire protocols.
The core file has a common adxl345_core_remove() function which puts the
chip into a powerdown state. This can be implemented with a
devm_add_action_or_reset() hook.
Doing that means we can register the IIO device with
devm_iio_device_register() and get rid of the adxl345_core_remove()
function.
The dev_set_drvdata() call can be removed as there is no other user of this
private data anymore.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This change converts the driver to use only device-managed init routines in
the probe function of the driver.
This way, we no longer need the tcs3414_remove() hook.
We still need to keep the i2c_set_clientdata() call, as that's being used
for the PM routines.
And lastly, a devm_add_action_or_reset() hook is added to call the
powerdown handler when the chip is uninitialized or the probe fails.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080534.9209-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The change converts the probe function to use the
devm_iio_device_register() function.
Before calling that, we need to register an action to store the wiper back
to non-volatile memory when the device is de-registered.
We don't need to do this if the probe fails, because the only place where
the probe can fail now is devm_iio_device_register() and that shouldn't
create an IIO device (for userspace to poke at) if it fails.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080641.9953-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
When the device is probed, there's no guarantee that the device is not in
power-down mode. This can happen if the driver is unregistered and
re-probed.
To make sure this doesn't happen, the value of the TMP006_CONFIG register
(which is read in the probe function and stored in the device's private
data) is being checked to see if the MOD bits have the correct value.
This is a fix for a somewhat-rare corner case. As it stands, this doesn't
look like a high priority to go into the Fixes route.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624081924.15897-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625140137.362282-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625140137.362282-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Simple binding for this family of microchip DACs.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael Welling <mwelling@ieee.org>
Reviewed-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
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-15-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-14-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-13-jic23@kernel.org
|
|
Straight forward binding with vref optional for those part with internal
regulators, but required for those without.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Ricardo Ribalda <ribalda@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-12-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-11-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-10-jic23@kernel.org
|
|
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org
|
|
Binding for this high voltage DAC with temperature event signal.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-8-jic23@kernel.org
|
|
Documenting existing binding, so little flexibility available.
2 channel devices that require separate reference voltages.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-7-jic23@kernel.org
|
|
A simple binding for this particular DAC familly.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-5-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-4-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-3-jic23@kernel.org
|
|
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-2-jic23@kernel.org
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210628141709.80534-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210630120338.482426-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210630121509.653717-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210630131636.1563148-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210630131636.1563148-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210705071456.649659-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210705071456.649659-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add description for rk3568 saradc.
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210712014437.97427-1-xxm@rock-chips.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/89d8a766eb971eda1ee362444a8711037bdb208c.1626261211.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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: kernel test robot <lkp@intel.com>
Signed-off-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.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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: Alexandru Ardelean <aardelean@deviqon.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210630123029.759609-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
|
|
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>
|
|
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: cd62734ca60d ("mm/rmap: split try_to_munlock from try_to_unmap")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reported-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: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Acked-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: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: 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/563ce5b2-7a44-5b4d-1dfd-59a0e65932a9@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>
|
