Message ID | 20230929-ad2s1210-mainline-v3-2-fa4364281745@baylibre.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp230248vqb; Fri, 29 Sep 2023 23:41:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFiXhWH5yvc16P5rHsX2zXJDAflBmDykRKdEnuQ7JJ9uTKpJ86oonB7SGfjse9kubUO/ekf X-Received: by 2002:a05:6358:e49c:b0:143:9bc0:a975 with SMTP id by28-20020a056358e49c00b001439bc0a975mr6972135rwb.7.1696056077262; Fri, 29 Sep 2023 23:41:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696056077; cv=none; d=google.com; s=arc-20160816; b=aq9NIsng71wpBbG/IU6qnMYVUgmGes7OPLC3o8sNaJfpWirhzonp+bz3Gq4s6qjiQb vnt2XguGUW0qGgaqvxnfgadqJ01AfVwIJ/ZJefhU/mQmk2A/ijJTxy0m31+C601Y7SAZ AZH1a0KTim5YdWma9hof4VO0UhM+9xyUTwpRaSq7yjdAnS3c9WmjfSgMUcNj+QUBiK67 y+XsErsj8Q5T/Ti0aKGl9SYz7WVy2qXe6r+kTUt3mhRo36EyUHDFFkBZQ56WH9y2ecmD ZTBRhuL6nakDBVuesxO28Tpydo2I0sQr2P3Su0rOaO/RKsaBGCAW8wN8mMwtANXVHII4 mPww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JKHIiAEIE2mVS9nRK2qrqb6L2W/l1AsQzObZva2M/Qk=; fh=/JQ89VrFJ6cddpMA/8uKU4hR6LyRWF8O9dzD336qQ7I=; b=SJIdRKHTp7G2vsMCwZcC9EYpPd26a63Sb7PQlOKGRDLalxT5oDRjvAL2yKUUDDT0TV ugJS5QxydvZgO8ERbiN4XGC1KBQV3Y9EDlepucCJ+x9efzSnE9USYEBxwDA7C1y9vtEo 7plhPZj5WjK7/hGHZig47RWi03gJ2pAVTCpZ7zxv+62zYWyGJ/5Jp8tpWD6i9FpSxuWH KuZvL03ets5jtQu+Pdtxsjx51m+oIrmqakWiHbASaRjzH7AFo/RYCP8V7BY9qjnQfPIL jy59CGVYag68xSlPzD9bF+ghRIlWNvRNdKA1boegm4jsYKHyxndEpSoBvICV7TF2tPQu fMXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20230601.gappssmtp.com header.s=20230601 header.b=j4PQqsf2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id l3-20020a17090ac58300b0027775575d1dsi1126819pjt.0.2023.09.29.23.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 23:41:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20230601.gappssmtp.com header.s=20230601 header.b=j4PQqsf2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 7352080BE3FC; Fri, 29 Sep 2023 10:26:11 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233354AbjI2RZx (ORCPT <rfc822;pwkd43@gmail.com> + 19 others); Fri, 29 Sep 2023 13:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233260AbjI2RZv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 29 Sep 2023 13:25:51 -0400 Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 467281B8 for <linux-kernel@vger.kernel.org>; Fri, 29 Sep 2023 10:25:49 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-57d086365f7so3021614eaf.0 for <linux-kernel@vger.kernel.org>; Fri, 29 Sep 2023 10:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1696008348; x=1696613148; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=JKHIiAEIE2mVS9nRK2qrqb6L2W/l1AsQzObZva2M/Qk=; b=j4PQqsf2TA8TkYJ+C8KvefTKjDPFlZvpI1lokxnsLrQs4lzDlByW6WJVdZZAqgEAOs 1r08PgUMG2N/OU4W5TBEnGYs4OInjBn8CvnXFowv2wCITrH5pSS1FjVS/fzllZaU+dUN kp+CTnbscvLpBFg0zFokBWDaIeJ4q/KpLhDeK+F3lFtxS0qresUnOsefaterSltQZNwH KcWNaW6/eyy14kHOGExsveguQy/WeFKmexiO7OtGw+o7CkP/3wsNhMSdpEuy655gDA/e ABCESi/JjxeNxiJoT8dYaZ8oF5f4/e8eF4ZKj1tPTOa8ya3UyA6qf5gL7EqD1yg+N+ma QlHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696008348; x=1696613148; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JKHIiAEIE2mVS9nRK2qrqb6L2W/l1AsQzObZva2M/Qk=; b=q6DqknJpNc8xBwZ5N9BlJuwtU40Tn6RnPNpNQ5ff9kpU5rNogKhbC8Mrl+Ye/kwGsk Amzch+uhJBwNCnTSu/o6iz9YGxVzYTS1XWIoYLRj2RJw0xbOWOvu1ohf6bB1w0fr24DI pBFXYoQlmbye7Zw8wDcGAMQH2LHtnyYyGgH66IwQuQ+hGjW4GCfEfrhGaW9ygDRqgkSJ YcvRDzNe2qcbk90rZKPt9IaObI6X1u4OqMK4mfPY51+oaekh2QdgWPDs8si6SIa8ij0x w2MO2DTnuNm7xRB7wxjeLUvDTcdIJDSFSRcdLv9DQHbbdQrFjV7Yl1ghiPP44S39mOlu LO3g== X-Gm-Message-State: AOJu0Yzu1kLzxf+TELg4SDDqJEWWoquSxlDydoN7YTAnBC6LZ5R2+ugc LfL8alCScte5kMnx1rgTn/R7TA== X-Received: by 2002:a4a:6f49:0:b0:57b:5e98:f733 with SMTP id i9-20020a4a6f49000000b0057b5e98f733mr4812423oof.3.1696008348476; Fri, 29 Sep 2023 10:25:48 -0700 (PDT) Received: from freyr.lechnology.com (ip98-183-112-25.ok.ok.cox.net. [98.183.112.25]) by smtp.gmail.com with ESMTPSA id f128-20020a4a5886000000b0057bb326cad4sm2272915oob.33.2023.09.29.10.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 10:25:48 -0700 (PDT) From: David Lechner <dlechner@baylibre.com> To: linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-staging@lists.linux.dev Cc: David Lechner <david@lechnology.com>, Jonathan Cameron <jic23@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Michael Hennerich <Michael.Hennerich@analog.com>, =?utf-8?q?Nuno_S=C3=A1?= <nuno.sa@analog.com>, Axel Haslam <ahaslam@baylibre.com>, Philip Molloy <pmolloy@baylibre.com>, linux-kernel@vger.kernel.org, David Lechner <dlechner@baylibre.com> Subject: [PATCH v3 02/27] staging: iio: resolver: ad2s1210: fix use before initialization Date: Fri, 29 Sep 2023 12:23:07 -0500 Message-ID: <20230929-ad2s1210-mainline-v3-2-fa4364281745@baylibre.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230929-ad2s1210-mainline-v3-0-fa4364281745@baylibre.com> References: <20230929-ad2s1210-mainline-v3-0-fa4364281745@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: b4 0.12.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 29 Sep 2023 10:26:11 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778443696807592224 X-GMAIL-MSGID: 1778443696807592224 |
Series |
iio: resolver: move ad2s1210 out of staging
|
|
Commit Message
David Lechner
Sept. 29, 2023, 5:23 p.m. UTC
From: David Lechner <david@lechnology.com> From: David Lechner <dlechner@baylibre.com> This fixes a use before initialization in ad2s1210_probe(). The ad2s1210_setup_gpios() function uses st->sdev but it was being called before this field was initialized. Signed-off-by: David Lechner <dlechner@baylibre.com> --- v3 changes: * This is a new patch split out from "staging: iio: resolver: ad2s1210: fix probe" drivers/staging/iio/resolver/ad2s1210.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On Fri, 29 Sep 2023 12:23:07 -0500 David Lechner <dlechner@baylibre.com> wrote: > From: David Lechner <david@lechnology.com> > > From: David Lechner <dlechner@baylibre.com> > > This fixes a use before initialization in ad2s1210_probe(). The > ad2s1210_setup_gpios() function uses st->sdev but it was being called > before this field was initialized. > > Signed-off-by: David Lechner <dlechner@baylibre.com> Applied to the togreg banch of iio.git and pushed out as testing for 0-day to poke at it. I didn't pull this out as a fix to upstream quicker because it would make a mess of the rest of applying the rest of the series. Maybe we want to consider backporting some of these at somepoint. Jonathan > --- > > v3 changes: > * This is a new patch split out from "staging: iio: resolver: ad2s1210: > fix probe" > > drivers/staging/iio/resolver/ad2s1210.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/iio/resolver/ad2s1210.c b/drivers/staging/iio/resolver/ad2s1210.c > index f695ca0547e4..3f08b59f4e19 100644 > --- a/drivers/staging/iio/resolver/ad2s1210.c > +++ b/drivers/staging/iio/resolver/ad2s1210.c > @@ -658,9 +658,6 @@ static int ad2s1210_probe(struct spi_device *spi) > if (!indio_dev) > return -ENOMEM; > st = iio_priv(indio_dev); > - ret = ad2s1210_setup_gpios(st); > - if (ret < 0) > - return ret; > > spi_set_drvdata(spi, indio_dev); > > @@ -671,6 +668,10 @@ static int ad2s1210_probe(struct spi_device *spi) > st->resolution = 12; > st->fexcit = AD2S1210_DEF_EXCIT; > > + ret = ad2s1210_setup_gpios(st); > + if (ret < 0) > + return ret; > + > indio_dev->info = &ad2s1210_info; > indio_dev->modes = INDIO_DIRECT_MODE; > indio_dev->channels = ad2s1210_channels; >
On Fri, Sep 29, 2023 at 12:23:07PM -0500, David Lechner wrote: > From: David Lechner <david@lechnology.com> > > From: David Lechner <dlechner@baylibre.com> > > This fixes a use before initialization in ad2s1210_probe(). The > ad2s1210_setup_gpios() function uses st->sdev but it was being called > before this field was initialized. > > Signed-off-by: David Lechner <dlechner@baylibre.com> > --- > Fixes: b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.") This would crash the driver right away, on probe. It's amazing no one filed a bug report even though the bug is 12 years old. regards, dan carpenter
On Mon, 2 Oct 2023 11:07:15 +0300 Dan Carpenter <dan.carpenter@linaro.org> wrote: > On Fri, Sep 29, 2023 at 12:23:07PM -0500, David Lechner wrote: > > From: David Lechner <david@lechnology.com> > > > > From: David Lechner <dlechner@baylibre.com> > > > > This fixes a use before initialization in ad2s1210_probe(). The > > ad2s1210_setup_gpios() function uses st->sdev but it was being called > > before this field was initialized. > > > > Signed-off-by: David Lechner <dlechner@baylibre.com> > > --- > > > > Fixes: b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.") Thanks but nope, not that one. At that point ad2s1210_setup_gpios, didn't use st->sdev. I think this went wrong when the platform data was removed in I 'think' it was Fixes: f356dc6ec26b ("staging: iio: ad2s1210: Switch to the gpio descriptor interface") > > This would crash the driver right away, on probe. It's amazing no one > filed a bug report even though the bug is 12 years old. Only 5 years :) Welcome to the long tail of IIO Devices and the long term availability of the hardware - this is still a production part. Clearly no one was using the upstream driver for 5 + years, but here comes David who is not only fixing the bugs but cleaning it up. Hmm. What happened to roadtest? I was hoping that would solve this sort of issue by allowing simple testing of basic functionality... Hope it is still headed for a new version / upstream! Jonathan > regards, > dan carpenter
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.
On Fri, 6 Oct 2023 14:48:29 +0000 Vincent Whitchurch <Vincent.Whitchurch@axis.com> wrote: Hi Vincent Thanks for the update, > 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.) > Great stuff! > > 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 Thanks. > > (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. Exactly - my main interest is the dream of getting to the point where new drivers typically also come with roadtest tests, with the aim that they will be used for regression testing. For IIO I might lean on / ask nicely few of the bigger contributors to add fairly comprehensive tests for say one in 3 of their drivers, providing a canary for any subsystem level problems that might sneak in. The stability gained for those drivers might also prove it's own benefit to push people to add tests. At somepoint in the longer term I might even make it a requirement for upstreaming a new driver + slowly tackle the backlog of existing ones. From my experiments with it last year, this is a trivial burden fo > > 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. I fully appreciate your concern. I just really like roadtest and want a smooth way to integrate using it with my upstream maintenance (and occasional development) process... I of course can't expect you to commit to anything though - I'd be delighted if someone else wants to take this forwards but that would be very much their decision to make! Having not yet waded into the latest code, how 'stable' is it from the point of view of modifications to tests? I can rebase the ones I have out of tree and see, but I'm after an assessment that incorporates what you are planning to change in future. I guess the nasty stuff is if you have a few hundred additional drivers in the test set, any modification to the way they interact with the core of roadtest becomes very painful to push into those tests. One starting point would be to separate the tests directory from the directories containing roadtest frameworks etc as that would help to limit scope of responsibility. If a potential upstream roadtest maintainer is primarily concerned about review + handling of the actual tests, other than potentially letting in some ugly code, I'd imagine any subsystem maintainer who opts into this will take that burden on - perhaps with the occasional question heading your way. I'd certainly not expect you to have to deal with high patch flows and would ensure that didn't happen for any IIO tests (any review people have time for is of course welcome!) +CC a few maintainers of other subsystems who may be interested (I know one of them is ;) Jonathan
diff --git a/drivers/staging/iio/resolver/ad2s1210.c b/drivers/staging/iio/resolver/ad2s1210.c index f695ca0547e4..3f08b59f4e19 100644 --- a/drivers/staging/iio/resolver/ad2s1210.c +++ b/drivers/staging/iio/resolver/ad2s1210.c @@ -658,9 +658,6 @@ static int ad2s1210_probe(struct spi_device *spi) if (!indio_dev) return -ENOMEM; st = iio_priv(indio_dev); - ret = ad2s1210_setup_gpios(st); - if (ret < 0) - return ret; spi_set_drvdata(spi, indio_dev); @@ -671,6 +668,10 @@ static int ad2s1210_probe(struct spi_device *spi) st->resolution = 12; st->fexcit = AD2S1210_DEF_EXCIT; + ret = ad2s1210_setup_gpios(st); + if (ret < 0) + return ret; + indio_dev->info = &ad2s1210_info; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->channels = ad2s1210_channels;