| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Dec 2023 18:31:04 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, Banajit Goswami <bgoswami@...cinc.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Sean Anderson <sean.anderson@...o.com>
Subject: Re: [PATCH 1/4] reset: instantiate reset GPIO controller for shared reset-gpios
On Fri, Dec 22, 2023 at 4:01 PM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> Devices sharing a reset GPIO could use the reset framework for
> coordinated handling of that shared GPIO line. We have several cases of
> such needs, at least for Devicetree-based platforms.
>
> If Devicetree-based device requests a reset line which is missing but
> there is a reset-gpios property, instantiate a new "reset-gpio" platform
> device which will handle such reset line. This allows seamless handling
> of such shared reset-gpios without need of changing Devicetree binding [1].
>
> The "reset-gpio" driver follows shortly.
>
> Link: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/
> Cc: Bartosz Golaszewski <brgl@...ev.pl>
> Cc: Sean Anderson <sean.anderson@...o.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> ---
> drivers/reset/core.c | 70 +++++++++++++++++++++++++++-----
> include/linux/reset-controller.h | 2 +
> 2 files changed, 61 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 4d5a78d3c085..a1f0f515a7e0 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -10,9 +10,12 @@
> #include <linux/export.h>
> #include <linux/kernel.h>
> #include <linux/kref.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_gpio.h>
> #include <linux/acpi.h>
> +#include <linux/platform_device.h>
> #include <linux/reset.h>
> #include <linux/reset-controller.h>
> #include <linux/slab.h>
> @@ -813,13 +816,59 @@ static void __reset_control_put_internal(struct reset_control *rstc)
> kref_put(&rstc->refcnt, __reset_control_release);
> }
>
> +static int __reset_add_reset_gpio_device(struct device_node *node,
> + const struct gpio_desc **out)
> +{
> + struct platform_device *pdev;
> + int gpio;
> +
> + /* Don't care about deprecated '-gpio' suffix. */
> + gpio = of_get_named_gpio(node, "reset-gpios", 0);
Sorry but NAK. This is a legacy API, we've managed to remove all of_
GPIO interfaces but this one. Please don't use it. Any function that
deals with the global GPIO numberspace is deprecated. See below how I
would approach it.
Side note: do we have any formal way of deprecating interfaces in the kernel?
> + if (!gpio_is_valid(gpio))
> + return gpio;
> +
> + pdev = platform_device_register_data(NULL, "reset-gpio",
> + PLATFORM_DEVID_AUTO, &node,
> + sizeof(node));
You seem to make an assumption (in __reset_find_rcdev()) that this
device will get bound to its driver before this function returns.
There is no such guarantee. There are many situations where this may
not happen immediately (think loading the reset-gpio driver as a
module from the filesystem). You should set up a notifier callback on
the platform bus that will get invoked on bus events and wait for this
device's BUS_NOTIFY_BOUND_DRIVER event.
> + if (!IS_ERR(pdev))
> + *out = gpio_to_desc(gpio);
> +
> + return PTR_ERR_OR_ZERO(pdev);
> +}
> +
> +static struct reset_controller_dev *__reset_find_rcdev(const struct of_phandle_args *args,
> + const void *cookie)
> +{
> + struct reset_controller_dev *r, *rcdev;
> +
> + lockdep_assert_held(&reset_list_mutex);
> +
> + rcdev = NULL;
> + list_for_each_entry(r, &reset_controller_list, list) {
> + if (args && args->np) {
> + if (args->np == r->of_node) {
> + rcdev = r;
> + break;
> + }
> + } else if (cookie) {
> + if (cookie == r->cookie) {
As I said in private: there's no guarantee that the same GPIO
descriptor will always reference the same GPIO line. It happens to be
the case currently but it's an implementation detail.
> + rcdev = r;
> + break;
> + }
> + }
> + }
> +
> + return rcdev;
> +}
> +
> struct reset_control *
> __of_reset_control_get(struct device_node *node, const char *id, int index,
> bool shared, bool optional, bool acquired)
> {
> + const struct gpio_desc *gpio = NULL;
> + struct of_phandle_args args = {0};
> struct reset_control *rstc;
> - struct reset_controller_dev *r, *rcdev;
> - struct of_phandle_args args;
> + struct reset_controller_dev *rcdev;
> int rstc_id;
> int ret;
>
> @@ -839,17 +888,16 @@ __of_reset_control_get(struct device_node *node, const char *id, int index,
> index, &args);
> if (ret == -EINVAL)
> return ERR_PTR(ret);
> - if (ret)
> - return optional ? NULL : ERR_PTR(ret);
> + if (ret) {
> + ret = __reset_add_reset_gpio_device(node, &gpio);
> + if (ret)
> + return optional ? NULL : ERR_PTR(ret);
> +
> + args.args_count = 1; /* reset-gpio has only one reset line */
> + }
>
> mutex_lock(&reset_list_mutex);
> - rcdev = NULL;
> - list_for_each_entry(r, &reset_controller_list, list) {
> - if (args.np == r->of_node) {
> - rcdev = r;
> - break;
> - }
> - }
> + rcdev = __reset_find_rcdev(&args, gpio);
>
> if (!rcdev) {
> rstc = ERR_PTR(-EPROBE_DEFER);
> diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
> index 0fa4f60e1186..c0a99a8ea29e 100644
> --- a/include/linux/reset-controller.h
> +++ b/include/linux/reset-controller.h
> @@ -61,6 +61,7 @@ struct reset_control_lookup {
> * @dev: corresponding driver model device struct
> * @of_node: corresponding device tree node as phandle target
> * @of_reset_n_cells: number of cells in reset line specifiers
> + * @cookie: for reset-gpios controllers: corresponding GPIO instead of of_node
> * @of_xlate: translation function to translate from specifier as found in the
> * device tree to id as given to the reset control ops, defaults
> * to :c:func:`of_reset_simple_xlate`.
> @@ -74,6 +75,7 @@ struct reset_controller_dev {
> struct device *dev;
> struct device_node *of_node;
> int of_reset_n_cells;
> + const void *cookie;
> int (*of_xlate)(struct reset_controller_dev *rcdev,
> const struct of_phandle_args *reset_spec);
> unsigned int nr_resets;
> --
> 2.34.1
>
I dislike this approach entirely. Here's what I would do:
In the reset core: parse the phandle of the reset-gpios property. Use
the resulting node with gpio_device_find_by_fwnode(). If the device is
not up yet, defer probe. You'll now have the GPIO device object.
Retrieve its label using gpio_device_get_label(). Now you should have
everything you need (the offset and flags of the GPIO you'll get from
__of_parse_phandle_with_args()) to set up the lookup tables. See
include/linux/gpio/machine.h. An example of that would be in:
bcm2835_spi_setup() in drivers/spi/spi-bcm2835.c.
Then with a lookup table in place, you instantiate your device and
it'll get its GPIO as it should. This is not ideal but much better
than the above.
Bartosz
Powered by blists - more mailing lists