Re: protected pins and debugfs

[Stephen Boyd]

Quoting Sodagudi Prasad (2018-10-16 19:00:45)
> On 2018-10-10 12:40, Sodagudi Prasad wrote:
> > On 2018-10-07 23:04, Stephen Boyd wrote:
> >> Quoting Sodagudi Prasad (2018-10-03 05:38:24)
> >>> 
> >>>          for (i = 0; i < chip->ngpio; i++, gpio++) {
> >>> +               label = gpiochip_is_requested(chip, i);
> >>> +               if (!label)
> >>> +                       continue;
> >>>                  msm_gpio_dbg_show_one(s, NULL, chip, i, gpio);
> >>> -               seq_puts(s, "\n");
> >>>          }
> >>>   }
> >>> 
> >> 
> >> Does something not work with the following code in
> >> msm_gpio_dbg_show_one()?
> >> 
> >> 
> >>         if (!gpiochip_line_is_valid(chip, offset))
> >>              return;
> > 
> > Hi Stephen,
> > I didnt realize that these changes are merged on tip. I was testing on
> > 4.14 kernel.
> > 
> > https://lore.kernel.org/patchwork/patch/878107/
> > https://lore.kernel.org/patchwork/patch/878106/
> > https://lore.kernel.org/patchwork/patch/878109/
> 
> 
> Hi Stephen,
> 
> After checking this further, adding "gpio-reserved-ranges" in not good 
> option. Because of the following reasons.
> 1) These gpio information changes from platform to platform. So need to 
> maintain reserved-range properly for each platform.

This was known. The best approach was to populate this based on what the
firmware chooses to lock down, which didn't seem to change very often
from what I recall being told.

> 2) Also some of the gpio can be changed to secure/protected gpio 
> dynamically based on the use case.

This is new information. How exactly do these pins change dynamically?
Perhaps gpiolib needs to gain more support for the mask to change at
runtime instead of being populated once at boot time from DT.  Seems
like a patch could be written for gpiolib to handle that if it really is
something that needs to be done.

> 
> It looks adding the "gpio-reserved-ranges" ranges is not good option for 
> most of the platforms.
> 
> Can you please check the initial patch suggested in this thread? Please 
> let me know if you have any other options for the above points.
> 

The initial patch in this thread takes a Qualcomm centric approach to
the problem, which probably works just fine, but we would like to push
the solution to problem into the core framework so that other SoCs can
benefit from common code. Please look into handling the runtime swapping
in the gpiolib core so that we don't have a one-off solution for
Qualcomm here.