Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 23 Aug 2022 10:10:45 +0200
From:   Vincent Whitchurch <vincent.whitchurch@axis.com>
To:     Jonathan Cameron <jic23@kernel.org>
CC:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        kernel <kernel@axis.com>, Lars-Peter Clausen <lars@metafoo.de>,
        linux-iio <linux-iio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iio: buffer: Silence lock nesting splat
Message-ID: <YwSLhWFbGb26B3mx@axis.com>
References: <20220816080828.1218667-1-vincent.whitchurch@axis.com>
 <CAHp75VebQfdHrfYTmF0w9M556ZV8fG5jJ2rAN5a3mrB1mbvOQw@mail.gmail.com>
 <20220820120800.519b5eb5@jic23-huawei>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220820120800.519b5eb5@jic23-huawei>
Precedence: bulk

On Sat, Aug 20, 2022 at 01:08:00PM +0200, Jonathan Cameron wrote:
> On Fri, 19 Aug 2022 11:03:55 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On top of that, Fixes tag?
> It's going to be tricky to identify - the interface predates usecases that were IIO
> drivers by a long way.  I guess introduction of first IIO driver that used
> a callback buffer? No idea which one that was :(

AFAICS there's only one IIO driver upstream using a callback buffer, and
it's lmp91000, so I can point the fixes tag to the patch which added
that.

By the way, note that lmp91000 actually fails to probe in mainline
without extra patches, and it seems to have been that way for a while
now.  I noticed this lockdep splat when working on a new driver which
also uses a callback buffer.  I can post the fixes I used to get
lmp91000 to probe successfully (in roadtest) separately.