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
