All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Gutson <daniel@eclypsium.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.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>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable
Date: Mon, 24 Aug 2020 12:15:42 +0300	[thread overview]
Message-ID: <20200824091542.GC1375436@lahna.fi.intel.com> (raw)
In-Reply-To: <CAK8P3a0==cZDHwZfqvCuvUg9jfjBOBG+AAomE9eqJ2xm-xNLvQ@mail.gmail.com>

On Mon, Aug 24, 2020 at 11:08:33AM +0200, Arnd Bergmann wrote:
> On Mon, Aug 24, 2020 at 10:22 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > On Sat, Aug 22, 2020 at 06:06:03PM +0200, Arnd Bergmann wrote:
> > > On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg
> > >
> > > The mtd core just checks both the permissions on the device node (which
> > > default to 0600 without any special udev rules) and the MTD_WRITEABLE
> > > on the underlying device that is controlled by the module parameter
> > > in case of intel-spi{,-platform,-pci}.c.
> >
> > OK, thanks.
> >
> > Since we cannot really get rid of the module parameter (AFAIK there are
> > users for it), I still think we should just make the "writeable" to
> > apply to the PCI part as well. That should at least make it consistent,
> > and it also solves Daniel's case.
> 
> Can you explain Daniel's case then? I still don't understand what he
> actually wants.
> 
> As I keep repeating, the module parameter *does* apply to the pci
> driver front-end since it determines whether the driver will disallow
> writes to the mtd device without it. The only difference is that the pci
> driver will attempt to set the hardware bit without checking the
> module parameter first, while the platform driver does not. If the
> module parameter is not set however, the state of the hardware
> bit is never checked again.

I think Daniel wants the PCI driver not to set the hardware bit by
default (same as the platform driver).

WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Richard Hughes <hughsient@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Daniel Gutson <daniel@eclypsium.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Alex Bazhaniuk <alex@eclypsium.com>
Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable
Date: Mon, 24 Aug 2020 12:15:42 +0300	[thread overview]
Message-ID: <20200824091542.GC1375436@lahna.fi.intel.com> (raw)
In-Reply-To: <CAK8P3a0==cZDHwZfqvCuvUg9jfjBOBG+AAomE9eqJ2xm-xNLvQ@mail.gmail.com>

On Mon, Aug 24, 2020 at 11:08:33AM +0200, Arnd Bergmann wrote:
> On Mon, Aug 24, 2020 at 10:22 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > On Sat, Aug 22, 2020 at 06:06:03PM +0200, Arnd Bergmann wrote:
> > > On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg
> > >
> > > The mtd core just checks both the permissions on the device node (which
> > > default to 0600 without any special udev rules) and the MTD_WRITEABLE
> > > on the underlying device that is controlled by the module parameter
> > > in case of intel-spi{,-platform,-pci}.c.
> >
> > OK, thanks.
> >
> > Since we cannot really get rid of the module parameter (AFAIK there are
> > users for it), I still think we should just make the "writeable" to
> > apply to the PCI part as well. That should at least make it consistent,
> > and it also solves Daniel's case.
> 
> Can you explain Daniel's case then? I still don't understand what he
> actually wants.
> 
> As I keep repeating, the module parameter *does* apply to the pci
> driver front-end since it determines whether the driver will disallow
> writes to the mtd device without it. The only difference is that the pci
> driver will attempt to set the hardware bit without checking the
> module parameter first, while the platform driver does not. If the
> module parameter is not set however, the state of the hardware
> bit is never checked again.

I think Daniel wants the PCI driver not to set the hardware bit by
default (same as the platform driver).

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

  reply	other threads:[~2020-08-24  9:16 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04 13:58 [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable Daniel Gutson
2020-08-04 13:58 ` Daniel Gutson
2020-08-04 14:08 ` Mika Westerberg
2020-08-04 14:08   ` Mika Westerberg
2020-08-04 15:21 ` Arnd Bergmann
2020-08-04 15:21   ` Arnd Bergmann
     [not found]   ` <CAFmMkTHEm8k+5GZkVJbDZMEhMwpsqVKRb-hGskSpBstdLRuFyA@mail.gmail.com>
2020-08-04 19:06     ` Arnd Bergmann
2020-08-04 19:06       ` Arnd Bergmann
2020-08-04 19:57       ` Daniel Gutson
2020-08-04 19:57         ` Daniel Gutson
2020-08-04 20:46         ` Arnd Bergmann
2020-08-04 20:46           ` Arnd Bergmann
2020-08-04 21:26           ` Daniel Gutson
2020-08-04 21:26             ` Daniel Gutson
2020-08-12 15:41             ` Daniel Gutson
2020-08-12 15:41               ` Daniel Gutson
2020-08-13  9:01               ` Greg Kroah-Hartman
2020-08-13  9:01                 ` Greg Kroah-Hartman
     [not found]                 ` <CAFmMkTFgjW+9gNfx=2SU7B0foww=SLiiyVi+P-hZpEFDbMTf2Q@mail.gmail.com>
2020-08-13 11:47                   ` Greg Kroah-Hartman
2020-08-13 11:47                     ` Greg Kroah-Hartman
2020-08-13 15:41             ` Arnd Bergmann
2020-08-13 15:41               ` Arnd Bergmann
2020-08-13 21:40               ` Daniel Gutson
2020-08-13 21:40                 ` Daniel Gutson
2020-08-16  8:41                 ` Arnd Bergmann
2020-08-16  8:41                   ` Arnd Bergmann
2020-08-18 15:55                   ` Daniel Gutson
2020-08-18 15:55                     ` Daniel Gutson
2020-08-19  6:57                     ` Mika Westerberg
2020-08-19  6:57                       ` Mika Westerberg
2020-08-19  8:38                       ` Arnd Bergmann
2020-08-19  8:38                         ` Arnd Bergmann
2020-08-19  9:11                         ` Mika Westerberg
2020-08-19  9:11                           ` Mika Westerberg
2020-08-22 16:06                           ` Arnd Bergmann
2020-08-22 16:06                             ` Arnd Bergmann
2020-08-24  8:22                             ` Mika Westerberg
2020-08-24  8:22                               ` Mika Westerberg
2020-08-24  9:08                               ` Arnd Bergmann
2020-08-24  9:08                                 ` Arnd Bergmann
2020-08-24  9:15                                 ` Mika Westerberg [this message]
2020-08-24  9:15                                   ` Mika Westerberg
2020-08-24  9:31                                   ` Arnd Bergmann
2020-08-24  9:31                                     ` Arnd Bergmann
2020-08-24  9:44                                     ` Mika Westerberg
2020-08-24  9:44                                       ` Mika Westerberg
2020-08-24 16:00                                       ` Daniel Gutson
2020-08-24 16:00                                         ` Daniel Gutson
2020-08-19  9:19                         ` David Laight
2020-08-19  9:19                           ` David Laight

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=20200824091542.GC1375436@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=alex@eclypsium.com \
    --cc=arnd@arndb.de \
    --cc=bbrezillon@kernel.org \
    --cc=daniel@eclypsium.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughsient@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --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.