Message ID | 20180126011400.2191-1-sboyd@codeaurora.org |
---|---|
Headers | show |
Series | Support qcom pinctrl protected pins | expand |
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?