Re: [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 06, 2016 at 08:53:10PM +0200, Heiner Kallweit wrote:
> Am 06.06.2016 um 19:40 schrieb Mark Brown:

> > That doesn't make any sense, the controller hardware doesn't 
> > magically change based on what is connected to it.

> The issue with fsl-espi is that the controller deactivates CS after
> each physical transfer. And a lot of HW designs use the hardware CS,
> therefore the advise to use a GPIO instead doesn't really help.

There's no pinmux to fix the broken behaviour?  The Freescale SPI
controllers really are terrible :(

> In case of SPI NOR CS needs to stay active between command and data

In the case of *all* SPI transactions this needs to happen.  This is
*not* optional, it's not some weird requirement of NOR, it's one of the
most basic requirements for a SPI driver on Linux.

> Well, we could reduce the max_transfer_size exposed by the driver by
> the max length of a m25p80 read command in general.

No!  Apart from anything else this would be a complete and total
abstraction failure.  This is a driver for a SPI controller, not a
driver for a flash controller, which means that it should not have flash
specific hacks in it.

> Then we might be too strict for other SPI devices, but this may
> be acceptable as the current fsl-espi driver is usable with SPI NOR
> devices only anyway.

What makes you say this?  I'm guessing that the driver is just broken
but it would be good to understand the specifics.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux