There's a rule to ignore all the dot-files (.*) but we want to exclude the
config files used by KUnit (.kunitconfig) since those are usually added to
allow executing test suites without having to enable custom config symbols.
Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com>
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 70ec6037fa7a..7f86e0837909 100644
--- a/.gitignore
+++ b/.gitignore
@@ -103,6 +103,7 @@ modules.order
!.get_maintainer.ignore
!.gitattributes
!.gitignore
+!.kunitconfig
!.mailmap
!.rustfmt.toml
base-commit: ffe78bbd512166e0ef1cc4858010b128c510ed7d
--
2.40.0
Support ROHM BU27034 ALS sensor
This series adds support for ROHM BU27034 Ambient Light Sensor.
The BU27034 has configurable gain and measurement (integration) time
settings. Both of these have inversely proportional relation to the
sensor's intensity channel scale.
Many users only set the scale, which means that many drivers attempt to
'guess' the best gain+time combination to meet the scale. Usually this
is the biggest integration time which allows setting the requested
scale. Typically, increasing the integration time has better accuracy
than increasing the gain, which often amplifies the noise as well as the
real signal.
However, there may be cases where more responsive sensors are needed.
So, in some cases the longest integration times may not be what the user
prefers. The driver has no way of knowing this.
Hence, the approach taken by this series is to allow user to set both
the scale and the integration time with following logic:
1. When scale is set, the existing integration time is tried to be
maintained as a first priority.
1a) If the requested scale can't be met by current time, then also
other time + gain combinations are searched. If scale can be met
by some other integration time, then the new time may be applied.
If the time setting is common for all channels, then also other
channels must be able to maintain their scale with this new time
(by changing their gain). The new times are scanned in the order
of preference (typically the longest times first).
1b) If the requested scale can be met using current time, then only
the gain for the channel is changed.
2. When the integration time change - scale is tried to be maintained.
When integration time change is requested also gain for all impacted
channels is adjusted so that the scale is not changed, or is chaned
as little as possible. This is different from the RFCv1 where the
request was rejected if suitable gain couldn't be found for some
channel(s).
This logic is simple. When total gain (either caused by time or hw-gain)
is doubled, the scale gets halved. Also, the supported times are given a
'multiplier' value which tells how much they increase the total gain.
However, when I wrote this logic in bu27034 driver, I made quite a few
errors on the way - and driver got pretty big. As I am writing drivers
for two other sensors (RGB C/IR + flicker BU27010 and RGB C/IR BU27008)
with similar gain-time-scale logic I thought that adding common helpers
for these computations might be wise. I hope this way all the bugs will
be concentrated in one place and not in every individual driver ;)
Hence, this series also intriduces IIO gain-time-scale helpers
(abbreviated as gts-helpers) + a couple of KUnit tests for the most
hairy parts.
Speaking of which - testing the devm interfaces requires a 'dummy
device'. I've learned that there has been at least two ways of handling
this kind of a dependecy.
1) Using a root_device_[un]register() functions (with or without a
wrapper)
2) Using dummy platform_device.
Way 2) is seen as abusing platform_devices to something they should not
be used.
Way 1) is also seen sub-optimal - and after a discussion a 'kunit dummy
device' is being worked on by David Gow:
https://lore.kernel.org/linux-kselftest/20230325043104.3761770-1-davidgow@g…
David's work relies on not yet in-tree kunit deferring API. Schedule for
this work is - as always in case of upstream development - unkonwn. In
order to be self-contained while still easily 'fixable when David's work
is completed' this series introduces warappers named similar to what was
suggested by david - and which are intended to have similar behaviour
(automatic clean-up upon test completion). These wrappers do still use
root-device APIs underneath but this should be fixed by David's work.
Finally, these added helpers do provide some value also for drivers
which only:
a) allow gain change
or
b) allow changing both the time and gain while trying to maintain the
scale.
For a) we provide the gain - selector (register value) table format +
selector to gain look-ups, gain <-> scale conversions and the available
scales helpers.
For latter case we also provide the time-tables, and actually all the
APIs should be usable by setting the time multiplier to 1. (not testeted
thoroughly though).
The patch 1/7 introduces the helpers for creating/dropping a test device
for devm-tests. It can be applied alone.
The patch 4/7 (IIO GTS tests) also depends on the patch 1/7 (and also
other patches in the series).
Rest of the series should be Ok to be applied with/without the patches
1/7 and 4/7 - although the 4/7 (which depends on 1/7) would be "nice to
have" together with the rest of the series for the testability reasons.
Revision history:
v5 => v6:
- Just a minor fixes in iio-gts-helpers and bu27034 driver.
- Kunit device helper for a test device creation.
- IIO GTS tests use kunit device helper.
v4 => v5: Mostly fixes to review comments from Andy and Jonathan.
- more accurate change-log in individual patches
- copy code from DRM test helper instead of moving it to simplify
merging
- document all exported GTS helpers.
- inline a few GTS helpers
- use again Milli lux for the bu27034 with RAW IIO_LIGHT channel and scale
- Fix bug from added in v4 bu27034 time setting.
v3 => v4: (Still mostly fixes to review comments from Andy and Jonathan)
- more accurate change-log in individual patches
- dt-binding and maintainer patches unchanged.
- dropped unused helpers and converted ones currently used only internally
to static.
- extracted "dummy device" creation helpers from DRM tests.
- added tests for devm APIs
- dropped scale for PROCESSED channel in BU27034 and converted mLux
values to luxes
- dropped channel 2 GAIN setting which can't be done due to HW
limitations.
v2 => v3: (Mostly fixes to review comments from Andy and Jonathan)
- dt-binding and maintainer patches unchanged.
- iio-gts-helper tests: Use namespaces
- iio-gts-helpers + bu27034 plenty of changes. See more comprehensive
changelog in individual patches.
RFCv1 => v2:
dt-bindings:
- Fix binding file name and id by using comma instead of a hyphen to
separate the vendor and part names.
gts-helpers:
- fix include guardian
- Improve kernel doc for iio_init_iio_gts.
- Add iio_gts_scale_to_total_gain
- Add iio_gts_total_gain_to_scale
- Fix review comments from Jonathan
- add documentation to few functions
- replace 0xffffffffffffffffLLU by U64_MAX
- some styling fixes
- drop unnecessary NULL checks
- order function arguments by in / out purpose
- drop GAIN_SCALE_ITIME_MS()
- Add helpers for available scales and times
- Rename to iio-gts-helpers
gts-tests:
- add tests for available scales/times helpers
- adapt to renamed iio-gts-helpers.h header
bu27034-driver:
- (really) protect read-only registers
- fix get and set gain
- buffered mode
- Protect the whole sequences including meas_en/meas_dis to avoid messing
up the enable / disable order
- typofixes / doc improvements
- change dropped GAIN_SCALE_ITIME_MS() to GAIN_SCALE_ITIME_US()
- use more accurate scale for lux channel (milli lux)
- provide available scales / integration times (using helpers).
- adapt to renamed iio-gts-helpers.h file
- bu27034 - longer lines in Kconfig
- Drop bu27034_meas_en and bu27034_meas_dis wrappers.
- Change device-name from bu27034-als to bu27034
MAINTAINERS:
- Add iio-list
---
Matti Vaittinen (7):
dt-bindings: iio: light: Support ROHM BU27034
iio: light: Add gain-time-scale helpers
kunit: Add kunit wrappers for (root) device creation
iio: test: test gain-time-scale helpers
MAINTAINERS: Add IIO gain-time-scale helpers
iio: light: ROHM BU27034 Ambient Light Sensor
MAINTAINERS: Add ROHM BU27034
.../bindings/iio/light/rohm,bu27034.yaml | 46 +
MAINTAINERS | 14 +
drivers/iio/Kconfig | 3 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-gts-helper.c | 1057 ++++++++++++
drivers/iio/light/Kconfig | 14 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/rohm-bu27034.c | 1496 +++++++++++++++++
drivers/iio/test/Kconfig | 14 +
drivers/iio/test/Makefile | 1 +
drivers/iio/test/iio-test-gts.c | 517 ++++++
include/kunit/device.h | 18 +
include/linux/iio/iio-gts-helper.h | 206 +++
lib/kunit/Makefile | 3 +-
lib/kunit/device.c | 36 +
15 files changed, 3426 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml
create mode 100644 drivers/iio/industrialio-gts-helper.c
create mode 100644 drivers/iio/light/rohm-bu27034.c
create mode 100644 drivers/iio/test/iio-test-gts.c
create mode 100644 include/kunit/device.h
create mode 100644 include/linux/iio/iio-gts-helper.h
create mode 100644 lib/kunit/device.c
base-commit: eeac8ede17557680855031c6f305ece2378af326
--
2.39.2
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
This series provides some initial KUnit coverage for regmap,
covering most of the interfaces that operate at the register
level using an instrumented RAM backed bus type.
Without the current regmap tree the paging tests will fail as the
RAM backed regmap doesn't support the required operations.
Changes in v2:
- Add a test for regcache_drop_region().
- Add a stress test for inserting registers into a sparse cache.
- Link to v1: https://lore.kernel.org/r/20230324-regmap-kunit-v1-0-62ef9cfa9b89@kernel.org
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
Mark Brown (2):
regmap: Add RAM backed register map
regmap: Add some basic kunit tests
drivers/base/regmap/Kconfig | 10 +
drivers/base/regmap/Makefile | 2 +
drivers/base/regmap/internal.h | 19 +
drivers/base/regmap/regmap-kunit.c | 736 +++++++++++++++++++++++++++++++++++++
drivers/base/regmap/regmap-ram.c | 85 +++++
5 files changed, 852 insertions(+)
---
base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65
change-id: 20230324-regmap-kunit-bb3c3e81e35c
Best regards,
--
Mark Brown <broonie(a)kernel.org>
This series provides some initial KUnit coverage for regmap,
covering most of the interfaces that operate at the register
level using an instrumented RAM backed bus type.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
Mark Brown (2):
regmap: Add RAM backed register map
regmap: Add some basic kunit tests
drivers/base/regmap/Kconfig | 10 +
drivers/base/regmap/Makefile | 2 +
drivers/base/regmap/internal.h | 19 ++
drivers/base/regmap/regmap-kunit.c | 631 +++++++++++++++++++++++++++++++++++++
drivers/base/regmap/regmap-ram.c | 85 +++++
5 files changed, 747 insertions(+)
---
base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65
change-id: 20230324-regmap-kunit-bb3c3e81e35c
Best regards,
--
Mark Brown <broonie(a)kernel.org>
I noticed that l2tp.sh net selftest is failing in recent kernels with
the following error:
RTNETLINK answers: Protocol not supported
See also: https://bugs.launchpad.net/bugs/2013014
Apprently the module lt2p_ipv6 is not automatically loaded when the test
is trying to create an l2tp ipv6 tunnel.
I did a bisect and found that the offending commit is this one:
65b32f801bfb ("uapi: move IPPROTO_L2TP to in.h")
I've temporarily reverted this commit for now, any suggestion on how to
fix this properly?
Thanks,
-Andrea
Hi all,
This is a follow-up to the conversation[1] about adding helpers to create a
struct device for use in KUnit tests. At the moment, most tests are
using root_device_register(), which doesn't quite fit, and a few are
using platform_devices instead.
This adds a KUnit-specific equivalent: kunit_device_register(), which
creates a device which will be automatically cleaned up on test exit
(such as, for example, if an assertion fails).
It's also possible to unregister it earlier with
kunit_device_unregister().
This can replace the root_device_register() users pretty comfortably,
though doesn't resolve the issue with devm_ resources not being released
properly as laid out in [2]. Updating the implementation here to use a
'kunit' bus should, I think, be reasonably straightforward.
The first patch in the series is an in-progress implementation of a
separate new 'kunit_defer()' API, upon which this device implementation
is built.
If the overall idea seems good, I'll make sure to add better
tests/documentation, and patches converting existing tests to this API.
Cheers,
-- David
[1]: https://lore.kernel.org/linux-kselftest/bad670ee135391eb902bd34b8bcbe777afa…
[2]: https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@hou…
---
David Gow (2):
kunit: resource: Add kunit_defer() functionality
kunit: Add APIs for managing devices
include/kunit/device.h | 25 +++++++++
include/kunit/resource.h | 87 +++++++++++++++++++++++++++++++
lib/kunit/Makefile | 1 +
lib/kunit/device.c | 68 ++++++++++++++++++++++++
lib/kunit/resource.c | 110 +++++++++++++++++++++++++++++++++++++++
5 files changed, 291 insertions(+)
create mode 100644 include/kunit/device.h
create mode 100644 lib/kunit/device.c
--
2.40.0.348.gf938b09366-goog