On Mon, Mar 13, 2017 at 09:26:04PM +0100, Adrian Fiergolski wrote: > On 13.03.2017 at 20:57, Geert Uytterhoeven wrote: > > On Mon, Mar 13, 2017 at 7:12 PM, Adrian Fiergolski d > >>> I can't see any way in which it follows from the above that it's a good > >>> idea to try to override bits per word settings in the device tree, that > >>> just wastes user time and is an abstraction failure. We need better > >>> handling of defaults done purely in the kernel. > >> If enforcing by device tree specific for a given device driver SPI_CPHA, > >> SPIC_CPOL, SPI_CS_HIGH, max_speed_hz, etc. if fine form the abstraction > >> point of view, why it doesn't apply to bits_per_word ? > > Because unlike polarity, phase, and speed, bits_per_word is a property > > of the communication protocol. > > E.g. you can talk to the same EEPROM using different polarities, phase, or > > speed, but bits_per_word is fixed. > In this case, currently, what is the proper way to handle SPI > controllers (spi-xilinx) without 8-bit transmission support ? As I said above we should fix the handling of defaults such that it is possible to instantiate a 16 bit using device on a 16 bit supporting controller; there should be no need to have anything about device tree in this.
Attachment:
signature.asc
Description: PGP signature
