Am 21.11.2015 um 00:22 schrieb Brian Norris: > On Fri, Nov 20, 2015 at 08:05:48PM +0100, Michal Suchanek wrote: >> On 20 November 2015 at 19:59, Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: >>> Am 20.11.2015 um 13:35 schrieb Mark Brown: >>>> On Fri, Nov 20, 2015 at 11:06:47AM +0100, Heiner Kallweit wrote: >>>>> If the discussed case is valid a clear hint to all users of spi_sync and >>>>> friends should be added that the caller can not rely on status code 0 >>>>> only but must check actual_length to verify that the complete message >>>>> was transferred. >>>> >>>> You'll get an error on truncation. It may be possible to recover. >>>> >>> OK, I interpret this as: >>> Controller drivers shall return 0 only if the complete message was >>> transferred successfully. >>> If a controller driver returns an error it has the option to set >>> actual_length to what was transferred successfully. >>> >>> This means we can't use patch 4 from Michal because it bails out as soon >>> as the underlying SPI transfer returns an error. > > Right (although you meant patch 7). > >>> Instead something like the spi-nor patch I sent on Oct 6th would be needed: >>> [PATCH] mtd: spi-nor: handle controller driver limitations in spi_nor_read > > I don't think your patch is good either... > >>> It loops over nor->read and ignores errors as long as at least something >>> was read. >>> >> >> I don't think ignoring errors in general is good idea. > > ...for this reason, at least. > >> If it's desirable that a partial transfer is reported as error then a >> particular error value should be defined for this case and drivers >> that can continue the transfer in a driver-specific way (such as >> spi-nor) can check for this error and handle it appropriately and pass >> through any other error. > > Based on Mark's further comments (and my own intuition), I'd rather not > try to interpret different error codes to mean "truncated but keep > going" vs. "truncated for other reason, stop now", unless we really have > to. > > I think if we do what Heiner was proposing from the beginning -- expose > a reasonable max SPI message length -- then I think we'll cover the bulk > of what we want. SPI NOR drivers can then try "small enough" transfers, > and if we see any errors, those are unexpected, and we abort. Based on what was discussed so far I'll submit a patch series as basis for further discussion. Heiner > > Sound OK? > > Brian > -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html