From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46567EC873D for ; Thu, 7 Sep 2023 16:27:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238953AbjIGQ1h (ORCPT ); Thu, 7 Sep 2023 12:27:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240613AbjIGQ0i (ORCPT ); Thu, 7 Sep 2023 12:26:38 -0400 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 287FD2728 for ; Thu, 7 Sep 2023 09:23:55 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-4122e42a76aso8535001cf.1 for ; Thu, 07 Sep 2023 09:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694103761; x=1694708561; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nAcaB2pTm5ugUpb7jItBu7GBa9HGPWbiLI0lhRjflAk=; b=AMcxR3jwwmCBTZBUTcvlMUhzbxiiQvCu1Hi9LmwivQBuVI+cqkCqjchM6Aa0snKt1V NqeikiNrG1YgBvNYgN9OyEljiqq8vFYYR5xwMqjCyOREOVmqYYEdHKt1WLZxxNcveNAV uF7k+8IPG53oKiN9G/2bQx3laLx5TqPvN5BustBJqA+jL19WgOiPL8+tggQJtaP6gOwn LwOdcLwlcULXxlpqe9jI9cdBGqD3+qQWAq4KBZcpq5EwKe2z1mDGgroHcPHxiL/bwHBL KBQtQY6hMKH/ljWamgfRWlMR1eDhrHfnPp2VflZ6YKpdnFvrkeR0WLjrBDLqlTlyGGDk 74bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694103761; x=1694708561; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nAcaB2pTm5ugUpb7jItBu7GBa9HGPWbiLI0lhRjflAk=; b=lR3brbPGFmnloICXSc8QdvYxZbH5mSFwgWaPPCB9HepalLTzyE2BB9E0ZbIES8AUQj HPFqv+OwBOTd/x534bhf+EH4slc1Y4tbnGacpoZhI2QwucSV0dmzruVaLKwZAUZ6Qitj hAzLwcl0KWzPUclKphLyrbPt1jyzA4ZlfbgS9wxL9WPGGEUExr+3arq2N3ugRY60hpaZ rQNQW63aGxcL7M0XLzyCZEQQC4kNWcJSnSDO/D8EI9KFLtpAu9fa74NsG4Bn1e2kDm34 MNnU6JmSV0SeaehoJgQHsUBnki+5vMTeodlYfzpIVa213WcvPHidiHUXg7NZda8kEcvq D6bQ== X-Gm-Message-State: AOJu0YyxuXoXHP2p3ORhLkYIroRQ68fgwboq1JUMnhSUDDfsq96NzTE1 b5/o5p+7UusrHpsrj2a0OQrf6WvYIS/+0lVgjbwZjVpjdbs0HUYp X-Google-Smtp-Source: AGHT+IG3iM5SVFsQBffezpzdNtWCyc5u9P9zQgzxCYNNrdFDmyZDKiMxM6k7I5B7BvMWEn22bFgEPztstkMTEryGy0M= X-Received: by 2002:a25:e808:0:b0:d7f:ec57:bce6 with SMTP id k8-20020a25e808000000b00d7fec57bce6mr1114484ybd.26.1694070032245; Thu, 07 Sep 2023 00:00:32 -0700 (PDT) MIME-Version: 1.0 References: <20230905185309.131295-1-brgl@bgdev.pl> In-Reply-To: <20230905185309.131295-1-brgl@bgdev.pl> From: Linus Walleij Date: Thu, 7 Sep 2023 09:00:20 +0200 Message-ID: Subject: Re: [PATCH 00/21] gpio: convert users to gpio_device_find() and remove gpiochip_find() To: Bartosz Golaszewski , Johan Hovold Cc: Aaro Koskinen , Janusz Krzysztofik , Tony Lindgren , Russell King , Mika Westerberg , Andy Shevchenko , Dipen Patel , Thierry Reding , Jonathan Hunter , Hans de Goede , Mark Gross , linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org, timestamp@lists.linux.dev, linux-tegra@vger.kernel.org, platform-driver-x86@vger.kernel.org, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Tue, Sep 5, 2023 at 8:53=E2=80=AFPM Bartosz Golaszewski = wrote: > The GPIO subsystem does not handle hot-unplug events very well. Yeah :/ it was never designed for this, and I've seen the discussions. The person who made the biggest effort to make this sort-of work was actually Johan Hovold so I added him to the mail so you can include him in upcoming iterations. I think he was working with GPIO on greybus at the time. Maybe he want to take a look! > Before we can even get to fixing the locking, we need to address a seriou= s > abuse of the GPIO driver API - accessing struct gpio_chip by anyone who i= sn't > the driver owning this object. This structure is owned by the GPIO provid= er > and its lifetime is tied to that of that provider. It is destroyed when t= he > device is unregistered and this may happen at any moment. struct gpio_dev= ice > is the opaque, reference counted interface to struct gpio_chip (which is = the > low-level implementation) and all access should pass through it. Thanks for looking into this. As I remember I have tried to bring down this abuse over the years and IIRC it used to be even worse, it came from the fact that all GPIO drivers used to be under some arch/* tree and often loosely using the kernel GPIO API but in addition providing a custom API... > The end-goal is to make all gpio_device manipulators check the existence = of > gdev->chip and then lock it for the duration of any of the calls using SR= CU. Excellent! > This series starts the process by replacing gpiochip_find() with > gpio_device_find(). This is in line with other device_find type interface= s and > returns a reference to the GPIO device that is guaranteed to remain valid > until it is put. I agree with the direction and I see no major problem with the patches other than some testing and cosmetics. The kernel sure as hell looks better *after* this than *before* so once you have rough confidence in the patches I think they should be merged and any issuse fixed up in-tree so we get wider audience and can continue the planned refactorings. So: Acked-by: Linus Walleij I'll try to provide some detailed reviews if something stands out. Yours, Linus Walleij