On Mon, Nov 14, 2022 at 03:29:43PM -0500, Brian Masney wrote:
> Note that this is a RFC patch and not meant to be merged. I looked into
> a problem with linux-next-20221110 on the Qualcomm SA8540P automotive
> board (sc8280xp) where the UFS host controller would fail to probe due
> to repeated probe deferrals when trying to get reset-gpios via
> devm_gpiod_get_optional().
>
> of_get_named_gpiod_flags() returns -EPROBE_DEFER, which is caused by
> of_gpiochip_match_node_and_xlate() returning 0 since the of_xlate function
> pointer is not set for the qcom,sc8280xp-tlmm pinctrl driver. The
> pinctrl driver doesn't define one, so of_gpiochip_add() should
> automatically setup of_gpio_simple_xlate() on it's behalf. This doesn't
> happen since the fwnode member on the struct gpiochip is set to null
> when of_gpiochip_add() is called. Let's work around this by ensuring
> that it's set if available.
>
> Note that this broke sometime within the last few weeks within
> linux-next and I haven't bisected this. I'm posting this in the hopes
> that someone may know offhand which patch(es) may have broken this.
>
> Signed-off-by: Brian Masney <bmasney@xxxxxxxxxx>
> ---
> drivers/gpio/gpiolib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 11fb7ec883e9..8bec66008869 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -678,7 +678,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> * Assign fwnode depending on the result of the previous calls,
> * if none of them succeed, assign it to the parent's one.
> */
> - gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode;
> + gc->fwnode = gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode;
This doesn't look right to me. Looking at the documentation of
gc->fwnode and how it is used, the purpose of this is to allow
explicitly overriding the fwnode that the GPIO chip will use.
So really this should not be used beyond the initial registration
in gpiochip_add_data_with_key(). If the above patch fixes anything,
then I suspect somebody is using gc->fwnode outside of this
registration.
Looking at gpiolib, the only remaining place that seems to do this is
the gpio-reserved-ranges handling code, in which case, the below on top
of my initial patch might fix that. That might explain why MSM is still
seeing issues.
--- >8 ---
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 11fb7ec883e9..d692ad5c5a27 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -447,10 +447,11 @@ static unsigned long *gpiochip_allocate_mask(struct gpio_chip *gc)
static unsigned int gpiochip_count_reserved_ranges(struct gpio_chip *gc)
{
+ struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev);
int size;
/* Format is "start, count, ..." */
- size = fwnode_property_count_u32(gc->fwnode, "gpio-reserved-ranges");
+ size = fwnode_property_count_u32(fwnode, "gpio-reserved-ranges");
if (size > 0 && size % 2 == 0)
return size;
@@ -471,6 +472,7 @@ static int gpiochip_alloc_valid_mask(struct gpio_chip *gc)
static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
{
+ struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev);
unsigned int size;
u32 *ranges;
int ret;
@@ -483,7 +485,7 @@ static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc)
if (!ranges)
return -ENOMEM;
- ret = fwnode_property_read_u32_array(gc->fwnode, "gpio-reserved-ranges", ranges, size);
+ ret = fwnode_property_read_u32_array(fwnode, "gpio-reserved-ranges", ranges, size);
if (ret) {
kfree(ranges);
return ret;
--- >8 ---
I don't have a good idea about the Lenovo X13 issue, though, but I
haven't looked at ACPI at all since I don't have any hardware to test
on.
Thierry
Attachment:
signature.asc
Description: PGP signature
