- 21 12月, 2021 10 次提交
-
-
由 Jonathan Cameron 提交于
If CONFIG_PM not set then clang warns this structure is unused. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-12-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Not sure what the thinking was here, as lost to history, but the variable is clearly not used so get rid of it. Warning seen with clang W=1 tests (may be present with other compilers and build options). Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-11-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-10-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Baptiste Mansuy <bmansuy@invensense.com> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-9-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-8-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-7-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-6-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-5-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-4-jic23@kernel.org
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-3-jic23@kernel.org
-
- 17 12月, 2021 10 次提交
-
-
由 Jonathan Cameron 提交于
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-2-jic23@kernel.org
-
由 Mihail Chindris 提交于
The AD3552R-16 is a low drift ultrafast, 16-bit accuracy, current output digital-to-analog converter (DAC) designed to generate multiple output voltage span ranges. The AD3552R-16 operates with a fixed 2.5V reference. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdfSigned-off-by: NMihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211213110825.244347-3-mihail.chindris@analog.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Mihail Chindris 提交于
Add documentation for ad3552r and ad3542r Signed-off-by: NMihail Chindris <mihail.chindris@analog.com> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Antoniu Miclaus 提交于
Add initial ABI documentation for admv8818 filter sysfs interfaces. Signed-off-by: NAntoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Antoniu Miclaus 提交于
Add device tree bindings for the ADMV8818 Filter. Signed-off-by: NAntoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Antoniu Miclaus 提交于
The ADMV8818-EP is a fully monolithic microwave integrated circuit (MMIC) that features a digitally selectable frequency of operation. The device features four independently controlled high- pass filters (HPFs) and four independently controlled low-pass filters (LPFs) that span the 2 GHz to 18 GHz frequency range. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/admv8818-ep.pdfSigned-off-by: NAntoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Antoniu Miclaus 提交于
Add filter subfolder for IIO devices that handle filter functionality. Signed-off-by: NAntoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lars-Peter Clausen 提交于
The case to u8 * is unnecessary here since the expression is already of type u8 *. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lars-Peter Clausen 提交于
`buf` is cast to a const char *, but `buf` is already a const char *, so the case is unnecessary. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lars-Peter Clausen 提交于
`buf` is cast to a const char *, but `buf` is already a const char *, so the case is unnecessary. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 16 12月, 2021 6 次提交
-
-
由 Kees Cook 提交于
The find.h APIs are designed to be used only on unsigned long arguments. This can technically result in a over-read, but it is harmless in this case. Regardless, fix it to avoid the warning seen under -Warray-bounds, which we'd like to enable globally: In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:22, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:60, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:55, from ./include/linux/swait.h:7, from ./include/linux/completion.h:12, from drivers/iio/adc/stmpe-adc.c:10: drivers/iio/adc/stmpe-adc.c: In function 'stmpe_adc_probe': ./include/linux/find.h:98:23: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Warray-bounds] 98 | val = *addr | ~GENMASK(size - 1, offset); | ^~~~~ drivers/iio/adc/stmpe-adc.c:258:13: note: while referencing 'norequest_mask' 258 | u32 norequest_mask = 0; | ^~~~~~~~~~~~~~ Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Minghao Chi 提交于
Return value from ads8688_prog_write() directly instead of taking this in another redundant variable. Reported-by: NZeal Robot <zealci@zte.com.cn> Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Dan Carpenter 提交于
The > needs to be >= to prevent accessing one element beyond the end of the st->channel_configs[] array. Fixes: fea251b6 ("iio: addac: add AD74413R driver") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NCosmin Tanislav <cosmin.tanislav@analog.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Xiang wangx 提交于
Delete the redundant word 'the'. Signed-off-by: NXiang wangx <wangxiang@cdjrlc.com> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Zach DeCook 提交于
By flushing the output, iio_event_monitor can be more useful to programs chained along with it. iio_event_monitor stk3310 | awk '/rising/{system("my_unlockscreen.sh")} /falling/{system("my_lockscreen.sh")}' Without this flush, the above example would buffer a number of events, then after a while run the lock/unlock scripts several times. Signed-off-by: NZach DeCook <zachdecook@librem.one> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
由 Lars-Peter Clausen 提交于
Drvdata is typically used by drivers to attach driver specific data to a device. It is used to retrieve driver specific information when only the device to which the data is attached is available. In the IIO core in the `iio_device_alloc()` function we call `iio_device_set_drvdata(indio_dev, indio_dev)`. This sets the drvdata of the IIO device to itself. This is rather unnecessary since if we have a pointer to the IIO device to call `iio_device_get_drvdata()` on it we don't need to call the function since we already have the pointer. If we only have a pointer to the `struct device` we can use `dev_to_iio_dev()` to get the IIO device from it. Furthermore the drvdata is supposed to be reserved for drivers, so it should not be used by the IIO core in the first place. The `set_drvdata()` has been around from the very beginning of the IIO framework and back then it was used in the IIO device sysfs attribute handling code. But that was subsequently replaced with a `dev_to_iio_dev()` in commit e53f5ac5 ("iio: Use dev_to_iio_dev()") and other cleanups. The self `set_drvdata()` is now no longer needed and can be removed. Verified that there no longer any users by checking for potential users using the following two coccinelle scripts and reviewing that none of the matches are problematic code. <smpl> @@ struct iio_dev *iio_dev; expression dev; identifier fn !~ "(remove|resume|suspend)"; @@ fn(...) { ... *iio_dev = dev_get_drvdata(dev) ... } </smpl> <smpl> @r1@ position p; struct iio_dev *indio_dev; identifier dev_fn =~ "^dev_"; identifier devm_fn =~ "^devm_"; @@ ( dev_fn | devm_fn ) (&indio_dev@p->dev, ...) @@ struct iio_dev *indio_dev; position p != r1.p; @@ *&indio_dev@p->dev</smpl> Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 13 12月, 2021 14 次提交
-
-
由 Jonathan Cameron 提交于
Probably a cut and paste error, but the binding header used in the example is for the wrong device and nothing from it is used. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Jonathan Cameron 提交于
We could probably drop a lot more of these, but for now this removes unnecessary restrictions on stand alone ADC devices. For these 3 drivers the false dependency seems to date all the way back to their initial introduction. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
Nothing in this driver depends on OF firmware so drop the dependency and update the headers to remove the false impression such a dependency exists. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
There is nothing directly using of specific interfaces in this driver, so lets not include the headers. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: NPeter Rosin <peda@axentia.se> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
This enables using the driver with other firmware types such as ACPI via PRP0001. Also part of a general attempt to move IIO drivers over to generic properties to avoid opportunities for cut and paste. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
This allows use of the driver with other types of firmware such as ACPI PRP0001 based probing. Also part of a general attempt to remove direct use of of_ specific accessors from IIO. Added an include for mod_devicetable.h whilst here to cover the struct of_device_id definition. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Cc: Kent Gustavsson <kent@minoris.se> Reviewed-by: NMarcus Folkesson <marcus.folkesson@gmail.com>
-
由 Jonathan Cameron 提交于
Note the handling of the device tree node in this driver was somewhat unusual. I have cleaned that up whilst also moving over to generic properties. Part of a general attempt to move all IIO drivers over to generic firmware properties both as a general improvement and to avoid sources of cut and paste into future drivers. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
This enables use of other firmware types with minimal driver changes. Part of an ongoing effort to move all IIO drivers over to generic accessors in order to reduce the chance of of_* versions being copied into new drivers. Also updated the headers to reflect this change including using mod_devicetable.h for struct of_device_id definition rather than going via of.h Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
In this case it was only of_device_get_match_data() + header update. This enables use of other firmware types with no other changes, such as ACPI via the PRP0001 route. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Cc: Chris Coffey <cmc@babblebit.net>
-
由 Jonathan Cameron 提交于
This driver never used anything from the of specific headers. mod_devicetable.h provides the struct of_device_id definition. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
This driver never used anything in the of specific header. It just wants the struct of_device_id from mod_devicetable.h. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Acked-by: NPeter Rosin <peda@axentia.se>
-
由 Jonathan Cameron 提交于
These have never been used in this driver. What is used is in mod_devicetable.h so add that include (struct of_device_id) Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Cc: Daniel Gomez <dagmcr@gmail.com>
-
由 Jonathan Cameron 提交于
Lars pointed out that platform data can also be supported via the generic properties interface, so there is no point in continuing to support it separately. Hence squish the linux/platform_data/ad5755.h header into the c file and drop accessing the platform data directly. Done by inspection only. Mostly completely mechanical with the exception of a few places where default value handling is cleaner done by first setting the value, then calling the firmware reading function but and not checking the return value, as opposed to reading firmware then setting the default if an error occurs. Part of general attempt to move all of IIO over to generic device properties, both to enable other firmware types and to remove drivers that can be the source of of_ specific behaviour in new drivers. Suggested-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Jonathan Cameron 提交于
IIO triggers are software IRQ chips that split an incoming IRQ into separate IRQs routed to all devices using the trigger. When all consumers are done then a trigger callback reenable() is called. There are a few circumstances under which this can happen in atomic context. 1) A single user of the trigger that calls the iio_trigger_done() function from interrupt context. 2) A race between disconnecting the last device from a trigger and the trigger itself sucessfully being disabled. To avoid a resulting scheduling whilst atomic, close this second corner by using schedule_work() to ensure the reenable is not done in atomic context. Note that drivers must be careful to manage the interaction of set_state() and reenable() callbacks to ensure appropriate reference counting if they are relying on the same hardware controls. Deliberately taking this the slow path rather than via a fixes tree because the error has hard to hit and I would like it to soak for a while before hitting a release kernel. Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: NOleksij Rempel <o.rempel@pengutronix.de> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org
-