[PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable

[Daniel Gutson]

On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson <daniel at eclypsium.com> wrote:
> > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote:
> >>
> >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote:
> >> > El sáb., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman <
> >> > gregkh at linuxfoundation.org> escribió:
> >> >
> >> >
> >> > 1) I just did the same that intel-spi.c does.
> >>
> >> No need to copy bad examples :)
> >
> >
> > Didn't know it was a bad example. What's is the current modern mechanism that replaces initialization-time configuration?
>
> I'd say you'd generally want this to be a per-instance setting, which
> could be a sysfs attribute of the physical device, or an ioctl for an
> existing user space abstraction.

But still, they are not equivalent. The initial configuration remains
constant for the rest of the life of the driver, whereas the
sysfs attribute is set after the initialization and can be re-set over
time. I'm not asking module parameters "to come back" if
they are now considered obsolete, I'm just trying to understand.

>
> In the changelog, you should also explain what this is used for. Do
> you actually want to write to a device that is marked read-only, or
> are you just trying to make the interface more consistent between the
> two drivers?

The device can either be locked or unlocked. If it is unlocked, it can
be set writable depending on the module
argument in intel-spi, or straight writable in intel-spi-pci. Which is
dangerous.
I wanted to make, as you say, the interface consistent.
Exposing an interface to the user (via a sysfs attribute) to try to
make the driver writable is definitively a bad idea.
I'd rather do nothing (no module arg) rather than open that
here-be-dragons door.
>
>      Arnd



-- 
Daniel Gutson
Argentina Site Director
Enginieering Director
Eclypsium

Below The Surface: Get the latest threat research and insights on
firmware and supply chain threats from the research team at Eclypsium.
https://eclypsium.com/research/#threatreport