On Wed, Sep 03, 2025 at 12:34:00PM +0200, Bartosz Golaszewski wrote:

On Wed, Sep 3, 2025 at 12:22 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Wed, Sep 03, 2025 at 09:33:34AM +0200, Bartosz Golaszewski wrote:

quoted

On Tue, Sep 2, 2025 at 10:46 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Tue, Sep 2, 2025 at 8:42 PM Bartosz Golaszewski [off-list ref] wrote:

quoted

On Tue, Sep 2, 2025 at 4:38 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Tue, Sep 02, 2025 at 01:59:25PM +0200, Bartosz Golaszewski wrote:

...

quoted

quoted

quoted

quoted

quoted

quoted

The strict flag in struct pinmux_ops disallows the usage of the same pin
as a GPIO and for another function. Without it, a rouge user-space
process with enough privileges (or even a buggy driver) can request a
used pin as GPIO and drive it, potentially confusing devices or even
crashing the system. Set it globally for all pinctrl-msm users.

How does this keep (or allow) I²C generic recovery mechanism to work?

Anyway, what is your point? I don't think it has any impact on this.

If we have a group of pins that are marked as I²C, and we want to use recovery
via GPIOs, would it be still possible to request as GPIO when controller driver
is in the strict mode?

Yes, if you mark that function as a "GPIO" function in the pin
controller driver.

How would it prevent from requesting from user space?

-- 
With Best Regards,
Andy Shevchenko