Re: [PATCH v12 02/11] lib/test_linear_ranges: add a test for the 'linear_ranges'

2020-05-11 Thread Mark Brown
On Fri, May 08, 2020 at 06:42:25PM +, Vaittinen, Matti wrote:

> I'm sorry. I did build allmodconfig build but missed the warning :/ I
> saw you applied 1-5. Do you want a single incremental patch with
> MODULE_LICENSE() or should I resubmit of whole series? GPL is the
> license I would like to use for linking and SPDX should cover more
> accurate version information.

| If any updates are required or you are submitting further changes they
| should be sent as incremental updates against current git, existing
| patches will not be replaced.


signature.asc
Description: PGP signature


Re: [PATCH v12 02/11] lib/test_linear_ranges: add a test for the 'linear_ranges'

2020-05-09 Thread Vaittinen, Matti

On Fri, 2020-05-08 at 18:17 +0100, Mark Brown wrote:
> On Fri, May 08, 2020 at 06:40:43PM +0300, Matti Vaittinen wrote:
> > Add a KUnit test for the linear_ranges helper.
> > 
> > Signed-off-by: Matti Vaittinen 
> > Reviewed-by: Brendan Higgins 
> 
> This now generates:
> 
> WARNING: modpost: missing MODULE_LICENSE() in lib/linear_ranges.o
> see include/linux/module.h for more information
> 
> when the tests are built as a module and select the library.

I sent a fix as an incremental patch. Please let me know if it is not
the way to go.

And Sorry for the trouble!

Best Regards
Matti Vaittinen


Re: [PATCH v12 02/11] lib/test_linear_ranges: add a test for the 'linear_ranges'

2020-05-08 Thread Vaittinen, Matti
Thanks Mark!

On Fri, 2020-05-08 at 18:17 +0100, Mark Brown wrote:
> On Fri, May 08, 2020 at 06:40:43PM +0300, Matti Vaittinen wrote:
> > Add a KUnit test for the linear_ranges helper.
> > 
> > Signed-off-by: Matti Vaittinen 
> > Reviewed-by: Brendan Higgins 
> 
> This now generates:
> 
> WARNING: modpost: missing MODULE_LICENSE() in lib/linear_ranges.o
> see include/linux/module.h for more information
> 
> when the tests are built as a module and select the library.

I'm sorry. I did build allmodconfig build but missed the warning :/ I
saw you applied 1-5. Do you want a single incremental patch with
MODULE_LICENSE() or should I resubmit of whole series? GPL is the
license I would like to use for linking and SPDX should cover more
accurate version information.


Best Regards
--Matti



Re: [PATCH v12 02/11] lib/test_linear_ranges: add a test for the 'linear_ranges'

2020-05-08 Thread Mark Brown
On Fri, May 08, 2020 at 06:40:43PM +0300, Matti Vaittinen wrote:
> Add a KUnit test for the linear_ranges helper.
> 
> Signed-off-by: Matti Vaittinen 
> Reviewed-by: Brendan Higgins 

This now generates:

WARNING: modpost: missing MODULE_LICENSE() in lib/linear_ranges.o
see include/linux/module.h for more information

when the tests are built as a module and select the library.


signature.asc
Description: PGP signature


[PATCH v12 02/11] lib/test_linear_ranges: add a test for the 'linear_ranges'

2020-05-08 Thread Matti Vaittinen
Add a KUnit test for the linear_ranges helper.

Signed-off-by: Matti Vaittinen 
Reviewed-by: Brendan Higgins 
---

Changes since v11: Added missing dependency to LINEAR_RANGES lib.

 lib/Kconfig.debug|  12 +++
 lib/Makefile |   1 +
 lib/test_linear_ranges.c | 228 +++
 3 files changed, 241 insertions(+)
 create mode 100644 lib/test_linear_ranges.c

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 21d9c5f6e7ec..f3322a620674 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2092,6 +2092,18 @@ config LIST_KUNIT_TEST
 
  If unsure, say N.
 
+config LINEAR_RANGES_TEST
+   tristate "KUnit test for linear_ranges"
+   depends on KUNIT
+   select LINEAR_RANGES
+   help
+ This builds the linear_ranges unit test, which runs on boot.
+ Tests the linear_ranges logic correctness.
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
 config TEST_UDELAY
tristate "udelay test driver"
help
diff --git a/lib/Makefile b/lib/Makefile
index 20b9cfdcad69..cd548bfa8df9 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -310,3 +310,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
 
 # KUnit tests
 obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
+obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
diff --git a/lib/test_linear_ranges.c b/lib/test_linear_ranges.c
new file mode 100644
index ..676e0b8abcdd
--- /dev/null
+++ b/lib/test_linear_ranges.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for the linear_ranges helper.
+ *
+ * Copyright (C) 2020, ROHM Semiconductors.
+ * Author: Matti Vaittinen 
+ */
+#include 
+
+#include 
+
+/* First things first. I deeply dislike unit-tests. I have seen all the hell
+ * breaking loose when people who think the unit tests are "the silver bullet"
+ * to kill bugs get to decide how a company should implement testing 
strategy...
+ *
+ * Believe me, it may get _really_ ridiculous. It is tempting to think that
+ * walking through all the possible execution branches will nail down 100% of
+ * bugs. This may lead to ideas about demands to get certain % of "test
+ * coverage" - measured as line coverage. And that is one of the worst things
+ * you can do.
+ *
+ * Ask people to provide line coverage and they do. I've seen clever tools
+ * which generate test cases to test the existing functions - and by default
+ * these tools expect code to be correct and just generate checks which are
+ * passing when ran against current code-base. Run this generator and you'll 
get
+ * tests that do not test code is correct but just verify nothing changes.
+ * Problem is that testing working code is pointless. And if it is not
+ * working, your test must not assume it is working. You won't catch any bugs
+ * by such tests. What you can do is to generate a huge amount of tests.
+ * Especially if you were are asked to proivde 100% line-coverage x_x. So what
+ * does these tests - which are not finding any bugs now - do?
+ *
+ * They add inertia to every future development. I think it was Terry Pratchet
+ * who wrote someone having same impact as thick syrup has to chronometre.
+ * Excessive amount of unit-tests have this effect to development. If you do
+ * actually find _any_ bug from code in such environment and try fixing it...
+ * ...chances are you also need to fix the test cases. In sunny day you fix one
+ * test. But I've done refactoring which resulted 500+ broken tests (which had
+ * really zero value other than proving to managers that we do do "quality")...
+ *
+ * After this being said - there are situations where UTs can be handy. If you
+ * have algorithms which take some input and should produce output - then you
+ * can implement few, carefully selected simple UT-cases which test this. I've
+ * previously used this for example for netlink and device-tree data parsing
+ * functions. Feed some data examples to functions and verify the output is as
+ * expected. I am not covering all the cases but I will see the logic should be
+ * working.
+ *
+ * Here we also do some minor testing. I don't want to go through all branches
+ * or test more or less obvious things - but I want to see the main logic is
+ * working. And I definitely don't want to add 500+ test cases that break when
+ * some simple fix is done x_x. So - let's only add few, well selected tests
+ * which ensure as much logic is good as possible.
+ */
+
+/*
+ * Test Range 1:
+ * selectors:  2   3   4   5   6
+ * values (5): 10  20  30  40  50
+ *
+ * Test Range 2:
+ * selectors:  7   8   9   10
+ * values (4): 100 150 200 250
+ */
+
+#define RANGE1_MIN 10
+#define RANGE1_MIN_SEL 2
+#define RANGE1_STEP 10
+
+/* 2, 3, 4, 5, 6 */
+static const unsigned int range1_sels[] = { RANGE1_MIN_SEL, RANGE1_MIN_SEL + 1,