From: Brian Norris <computersforpeace@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Michal Suchanek <hramrach@gmail.com>,
MTD Maling List <linux-mtd@lists.infradead.org>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
Marek Vasut <marex@denx.de>, Han Xu <han.xu@nxp.com>,
linux-spi@vger.kernel.org
Subject: Re: [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading
Date: Mon, 6 Jun 2016 11:43:48 -0700 [thread overview]
Message-ID: <20160606184348.GA135086@google.com> (raw)
In-Reply-To: <20160606183426.GJ7510@sirena.org.uk>
On Mon, Jun 06, 2016 at 07:34:26PM +0100, Mark Brown wrote:
> On Mon, Jun 06, 2016 at 11:28:03AM -0700, Brian Norris wrote:
> > On Mon, Jun 06, 2016 at 06:40:03PM +0100, Mark Brown wrote:
> > > On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote:
>
> > > > I'd like to come back to this discussion. You said best would be to fix
> > > > the chip driver. To do this and calculate an appropriate value for
> > > > max_transfer_size the chip driver would have to know that the spi_device
> > > > is a spi-nor device.
>
> > > That doesn't make any sense, the controller hardware doesn't magically
> > > change based on what is connected to it.
>
> > I believe Heiner has an (unstated here, but stated elsewhere?)
> > assumption that his driver has a maximum *message* size, not *transfer*
> > size. So he's explaining how to work around that by implicitly figuring
> > out what the message size would be based on a transfer size, I think.
>
> That still wouldn't explain how this could depend on the connected
> device, the message size isn't going to change any more than the
> transfer size is.
Ah, well I bet Heiner's mostly just testing flash (m25p80) and/or m25p80
is one of the bigger stressors.
Anyway, you're definitely correct that Heiner's suggested approach is
not good. He's essentially implying his driver should be intuiting the
message size / transfer size patterns for arbitrary users. I suppose we
really just need to figure out what his actual problem is, so we can
address it generically.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Heiner Kallweit
<hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Michal Suchanek
<hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
MTD Maling List
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Cyrille Pitchen
<cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>,
Han Xu <han.xu-3arQi8VN3Tc@public.gmane.org>,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading
Date: Mon, 6 Jun 2016 11:43:48 -0700 [thread overview]
Message-ID: <20160606184348.GA135086@google.com> (raw)
In-Reply-To: <20160606183426.GJ7510-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Mon, Jun 06, 2016 at 07:34:26PM +0100, Mark Brown wrote:
> On Mon, Jun 06, 2016 at 11:28:03AM -0700, Brian Norris wrote:
> > On Mon, Jun 06, 2016 at 06:40:03PM +0100, Mark Brown wrote:
> > > On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote:
>
> > > > I'd like to come back to this discussion. You said best would be to fix
> > > > the chip driver. To do this and calculate an appropriate value for
> > > > max_transfer_size the chip driver would have to know that the spi_device
> > > > is a spi-nor device.
>
> > > That doesn't make any sense, the controller hardware doesn't magically
> > > change based on what is connected to it.
>
> > I believe Heiner has an (unstated here, but stated elsewhere?)
> > assumption that his driver has a maximum *message* size, not *transfer*
> > size. So he's explaining how to work around that by implicitly figuring
> > out what the message size would be based on a transfer size, I think.
>
> That still wouldn't explain how this could depend on the connected
> device, the message size isn't going to change any more than the
> transfer size is.
Ah, well I bet Heiner's mostly just testing flash (m25p80) and/or m25p80
is one of the bigger stressors.
Anyway, you're definitely correct that Heiner's suggested approach is
not good. He's essentially implying his driver should be intuiting the
message size / transfer size patterns for arbitrary users. I suppose we
really just need to figure out what his actual problem is, so we can
address it generically.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-06-06 18:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-27 22:50 [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading Heiner Kallweit
2016-04-05 19:39 ` Brian Norris
2016-04-05 20:08 ` Heiner Kallweit
2016-04-05 21:07 ` Brian Norris
2016-04-07 19:09 ` Heiner Kallweit
2016-05-05 23:57 ` Brian Norris
2016-05-05 23:57 ` Brian Norris
2016-05-06 12:14 ` Mark Brown
2016-05-06 12:14 ` Mark Brown
2016-06-03 22:22 ` Heiner Kallweit
2016-06-03 22:22 ` Heiner Kallweit
2016-06-06 17:40 ` Mark Brown
2016-06-06 17:40 ` Mark Brown
2016-06-06 18:28 ` Brian Norris
2016-06-06 18:28 ` Brian Norris
2016-06-06 18:34 ` Mark Brown
2016-06-06 18:34 ` Mark Brown
2016-06-06 18:43 ` Brian Norris [this message]
2016-06-06 18:43 ` Brian Norris
2016-06-06 18:48 ` Mark Brown
2016-06-06 18:48 ` Mark Brown
2016-06-06 18:53 ` Heiner Kallweit
2016-06-06 18:53 ` Heiner Kallweit
2016-06-06 19:40 ` Michal Suchanek
2016-06-06 19:40 ` Michal Suchanek
2016-06-06 21:02 ` Heiner Kallweit
2016-06-06 21:02 ` Heiner Kallweit
2016-06-06 19:46 ` Geert Uytterhoeven
2016-06-06 19:46 ` Geert Uytterhoeven
2016-06-06 21:20 ` Heiner Kallweit
2016-06-06 21:20 ` Heiner Kallweit
2016-06-06 22:28 ` Marek Vasut
2016-06-06 22:28 ` Marek Vasut
2016-06-07 4:52 ` Heiner Kallweit
2016-06-07 4:52 ` Heiner Kallweit
2016-06-06 23:07 ` Mark Brown
2016-06-06 23:07 ` Mark Brown
2016-06-07 6:03 ` Heiner Kallweit
2016-06-07 6:03 ` Heiner Kallweit
2016-06-07 8:10 ` Michal Suchanek
2016-06-07 8:10 ` Michal Suchanek
2016-06-07 20:42 ` Heiner Kallweit
2016-06-07 20:42 ` Heiner Kallweit
2016-06-08 19:51 ` Heiner Kallweit
2016-06-08 19:51 ` Heiner Kallweit
2016-06-09 7:12 ` Michal Suchanek
2016-06-09 7:12 ` Michal Suchanek
2016-06-17 20:13 ` Heiner Kallweit
2016-06-17 20:13 ` Heiner Kallweit
2016-04-06 13:55 ` Cyrille Pitchen
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=20160606184348.GA135086@google.com \
--to=computersforpeace@gmail.com \
--cc=broonie@kernel.org \
--cc=cyrille.pitchen@atmel.com \
--cc=han.xu@nxp.com \
--cc=hkallweit1@gmail.com \
--cc=hramrach@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=marex@denx.de \
/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.