All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Gutson <daniel@eclypsium.com>
Cc: Richard Hughes <hughsient@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	Boris Brezillon <bbrezillon@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Alex Bazhaniuk <alex@eclypsium.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable
Date: Thu, 30 Jul 2020 07:31:08 +0200	[thread overview]
Message-ID: <20200730053108.GA3861609@kroah.com> (raw)
In-Reply-To: <CAFmMkTEO7VNKJeYz2uoHsS-yN_aY8UuiQ2GcCq9NyAD5481ZGA@mail.gmail.com>

On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote:
> On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson <daniel@eclypsium.com> wrote:
> >
> > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson <daniel@eclypsium.com> wrote:
> > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman <gregkh@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@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.
> 
> ping.
> This is a real existing problem that I'm trying to address.
> There's currently no way to prevent the kernel to try to turn
> the SPI flash chip writable for the device IDs handled by
> intel-spi-pci. And allowing userspace to switch it between
> writable/non-writable is not an option.
> What other mechanism can I use other than the module parameter,

Again, module parameters are working on a per-chunk-of-code basis, while
you want to work on a per-device basis, which is why you should not use
a module parameter.

good luck!

greg k-h

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Gutson <daniel@eclypsium.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alex Bazhaniuk <alex@eclypsium.com>,
	Richard Hughes <hughsient@gmail.com>
Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable
Date: Thu, 30 Jul 2020 07:31:08 +0200	[thread overview]
Message-ID: <20200730053108.GA3861609@kroah.com> (raw)
In-Reply-To: <CAFmMkTEO7VNKJeYz2uoHsS-yN_aY8UuiQ2GcCq9NyAD5481ZGA@mail.gmail.com>

On Wed, Jul 29, 2020 at 05:54:35PM -0300, Daniel Gutson wrote:
> On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson <daniel@eclypsium.com> wrote:
> >
> > On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson <daniel@eclypsium.com> wrote:
> > > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman <gregkh@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@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.
> 
> ping.
> This is a real existing problem that I'm trying to address.
> There's currently no way to prevent the kernel to try to turn
> the SPI flash chip writable for the device IDs handled by
> intel-spi-pci. And allowing userspace to switch it between
> writable/non-writable is not an option.
> What other mechanism can I use other than the module parameter,

Again, module parameters are working on a per-chunk-of-code basis, while
you want to work on a per-device basis, which is why you should not use
a module parameter.

good luck!

greg k-h

  reply	other threads:[~2020-07-30  5:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 21:28 [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable Daniel Gutson
2020-07-24 21:28 ` Daniel Gutson
2020-07-25  5:56 ` Greg Kroah-Hartman
2020-07-25  5:56   ` Greg Kroah-Hartman
     [not found]   ` <CAFmMkTE_dT9+WJYyb19uQ_HmgJWZSARBy6PveheQJk++NuGbkQ@mail.gmail.com>
2020-07-26  7:17     ` Greg Kroah-Hartman
2020-07-26  7:17       ` Greg Kroah-Hartman
     [not found]       ` <CAFmMkTFzGfFDrJrdgHztzLK2K-zBWy6T2Tv+G4-rrbVpbahkgg@mail.gmail.com>
2020-07-27 15:15         ` Arnd Bergmann
2020-07-27 15:15           ` Arnd Bergmann
2020-07-27 15:31           ` Daniel Gutson
2020-07-27 15:31             ` Daniel Gutson
2020-07-29 20:54             ` Daniel Gutson
2020-07-29 20:54               ` Daniel Gutson
2020-07-30  5:31               ` Greg Kroah-Hartman [this message]
2020-07-30  5:31                 ` Greg Kroah-Hartman
     [not found]                 ` <CAFmMkTHXjfG7zMr0i_h65PvjAe4opPgvzdABH8W1EUGOmcA4Zg@mail.gmail.com>
2020-07-30 14:09                   ` Arnd Bergmann
2020-07-30 14:09                     ` Arnd Bergmann
2020-07-30 14:18                     ` Daniel Gutson
2020-07-30 14:18                       ` Daniel Gutson
2020-07-30 14:20                       ` Daniel Gutson
2020-07-30 14:20                         ` Daniel Gutson
2020-08-03  9:57 ` Mika Westerberg
2020-08-03  9:57   ` Mika Westerberg
2020-08-03 10:18   ` Richard Hughes
2020-08-03 10:18     ` Richard Hughes
2020-08-03 10:27     ` Mika Westerberg
2020-08-03 10:27       ` Mika Westerberg
2020-08-03 12:58       ` Daniel Gutson
2020-08-03 12:58         ` Daniel Gutson
2020-08-03 13:05         ` Mika Westerberg
2020-08-03 13:05           ` Mika Westerberg
2020-08-03 13:17           ` Daniel Gutson
2020-08-03 13:17             ` Daniel Gutson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200730053108.GA3861609@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alex@eclypsium.com \
    --cc=arnd@arndb.de \
    --cc=bbrezillon@kernel.org \
    --cc=daniel@eclypsium.com \
    --cc=hughsient@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@microchip.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.