Re: [PATCH v3 02/27] staging: iio: resolver: ad2s1210: fix use before initialization

From: Vincent Whitchurch <Vincent.Whitchurch@axis.com>
To: "Jonathan.Cameron@Huawei.com" <Jonathan.Cameron@Huawei.com>,
	"dan.carpenter@linaro.org" <dan.carpenter@linaro.org>
Cc: "linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	"Michael.Hennerich@analog.com" <Michael.Hennerich@analog.com>,
	kernel <kernel@axis.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"dlechner@baylibre.com" <dlechner@baylibre.com>,
	"nuno.sa@analog.com" <nuno.sa@analog.com>,
	"pmolloy@baylibre.com" <pmolloy@baylibre.com>,
	Vincent Whitchurch <Vincent.Whitchurch@axis.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"jic23@kernel.org" <jic23@kernel.org>,
	"ahaslam@baylibre.com" <ahaslam@baylibre.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"david@lechnology.com" <david@lechnology.com>
Subject: Re: [PATCH v3 02/27] staging: iio: resolver: ad2s1210: fix use before initialization
Date: Fri, 6 Oct 2023 14:48:29 +0000	[thread overview]
Message-ID: <de527e3f87effe7e446b44d84e43aead26f9fdec.camel@axis.com> (raw)
In-Reply-To: <20231002101742.0000774b@Huawei.com>

On Mon, 2023-10-02 at 10:17 +0100, Jonathan Cameron wrote:
> Hmm. What happened to roadtest?  I was hoping that would solve this sort
> of issue by allowing simple testing of basic functionality...

Roadtest is alive and well.  Several of my coworkers have been using it
for development and testing of new drivers[0][1][2][3][4] and
patches[5][6], and this has resulted in easier testing and refactoring
during development, more robust code, and of course the ability to
easily detect regressions after the patches are merged.

[0] https://lore.kernel.org/lkml/20230323-add-opt4001-driver-v2-2-0bae0398669d@axis.com/
[1] https://lore.kernel.org/lkml/d218a1bc75402b5ebd6e12a563f7315f83fe966c.1689753076.git.waqar.hameed@axis.com/
[2] https://lore.kernel.org/lkml/7b856b74c4c0f8c6c539d7c692051c9203b103c0.1692699931.git.waqar.hameed@axis.com/
[3] https://lore.kernel.org/lkml/20231002-rx8111-add-timestamp0-v1-1-353727cf7f14@axis.com/
[4] https://lore.kernel.org/lkml/20230502-tps6287x-driver-v3-2-e25140a023f5@axis.com/
[5] https://lore.kernel.org/lkml/20221012102347.153201-1-chenhuiz@axis.com/
[6] https://lore.kernel.org/lkml/20220413114014.2204623-3-camel.guo@axis.com/

In fact, by running our roadtests on newer kernels we have found
numerous bugs[10][12][14] and regressions[7][8][9][11][15] in mainline,
including subsystem-level issues affecting other drivers too.

[7] https://lore.kernel.org/lkml/20230911-regulator-voltage-sel-v1-1-886eb1ade8d8@axis.com/
[8] https://lore.kernel.org/lkml/20230918-power-uaf-v1-1-73c397178c42@axis.com/
[9] https://lore.kernel.org/lkml/20230829-tps-voltages-v1-1-7ba4f958a194@axis.com/
[10] https://lore.kernel.org/lkml/20230613-genirq-nested-v3-1-ae58221143eb@axis.com/
[11] https://lore.kernel.org/lkml/20220503114333.456476-1-camel.guo@axis.com/
[12] https://lore.kernel.org/linux-iio/20220816080828.1218667-1-vincent.whitchurch@axis.com/
[13] https://lore.kernel.org/linux-iio/20220519091925.1053897-1-vincent.whitchurch@axis.com/
[14] https://lore.kernel.org/linux-iio/20220620144231.GA23345@axis.com/
[15] https://lore.kernel.org/linux-spi/YxBX4bXG02E4lSUW@axis.com/

(The above lists are not exhaustive.)

> Hope it is still headed for a new version / upstream!

I pushed out an update with a squash of (most parts of) our internal
version out to the following repo, it's based on v6.6-rc4.

  https://github.com/vwax/linux/tree/roadtest/devel

(There are currently 6 lines of --diff-filter=M against v6.6-rc4 on the
 linked repo.  Two of those are from a patch which is posted and waiting
 for review on the lists, and the rest are for enabling regmap debugfs
 writes which are used from some of the newer tests.)

Since roadtest itself does not require any patches to the kernel or any
out-of-tree modules, the maintenance of the framework would not really
be simplified by putting it in the upstream tree.  However, there is of
course a potentially large benefit to the quality of many kinds of
kernel drivers if roadtest gets used by others, and having it in-tree
could facilitate that.  And it would potentially allow regressions like
the ones we're finding to be caught _before_ they go in, since anyone
can run the tests without special hardware.

The idea of having to maintain it in-tree and doing all the work that
goes along with that (dealing with the expectations of maintainers,
wrangling patches from mailing lists, etc), is something I personally
have had a hard time warming up to, but I have some coworkers who may
potentially be interested in that kind of work, so I wouldn't rule out
another posting of the patch set targeting upstream sometime in the
future.