When building with C=1, sparse reports some issues regarding endianness
annotations:
arm-smmu-v3.c:221:26: warning: cast to restricted __le64
arm-smmu-v3.c:221:24: warning: incorrect type in assignment (different base types)
arm-smmu-v3.c:221:24: expected restricted __le64 [usertype]
arm-smmu-v3.c:221:24: got unsigned long long [usertype]
arm-smmu-v3.c:229:20: warning: incorrect type in argument 1 (different base types)
arm-smmu-v3.c:229:20: expected restricted __le64 [usertype] *[assigned] dst
arm-smmu-v3.c:229:20: got unsigned long long [usertype] *ent
arm-smmu-v3.c:229:25: warning: incorrect type in argument 2 (different base types)
arm-smmu-v3.c:229:25: expected unsigned long long [usertype] *[assigned] src
arm-smmu-v3.c:229:25: got restricted __le64 [usertype] *
arm-smmu-v3.c:396:20: warning: incorrect type in argument 1 (different base types)
arm-smmu-v3.c:396:20: expected restricted __le64 [usertype] *[assigned] dst
arm-smmu-v3.c:396:20: got unsigned long long *
arm-smmu-v3.c:396:25: warning: incorrect type in argument 2 (different base types)
arm-smmu-v3.c:396:25: expected unsigned long long [usertype] *[assigned] src
arm-smmu-v3.c:396:25: got restricted __le64 [usertype] *
arm-smmu-v3.c:1349:32: warning: invalid assignment: |=
arm-smmu-v3.c:1349:32: left side has type restricted __le64
arm-smmu-v3.c:1349:32: right side has type unsigned long
arm-smmu-v3.c:1396:53: warning: incorrect type in argument 3 (different base types)
arm-smmu-v3.c:1396:53: expected restricted __le64 [usertype] *dst
arm-smmu-v3.c:1396:53: got unsigned long long [usertype] *strtab
arm-smmu-v3.c:1424:39: warning: incorrect type in argument 1 (different base types)
arm-smmu-v3.c:1424:39: expected unsigned long long [usertype] *[assigned] strtab
arm-smmu-v3.c:1424:39: got restricted __le64 [usertype] *l2ptr
While harmless, they are incorrect and could hide actual errors during
development. Fix them.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20200918141856.629722-1-jean-philippe@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
Check for !A || A && B condition. It's equivalent to !A || B.
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Fixes the following W=1 kernel build warning(s):
drivers/iio/chemical/sgp30.c:236: warning: Function parameter or member 'duration_us' not described in 'sgp_read_cmd'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Andreas Brauchli <a.brauchli@elementarea.net>
Cc: Pascal Sachs <pascal.sachs@sensirion.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-6-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/gyro/adis16080.c:49: warning: Function parameter or member 'lock' not described in 'adis16080_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Barry Song <21cnbao@gmail.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-13-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
File headers are not good candidates for kerneldoc.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dummy/iio_dummy_evgen.c:30: warning: Cannot understand * @regs: irq regs we are faking
on line 30 - I thought it was a doc line
drivers/iio/dummy/iio_dummy_evgen.c:42: warning: Function parameter or member 'irq_sim_domain' not described in 'iio_dummy_eventgen'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-16-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/ad7949.c:58: warning: Function parameter or member 'indio_dev' not described in 'ad7949_adc_chip'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Link: https://lore.kernel.org/r/20200716135928.1456727-18-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Misspelling, missing description.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad5064.c:71: warning: bad line: internal vref.
drivers/iio/dac/ad5064.c:83: warning: Function parameter or member 'channels' not described in 'ad5064_chip_info'
drivers/iio/dac/ad5064.c:125: warning: Function parameter or member 'lock' not described in 'ad5064_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-20-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vdd_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vref_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'lock' not described in 'ad7303_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200716135928.1456727-31-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect against any other accesses during the
reading of sample. Reading a sample requires multiple consecutive regmap
operations and a completion callback, so this requires that no other
read occurs until it completes.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200916092928.78026-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
VL53L0X can be configured to use interrupt pin (GPIO1)
to notify host about readiness of new measurement.
If interrupt pin is not specified, driver still uses polling.
Signed-off-by: Ivan Drobyshevskyi <drobyshevskyi@gmail.com>
Link: https://lore.kernel.org/r/20200916074458.873359-2-drobyshevskyi@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This enables use of the driver with ACPI PRP0001 and also removes
an antipattern that I am trying to clear out of IIO to avoid
it being copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-39-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: David Barksdale <dbarksdale@uplogix.com>
Link: https://lore.kernel.org/r/20200910173242.621168-38-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-37-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200910173242.621168-36-jic23@kernel.org
Both would result in only a small size saving. For simplicity it
is best to remove them. I also wish to remove both these antipatterns
from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-35-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-34-jic23@kernel.org
This change allows the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-33-jic23@kernel.org
This makes the existing code easier to read and will make the following
patch a little simpler.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-32-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-31-jic23@kernel.org
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data() doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-30-jic23@kernel.org
Avoids lots of repetition of &client->dev and will make the next
patch tidier.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-29-jic23@kernel.org
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-28-jic23@kernel.org
This cleans up the code at bit, but is primarily here as a precusor
to the next patch. I've only done this for the two functions
which use the dev pointer repeatedly.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com>
Link: https://lore.kernel.org/r/20200910173242.621168-27-jic23@kernel.org
of_match_ptr() prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver and use generic fw accessors to check
if there is a fw_node and get the id.
It might be neater to use pointers rather than indexes for
the device_data but that is another issue and should be handled
separately.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-26-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-25-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-24-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Manivannan Sadhasivam <manivannanece23@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-23-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-22-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Link: https://lore.kernel.org/r/20200910173242.621168-21-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Link: https://lore.kernel.org/r/20200910173242.621168-20-jic23@kernel.org
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Tomasz Duszynski <tduszyns@gmail.com>
Link: https://lore.kernel.org/r/20200910173242.621168-19-jic23@kernel.org
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20200910173242.621168-18-jic23@kernel.org
This change allows use of this driver with ACPI via PRP0001 and removes
an example of an anti pattern I'm trying to remove from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20200910173242.621168-17-jic23@kernel.org
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Link: https://lore.kernel.org/r/20200910173242.621168-16-jic23@kernel.org
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20200910173242.621168-15-jic23@kernel.org
This enables use of ACPI PRP0001 and removes an antipattern I am
trying to stop people copying in IIO.
This particular case is more complex than most because it allowed
probing via sysfs with out a fwnode but would presumably always
have then failed. Now the code will assume that properties are
the defaults if not specified or the firmware node is not present.
This relaxation of the constraints should not break any existing
cases and may enable some new ones.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Link: https://lore.kernel.org/r/20200910173242.621168-14-jic23@kernel.org
This prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also add mod_devicetable.h include given struct of_device_id is
declared there.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-13-jic23@kernel.org
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-12-jic23@kernel.org
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20200910173242.621168-11-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Link: https://lore.kernel.org/r/20200910173242.621168-10-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Also switch to device_get_match_data() from of_ variant and adjust
headers to reflect the change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-9-jic23@kernel.org
This change allows the use of the driver with ACPI via PRP0001
and remove an example of an anti pattern I'm trying to remove from IIO.
Also adjust includes to reflect this change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-8-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also use device_get_match_data() rather than devicetree only version.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/20200910173242.621168-7-jic23@kernel.org
Given that an ACPI binding must start with 3 or 4 capitals,
this cannot represent a valid binding.
It seems unlikely anything out there is using it.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Maury Anderson <maury.anderson@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-6-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Whilst this driver has an ACPI binding, it is not of a form
that is valid under ACPI so will be dropped shortly.
Also switch to device_get_match_data() and switch headers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Maury Anderson <maury.anderson@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20200910173242.621168-5-jic23@kernel.org
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also switch headers to reflect this change.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20200910173242.621168-4-jic23@kernel.org
Commit 73f3816609 ("arm64: Advertise mitigation of Spectre-v2, or lack
thereof") changed the way we deal with ARCH_WORKAROUND_1, by moving most
of the enabling code to the .matches() callback.
This has the unfortunate effect that the workaround gets only enabled on
the first affected CPU, and no other.
In order to address this, forcefully call the .matches() callback from a
.cpu_enable() callback, which brings us back to the original behaviour.
Fixes: 73f3816609 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
Cc: <stable@vger.kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
We seem to be pretending that we don't have any firmware mitigation
when KVM is not compiled in, which is not quite expected.
Bring back the mitigation in this case.
Fixes: 4db61fef16 ("arm64: kvm: Modernize __smccc_workaround_1_smc_start annotations")
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
In a follow-up patch, we may save the FPSIMD rather than the full SVE
state when the state has to be zeroed on return to userspace (e.g
during a syscall).
Introduce an helper to load SVE vectors from FPSIMD state and zero the rest
of SVE registers.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Link: https://lore.kernel.org/r/20200828181155.17745-7-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
