[v2,0/3] Support qcom pinctrl protected pins

This patchset proposes a solution to describing the valid
pins for a pin controller in a semi-generic way so that qcom
platforms can expose the pins that are really available.

Typically, this has been done by having drivers and firmware 
descriptions only use pins they know they have access to, and that
still works now because we no longer read the pin direction at
boot. But there are still some userspace drivers and debugfs facilities
that don't know what pins are available and attempt to read everything
they can. On qcom platforms, this may lead to a system hang, which isn't 
very nice behavior, even if root is the only user that can trigger it.

The proposal is to describe the valid pins and then not allow things to
cause problems by using the invalid pins. Obviously, the firmware may
mess this up, so this is mostly a nice to have feature or a safety net
so that things don't blow up easily.

Changes from v1:
 * Pushed into gpiolib-of core under irq valid line logic
 * Fixed up qcom driver patch to free stuff properly and remove custom code
 * Dropped export patch as it got picked up
 * Renamed binding to 'reserved-gpio-ranges'

Stephen Boyd (3):
  dt-bindings: pinctrl: Add a reserved-gpio-ranges property
  gpiolib-of: Support 'reserved-gpio-ranges' property
  pinctrl: qcom: Don't allow protected pins to be requested

 Documentation/devicetree/bindings/gpio/gpio.txt |  7 +--
 drivers/gpio/gpiolib-of.c                       | 28 ++++++++++
 drivers/gpio/gpiolib.c                          |  9 ++++
 drivers/pinctrl/qcom/pinctrl-msm.c              | 69 +++++++++++++++++++++++--
 4 files changed, 106 insertions(+), 7 deletions(-)

On 01/25/2018 07:13 PM, Stephen Boyd wrote:
> This patchset proposes a solution to describing the valid
> pins for a pin controller in a semi-generic way so that qcom
> platforms can expose the pins that are really available.
> 
> Typically, this has been done by having drivers and firmware
> descriptions only use pins they know they have access to, and that
> still works now because we no longer read the pin direction at
> boot. But there are still some userspace drivers and debugfs facilities
> that don't know what pins are available and attempt to read everything
> they can. On qcom platforms, this may lead to a system hang, which isn't
> very nice behavior, even if root is the only user that can trigger it.

Any progress on this patch set?  Stephen no longer works for Qualcomm, 
so I don't know what the next step is, and I really want this feature in 
4.17 (we've missed so many merge windows already).

On Tue, Feb 20, 2018 at 5:45 PM, Timur Tabi <timur@codeaurora.org> wrote:
> On 01/25/2018 07:13 PM, Stephen Boyd wrote:
>>
>> This patchset proposes a solution to describing the valid
>> pins for a pin controller in a semi-generic way so that qcom
>> platforms can expose the pins that are really available.
>>
>> Typically, this has been done by having drivers and firmware
>> descriptions only use pins they know they have access to, and that
>> still works now because we no longer read the pin direction at
>> boot. But there are still some userspace drivers and debugfs facilities
>> that don't know what pins are available and attempt to read everything
>> they can. On qcom platforms, this may lead to a system hang, which isn't
>> very nice behavior, even if root is the only user that can trigger it.
>
> Any progress on this patch set?  Stephen no longer works for Qualcomm, so I
> don't know what the next step is, and I really want this feature in 4.17
> (we've missed so many merge windows already).

I depend on Bjorn as maintainer of the pin control driver to ACK
the solution he likes.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri 23 Feb 06:22 PST 2018, Linus Walleij wrote:

> On Tue, Feb 20, 2018 at 5:45 PM, Timur Tabi <timur@codeaurora.org> wrote:
> > On 01/25/2018 07:13 PM, Stephen Boyd wrote:
> >>
> >> This patchset proposes a solution to describing the valid
> >> pins for a pin controller in a semi-generic way so that qcom
> >> platforms can expose the pins that are really available.
> >>
> >> Typically, this has been done by having drivers and firmware
> >> descriptions only use pins they know they have access to, and that
> >> still works now because we no longer read the pin direction at
> >> boot. But there are still some userspace drivers and debugfs facilities
> >> that don't know what pins are available and attempt to read everything
> >> they can. On qcom platforms, this may lead to a system hang, which isn't
> >> very nice behavior, even if root is the only user that can trigger it.
> >
> > Any progress on this patch set?  Stephen no longer works for Qualcomm, so I
> > don't know what the next step is, and I really want this feature in 4.17
> > (we've missed so many merge windows already).
> 
> I depend on Bjorn as maintainer of the pin control driver to ACK
> the solution he likes.
> 

I haven't found the time to review the reuse of the irq valid mask or
the effort needed to replace this, other than that I think the series
looks good.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 02/23/2018 10:54 AM, Bjorn Andersson wrote:
> I haven't found the time to review the reuse of the irq valid mask or
> the effort needed to replace this, other than that I think the series
> looks good.

So is that an ACK?