On Wed, Sep 03, 2025 at 12:41:48PM +0200, Bartosz Golaszewski wrote:
> On Wed, Sep 3, 2025 at 12:38 PM Andy Shevchenko
> <andriy.shevche...@intel.com> wrote:
> > On Wed, Sep 03, 2025 at 12:34:00PM +0200, Bartosz Golaszewski wrote:
> > > On Wed, Sep 3, 2025 at 12:22 PM Andy Shevchenko
> > > <andriy.shevche...@intel.com> wrote:
> > > > On Wed, Sep 03, 2025 at 09:33:34AM +0200, Bartosz Golaszewski wrote:
> > > > > On Tue, Sep 2, 2025 at 10:46 PM Andy Shevchenko
> > > > > <andy.shevche...@gmail.com> wrote:
> > > > > > On Tue, Sep 2, 2025 at 8:42 PM Bartosz Golaszewski <b...@bgdev.pl> 
> > > > > > wrote:
> > > > > > > On Tue, Sep 2, 2025 at 4:38 PM Andy Shevchenko
> > > > > > > <andriy.shevche...@intel.com> wrote:
> > > > > > > > On Tue, Sep 02, 2025 at 01:59:25PM +0200, Bartosz Golaszewski 
> > > > > > > > wrote:

...

> > > > > > > > > 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?
> 
> It wouldn't, we don't discriminate between user-space and in-kernel
> GPIO users. A function either is a GPIO or isn't. Can you point me to
> the driver you're thinking about or is this a purely speculative
> question?

The recovery mechanism is in I²C core and many drivers use that.
I'm not aware of Qualcomm drivers in particular. But mechanism is
in use in I²C DesignWare which is distributed a lot among platforms,
so using word 'purely' is incorrect, and word 'speculative' is a bit
strong, but you can think of the issue coming later on when somebody
does something like this.

The same applies to the in-band wakeup UART mechanism.

Which means that with this series we will relax it back anyway for
the above mentioned cases.

(Not sure, but SPI DesignWare requires programming SPI native chip selects even
 if the GPIO is used for that, this might have also some implications, but here
 it's for real 'purely speculative'.)

-- 
With Best Regards,
Andy Shevchenko



Reply via email to