- 15 Dec, 2019 4 commits
-
-
Linus Walleij authored
The end-of-conversion (EOC) GPIO line is better to grab using a GPIO descriptor. We drop the pdata for this: clients using board files can use machine descriptor tables to pass this GPIO from static data. Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marco Felsch authored
The device is always in a low-power state due to the hardware design. It wakes up upon a conversion request and goes back into the low-power state. The pm ops are added to disable the device completely and to free the regulator. Disbaling the device completely should be not that notable but freeing the regulator is important. Because if it is a shared power-rail the regulator won't be disabled during suspend-to-ram/disk and so all devices connected to that rail keeps on. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Linus Walleij authored
commit f7072198 ("iio: imu: Fix inv_mpu6050 dependencies") undid the explicit selection of I2C_MUX previously done by the driver, because I2C_MUX implicitly depended on HAS_IOMEM. However commit 93d710a6 ("i2c: mux: fix up dependencies") cleared up the situation properly and drivers that need to select I2C_MUX can now do so again. It makes a lot of sense for a driver to select the driver infrastructure it needs so restore the natural order of things. Cc: Richard Weinberger <richard@nod.at> Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Beniamin Bia authored
The channels specification assignment in chip info was simplified. This patch makes supporting other devices by this driver easier. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 01 Dec, 2019 4 commits
-
-
Andreas Klinger authored
Add support for parallax ping and laser ping sensors with just one pin for trigger and echo signal. This driver is based on srf04. In contrast to it it's necessary to change direction of the pin and to request the irq just for the period when the echo is rising and falling. Because this adds a lot of cases there is this individual driver for handling this type of sensors. Add a new configuration variable CONFIG_PING to Kconfig and Makefile. Julia reported an issue with failing to unlock a mutex in some error paths. Signed-off-by: Andreas Klinger <ak@it-klinger.de> Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Fabrice Gasnier authored
There is no need to explicitly generate update event to update timer master mode. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Klinger authored
Add a maintainer for the new parallax PING))) and LaserPING IIO sensors Signed-off-by: Andreas Klinger <ak@it-klinger.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 23 Nov, 2019 23 commits
-
-
Andreas Klinger authored
Add dt-bindings for parallax PING))) and LaserPING iio sensors, which are used for measuring distances. Signed-off-by: Andreas Klinger <ak@it-klinger.de> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Klinger authored
Add new vendor prefix parallax for newly created ping iio sensors. Signed-off-by: Andreas Klinger <ak@it-klinger.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Tachici authored
Previously, the code was using the of_read_property_bool() to check if an external regulator was provided. However, this is redundant, as it's more simple/direct to just ask the regulator is provided, via a `devm_regulator_get_optional()` call. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
Now the maxim_thermocouple has new, more specific, 'compatible' strings for better distinguish the various supported chips. This patch updates the DT bindings documentation accordingly Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
We added a sysfs ABI for getting/setting the type of a thermocouple. This driver supports chips that support specific fixed thermocouple types; we cannot set it, but still we can add this sysfs attribute in RO mode to read-back the thermocouple type. This driver supports actually several chips: - max6675 - max31855[k/j/n/s/t/e/r]asa family Max6675 supports only K-type thermocouples, so we can just report that. Each chip in max31855 family supports just one specific thermocouple type (in the obvious way: i.e. max31855jasa supports J-type). This driver did accept a generic SPI ID and OF compatible "max31855" which does not give any clue about which chip is really involved (and unfortunately it seems we have no way to detect it). This patch introduces a new set of, more specific, SPI IDs and OF compatible strings to better match the chip type. The old, generic, "max31855" binding is kept for compatibility reasons, but this patch aims to deprecate it, so, should we hit it, a warning is spit. In such case the reported thermocouple type in sysfs is '?', because we have no way to know. Regarding the implementation: the thermocouple type information is stored in the driver private data and I've kept only two maxim_thermocouple_chip types in order to avoid a lot of duplications (seven chip types with just a different thermocouple type). RFT because I have no real HW to test this. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
The sensor support various thermocouple types (e.g. J, K, N, ...). The driver allows to configure this parameter using a DT property. This is useful when i.e. the thermocouple is physically tied to the sensor and it is usually not removed, or when it is at least known in advance which sensor will be connected to the circuit. However, if the user can randomly connect any kind of thermocouples (i.e. the device exposes a connector, and the user is free to connect its own sensors), it would be more appropriate to provide a mechanism to dynamically switch from one thermocouple type to another. This can be i.e. handled in userspace by a GUI, a configuration file or a program that detects the thermocouple type by reading a GPIO, or a eeprom on the probe, or whatever. This patch adds a IIO attribute that can be used to override, at run-time, the DT-provided setting (which serves as default). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
IIO core layer gained a new sysfs standard attribute "thermocouple_type". This patch adds it to the list of documented ABI for sysfs-bus-iio Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
We have a couple of thermocouple IIO drivers, supporting several chips. Some of them support only one specific thermocouple type (e.g. "K", "J"), one of them can be configured to work with several different thermocouple types. In certain applications thermocouples could be externally connected to the chip by the user. This patch introduces a new IIO standard attribute to report the supported thermocouple type and, where applicable, to allow it to be dynamically set using sysfs. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
This patch introduces IIO_VAL_CHAR type for standard IIO attributes to allow for attributes that needs to be represented by character rather than a number. This is preparatory for introducing a new attribute whose purpose is to describe thermocouple type, that can be i.e. "J", "K", etc.. The char-type value is stored in the first "value" integer that is passed to the .[read/write]_raw() callbacks. Note that in order to make it possible for the IIO core to correctly parse this type (actually, to avoid integer parsing), it became mandatory for any driver that wish to use IIO_VAL_CHAR on a writable attribute to implement .write_raw_get_fmt(). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
This sensor can perform samples averaging in hardware, but currently the driver leaves this setting alone (default is no averaging). This patch binds this HW setting to the "oversampling_ratio" IIO attribute and allows the user to set the averaging as desired (the HW supports averaging of 2, 5, 8 or 16 samples; in-between values are rounded up). Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
max31856 IIO driver introduced a new attribute "in_temp_filter_notch_center_frequency". This patch adds it to the list of documented ABI for sysfs-bus-iio Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andrea Merello authored
This sensor has an embedded notch filter for reducing interferences caused by the power mains. This filter can be tuned to reject either 50Hz or 60Hz (and harmonics). Currently the said setting is left alone (the sensor defaults to 60Hz). This patch introduces a IIO attribute that allows the user to set the said filter to the desired frequency. NOTE: this has been intentionally not tied to any DT property to allow the configuration of this setting from userspace, e.g. with a GUI or by reading a configuration file, or maybe reading a GPIO tied to a physical switch or accessing some device that can autodetect the line frequency. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Colin Ian King <colin.king@canonical.com> Cc: Patrick Havelange <patrick.havelange@essensium.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Chuhong Yuan <hslester96@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change uses the ADIS library's state_lock to protect the state of the `max_speed_hz` change that is done during the set of the sampling frequency. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
It's the only operation that does 2 operations (a read & a write), so the unlocked functions can be used under a single state lock. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This replaces indio_dev's mlock with the state lock/mutex from the ADIS library. The __adis16136_get_freq() function has been prefixed to mark it as unlocked. The adis16136_{set,get}_filter() functions now hold the state lock for all the ops that they do. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This change removes the use of indio_dev's mlock in favor using the state lock from the ADIS library. The set_freq() & get_freq() hooks are unlocked, so they require specific locking. That is because in some cases the get_freq() hook is used in combination with adis16400_set_filter(). In cases where only one read/write is done, the functions that hold the state lock are used. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The single conversion function does a series of reads + writes. This change extends the use of the state_lock for the entire set of operations. Previously, indio_dev's mlock was used. This change also removes the use of this lock. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The initial startup routine is called by some ADIS drivers during probe, and before registering with IIO. Normally, userspace should not be able to do any access to the device (as there shouldn't be any available). This change extends the state lock to the entire initial-startup routine. Behaviourally nothing should change, but this should make the library function a bit more robust. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The reset routine may also be important to be protected by the state-lock and grouped with other operations, so create an unlocked version, so that this can be done. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This one also gets re-used in certain operations, so it makes sense to have an unlocked version of this to group it with other reads/writes/operations to have a single lock for the whole state change. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The adis_enable_irq() does a read & a write. This change keeps a lock for the duration of both operations vs for each op. The change is also needed in adis16480, since that has it's own implementation for adis_enable_irq(). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
This will allow more flexible control to group reads & writes into a single lock (particularly the state_lock). The end-goal is to remove the indio_dev->mlock usage, and the simplest fix would have been to just add another lock, which would not be a good idea on the long-run. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alexandru Ardelean authored
The lock can be extended a bit to protect other elements that are not particular to just TX/RX. Another idea would have been to just add a new `state_lock`, but that would mean 2 locks which would be redundant, and probably cause more potential for dead-locks. What will be done in the next patches, will be to add some unlocked versions for read/write_reg functions. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 16 Nov, 2019 8 commits
-
-
Geert Uytterhoeven authored
The relations between enum values and array indices values are currently not enforced by the code, which makes them fragile w.r.t. future changes. Fix this by: 1. Using designated array initializers, to make sure array indices and enums values match, 2. Linking max9611_csa_gain enum values to the corresponding max9611_conf_ids enum values, as the latter is cast to the former in max9611_read_csa_voltage(). No change in generated code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jean-Baptiste Maneyrol authored
Add support for driving MPU9150 magnetometer (AK8975) from mpu. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jean-Baptiste Maneyrol authored
MPU9150 is i2c only. Update Kconfig to delete in description chips that are i2c or spi only. Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Beniamin Bia authored
Add Beniamin Bia as a maintainer for AD7091R5 ADC. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Beniamin Bia authored
Documentation for AD7091R5 ADC was added. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Paul Cercueil authored
The scale can now be obtained with the "in_voltage_scale" file. By default, the scale returned corresponds to the internal VREF of 2.5V. It is possible to use an external VREF (through the REFIN/REFOUT pin of the chip), by passing a regulator to the driver. The scale will then be calculated according to the voltage reported by the regulator. Signed-off-by: Paul Cercueil <paul.cercueil@analog.com> Co-developed-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Paul Cercueil authored
AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC. This driver will also support AD7091R2/4/8 in the future. Datasheet: Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdfSigned-off-by: Paul Cercueil <paul.cercueil@analog.com> Co-developed-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: dma_request_chan(dev, name) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 15 Nov, 2019 1 commit
-
-
Marcelo Diop-Gonzalez authored
Reducing the indentation level helps a bit with the readability of this function. There's also a checkpatch fix here, moving the first argument to kthread_create() onto the same line, as well as a relocation of the statement "char threadname[16];" to the top of the function to avoid a declaration in the middle of code. Signed-off-by: Marcelo Diop-Gonzalez <marcgonzalez@google.com> Link: https://lore.kernel.org/r/20191114232801.71458-1-marcgonzalez@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-