Message ID | 20231011130204.52265-1-brgl@bgdev.pl |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp521300vqb; Wed, 11 Oct 2023 06:02:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHeyNdLfOp6tPrE3ocvP20c42Aw7KorOuP+Q7c6XMQLC3xP9wipkxPg2S3FJcm78v41dEy/ X-Received: by 2002:a17:90a:9f83:b0:27c:fbf8:6c43 with SMTP id o3-20020a17090a9f8300b0027cfbf86c43mr2923098pjp.1.1697029353754; Wed, 11 Oct 2023 06:02:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697029353; cv=none; d=google.com; s=arc-20160816; b=RGCcuWPJeH1GT/g2U4R82ukQIPRugtLUprB2X18e7K25zA14OY0IRsBs3DUsOHCmJM KcXjKLLx9TuU0gAurNO0tYCb7McrUNa7/M4I5PlENErr6WQY3/Weg+O/Z++FEqNV6Rsq oTTNl8Xv3ZSSOKStJsti+RGWPhUiCasIEVuHbylL+K+FJSFWVBPwgzIfMzPMBB3Kvgt5 SLtfGbzEyHcjnFdk2Qca3sb4h24rFR1x/g2RyvQVulYZAapk9rx4z+IoetE3oKM53XiK ACxeZ8/9VlTMS1tOz7rcOIyuuG448F21g2VNZorqbvCk/ONuVWorhIhxPYzuvjUXTRMl ZTuw== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=63QGBdQugmbIeYioEFVwwnNIFK60s4bwdnFfbGlBXP0=; fh=YP/ZZen/fLhGMMezUuWB0b3Qyqd3gueBWEsOMCN9gx4=; b=URzBISCiA5UHEiXqkX+4DEoS60GYFrql3OwaHUgO7OKTA8c8vZCscVjHYmVbfNAXN4 OkgAztNe+/EmDMaI83Xoa7V6u0jNRh0T96Dac1Fh7pH6ogk2odEgL1N8H9rfQEcGIqJ0 SMpnz69zqA0vqGW/HJSgeEomAvYflRChRowjibAUEu5GnUyiDSesAJNdKUAW/DrF3DCl C9Z2wMXw1yQrRfA1kGpNibtm0X3q52tvAcpEzlWs9iVQQ/h7Gxays5oNCX14MgikwRxN OgLfoGq4Emfmv56gJOhQcwDqhhD4jvmFKU9NoWoUr6L3r7uOmrNyXoxd/IV1lrGS4Fcd QIFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=dVNaN7bt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id n14-20020a17090ac68e00b0026822221502si1939595pjt.163.2023.10.11.06.02.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 06:02:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=dVNaN7bt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 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 fry.vger.email (Postfix) with ESMTP id 9BF338263515; Wed, 11 Oct 2023 06:02:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231758AbjJKNCN (ORCPT <rfc822;kartikey406@gmail.com> + 18 others); Wed, 11 Oct 2023 09:02:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231262AbjJKNCL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Oct 2023 09:02:11 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6010A7 for <linux-kernel@vger.kernel.org>; Wed, 11 Oct 2023 06:02:09 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3231df054c4so6123727f8f.0 for <linux-kernel@vger.kernel.org>; Wed, 11 Oct 2023 06:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1697029328; x=1697634128; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=63QGBdQugmbIeYioEFVwwnNIFK60s4bwdnFfbGlBXP0=; b=dVNaN7btylMSdzoZNKW45zXrvGW1bR/V+L+eNDccV4BQSz9zMpnfWbcC4i37es0dtC VOVXz9fIKdjQTLjNr7bN/2Zkgx2c7nyPdAzTJaUEPvWtMuKISVKybs2WXIwyUxgY80Hq z3E+F1Qhzf5CcHWAi6tNwGSHTPrUEd6YeN50DukuGhcNr97kpofnt5l3uoNhAICkPTxh n51EH+bpROB+74X+GQkv3UPrJdBDmEkedy9un4DBxv/NezpoyhM0jCQhpNFKy/C/XPcK nNSZrvOEFN0YhbcXLbyLR/+oeseQKOdK39eI+KyQ137FnHRgopjJFtmco+3ugKpFvyOZ /wqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697029328; x=1697634128; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=63QGBdQugmbIeYioEFVwwnNIFK60s4bwdnFfbGlBXP0=; b=IWHoWz812DtoEfXKXc2fepJ1zoV9OFuTsl35Bvt8kQjuF2l53vT2cy6tkmhKTmNa5v RXYJyfCQ4MunDSVwB9JDf/c4ebBivWpTKul29PYW1WcGiDWV2reUJZXfT5HeFKhDV78S 64nuV4WTRjdn9/lCC4/E87SSCipkyC3X4UZWhRcVgtcGIAMTN2+iyaXs1VXhU3TPU3Tz v/YzThF8QKXIadzRSoONodrjFMToTc9FKtXuOEjLRZydtq9rPknm1zcIYyQizb0bHJCK u+I+7y3jYK2gIoU0aOoCdS2WjbvfKiXvdvAYdr1+hzCx/GIAr7hQiKO0ejD2fKn2/QX5 N9cw== X-Gm-Message-State: AOJu0Yz2G9Wq5OkC1E419fGTTbdlhZFrt4cI8GL0GBF9l0dWTMvcC0mM Am/0z8uP4KruAyZE/jEJ7rIZ6Q== X-Received: by 2002:a05:6000:68d:b0:32d:88fd:5c65 with SMTP id bo13-20020a056000068d00b0032d88fd5c65mr1290432wrb.1.1697029327724; Wed, 11 Oct 2023 06:02:07 -0700 (PDT) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:e551:3946:26fc:f94]) by smtp.gmail.com with ESMTPSA id s13-20020adfeccd000000b003198a9d758dsm15455375wro.78.2023.10.11.06.02.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 06:02:07 -0700 (PDT) From: Bartosz Golaszewski <brgl@bgdev.pl> To: Linus Walleij <linus.walleij@linaro.org>, Andy Shevchenko <andy@kernel.org>, Peter Korsgaard <peter.korsgaard@barco.com>, Peter Rosin <peda@axentia.se> Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Subject: [PATCH 0/3] i2c: mux: don't access GPIOLIB internal structures Date: Wed, 11 Oct 2023 15:02:01 +0200 Message-Id: <20231011130204.52265-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.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 (fry.vger.email [0.0.0.0]); Wed, 11 Oct 2023 06:02:24 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779464251507139389 X-GMAIL-MSGID: 1779464251507139389 |
Series |
i2c: mux: don't access GPIOLIB internal structures
|
|
Message
Bartosz Golaszewski
Oct. 11, 2023, 1:02 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The backstory for this short series is that we are identyfing and
removing all unauthorized uses of GPIOLIB structures across the kernel.
For example: there are many users that access struct gpio_chip when the
only user allowed to safely do this is the provider of that chip.
We are very close to removing gpiochip_find(). Another function that
poses a similar problem is gpiod_to_chip() which also returns the
address of the underlying gpio_chip without assuring that it will not go
away e.g. due to a hot-unplug event or a device unbind.
We'll need to replace it with gpiod_to_gpio_device() across the entire
tree. Let's start by actually providing it and adding the first user:
the i2c-mux-gpio driver which dereferences the otherwise opaque struct
gpio_desc.
Let's also add a helper that allows to retrieve the address of the
struct device backing the GPIO device as this is another valid use-case.
Finally, let's un-include the GPIO private header and fix the code to
access the device in a safe way.
As the change is pretty minor, it would be best if patch 3/3 could be
acked by the I2C mux maintainers and went through the GPIO tree.
Otherwise, I can apply patches 1 and 2 and provide an immutable branch.
Bartosz Golaszewski (3):
gpiolib: provide gpio_device_to_device()
gpiolib: provide gpiod_to_gpio_device()
i2c: mux: gpio: don't fiddle with GPIOLIB internals
drivers/gpio/gpiolib.c | 38 ++++++++++++++++++++++++++++++++
drivers/i2c/muxes/i2c-mux-gpio.c | 12 +++++-----
include/linux/gpio/driver.h | 3 +++
3 files changed, 47 insertions(+), 6 deletions(-)
Comments
Hi Bartosz, On Wed, Oct 11, 2023 at 3:02 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > The backstory for this short series is that we are identyfing and > removing all unauthorized uses of GPIOLIB structures across the kernel. > > For example: there are many users that access struct gpio_chip when the > only user allowed to safely do this is the provider of that chip. > > We are very close to removing gpiochip_find(). Another function that > poses a similar problem is gpiod_to_chip() which also returns the > address of the underlying gpio_chip without assuring that it will not go > away e.g. due to a hot-unplug event or a device unbind. > > We'll need to replace it with gpiod_to_gpio_device() across the entire > tree. Let's start by actually providing it and adding the first user: > the i2c-mux-gpio driver which dereferences the otherwise opaque struct > gpio_desc. > > Let's also add a helper that allows to retrieve the address of the > struct device backing the GPIO device as this is another valid use-case. > > Finally, let's un-include the GPIO private header and fix the code to > access the device in a safe way. > > As the change is pretty minor, it would be best if patch 3/3 could be > acked by the I2C mux maintainers and went through the GPIO tree. > Otherwise, I can apply patches 1 and 2 and provide an immutable branch. > > Bartosz Golaszewski (3): > gpiolib: provide gpio_device_to_device() > gpiolib: provide gpiod_to_gpio_device() > i2c: mux: gpio: don't fiddle with GPIOLIB internals The series: Acked-by: Linus Walleij <linus.walleij@linaro.org> Good job! Yours, Linus Walleij
On Wed, Oct 11, 2023 at 3:02 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > The backstory for this short series is that we are identyfing and > removing all unauthorized uses of GPIOLIB structures across the kernel. > > For example: there are many users that access struct gpio_chip when the > only user allowed to safely do this is the provider of that chip. > > We are very close to removing gpiochip_find(). Another function that > poses a similar problem is gpiod_to_chip() which also returns the > address of the underlying gpio_chip without assuring that it will not go > away e.g. due to a hot-unplug event or a device unbind. > > We'll need to replace it with gpiod_to_gpio_device() across the entire > tree. Let's start by actually providing it and adding the first user: > the i2c-mux-gpio driver which dereferences the otherwise opaque struct > gpio_desc. > > Let's also add a helper that allows to retrieve the address of the > struct device backing the GPIO device as this is another valid use-case. > > Finally, let's un-include the GPIO private header and fix the code to > access the device in a safe way. > > As the change is pretty minor, it would be best if patch 3/3 could be > acked by the I2C mux maintainers and went through the GPIO tree. > Otherwise, I can apply patches 1 and 2 and provide an immutable branch. > > Bartosz Golaszewski (3): > gpiolib: provide gpio_device_to_device() > gpiolib: provide gpiod_to_gpio_device() > i2c: mux: gpio: don't fiddle with GPIOLIB internals > > drivers/gpio/gpiolib.c | 38 ++++++++++++++++++++++++++++++++ > drivers/i2c/muxes/i2c-mux-gpio.c | 12 +++++----- > include/linux/gpio/driver.h | 3 +++ > 3 files changed, 47 insertions(+), 6 deletions(-) > > -- > 2.39.2 > Queued for v6.7. Bart