Re: [ECOS] Semantics of cyg_spi_transaction_tick?

[Chris Holgate <chris at zynaptic dot com>]

Bart Veer wrote:
>>>>>> "Stanislav" == Stanislav Meduna <stano@meduna.org> writes:
> 
>     Stanislav> Hi,
>     Stanislav> the docs state that
> 
>     Stanislav>   If the device requires additional clock ticks in the
>     Stanislav>   middle of a transaction without being selected,
>     Stanislav>   cyg_spi_transaction_tick can be used. This will drop
>     Stanislav>   the device's chip select if necessary, then generate
>     Stanislav>   the appropriate number of ticks. The arguments are
>     Stanislav>   the same as for cyg_spi_tick.
> 
>     Stanislav> This does not correspond to what the present SPI
>     Stanislav> drivers do; they state that they do not touch the chip
>     Stanislav> select.
> 
> I am not sure which existing SPI drivers you are referring to. The
> documentation is correct: a tick means clock signals with no device
> selected. If a device is currently selected as part of a transaction,
> the chip select should be deasserted first. The tick functionality was
> incorporated into the API because of MMC cards, where the protocol
> requires clock ticks on the SPI bus with no data being transferred.

As far as I can tell, all the SPI drivers in the public CVS have this
behaviour.  Certainly the AT91 does because I used it as a reference
when implementing the STM32 one.  I think the same is also true for the
LPC driver.  From the AT91 comments for the tick function:

    // Transfer count zeros to the device - we don't touch the
    // chip select, the device could be selected or deselected.
    // It is up to the device driver to decide in wich state the
    // device will be ticked.

If this is incorrect it looks as though some patches are required.

>     Stanislav> From what I read in the code I can throw the unused
>     Stanislav> data using cyg_spi_transaction_tick (which does not
>     Stanislav> touch the CS) and rely on cyg_spi_transaction_end to
>     Stanislav> deassert the CS; however, this does not correspond with
>     Stanislav> the documentation. Can I rely on what the code does, or
>     Stanislav> is it possible that another SPI driver implements it
>     Stanislav> another way?
> 
> In theory the correct way to handle this is to use
> cyg_spi_transaction_transfer() with NULL arguments for both RX and TX
> buffers. In other words you transfer data to/from the current data
> device, but you do not care what data gets sent to the device and any
> data coming from the device should be discarded. I do not know if all
> current drivers handle this correctly.

I think that both the AT91 and STM32 drivers will behave correctly here
- although a quick look at the AT91 code suggests that it will send
invalid data starting from address 0.  This could be considered a
security issue in that it gives an attacker visibility of the contents
of the ARM exception jump table.

Chris.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss