10 Oct, 2018

1 commit

  • spidev will make a big fuss if a device tree node binds a device by
    using "spidev" as the node's compatible property.

    However, the logic for this isn't looking for "spidev" in the
    compatible, but rather checking that the device is NOT compatible with
    spidev's list of devices.

    This causes a false positive if a device not named "rohm,dh2228fv", etc.
    binds to spidev, even if a means other than putting "spidev" in the
    device tree was used. E.g., the sysfs driver_override attribute.

    Signed-off-by: Trent Piepho
    Reviewed-by: Jan Kundrát
    Tested-by: Jan Kundrát
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Trent Piepho
     

08 Oct, 2018

1 commit


09 Jul, 2017

1 commit


30 Jun, 2017

1 commit


14 May, 2017

2 commits

  • Use memdup_user() helper instead of open-coding to simplify the code.

    Signed-off-by: Geliang Tang
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geliang Tang
     
  • This removes an unused completion from spidev_sync.

    It was introduced in

    commit 25d5cb4b0375e ("spi: remove some spidev oops-on-rmmod paths")

    and it was no longer used after:

    commit 98d6f47958001 ("spi: spidev: use spi_sync instead of spi_async")

    Signed-off-by: Seraphime Kirkovski (Haapie)
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Seraphime Kirkovski
     

16 Mar, 2017

1 commit


21 Oct, 2016

1 commit

  • Entries are needed in the spidev ID list to configure configure it from a
    device tree. Add entry for the following device:
    - "ge,achc" : GE Healthcare USB Management Controller

    The USB Management Controller does not expose USB to the host, but acts as
    an offload engine, communicating with specific USB based data acquisition
    devices which are connected to it, extracting the required data and
    providing it to the host via other methods. SPI is used as an out-of-band
    configuration channel.

    Signed-off-by: Fabien Lahoudere
    Signed-off-by: Mark Brown

    Fabien Lahoudere
     

04 Jul, 2016

1 commit

  • Some IoT and maker software stacks are using spidev to perform raw access
    to the SPI bus instead of relying existing drivers provided by the kernel.
    They then implement their own "drivers" in userspace on top of the spidev
    raw interface. This is far from being an ideal solution but we do not want
    to prevent using mainline Linux in these devices.

    Now, it turns out that Windows has similar SPI devices than spidev which
    allow raw access on the SPI bus to userspace programs as described in the
    link below:

    https://msdn.microsoft.com/windows/hardware/drivers/spb/spi-tests-in-mitt

    These SPI test devices are also meant to be used during development and
    testing.

    In order to allow usage of spidev for development and testing in Linux, add
    those same ACPI IDs to the spidev driver (which is Linux counterpart of the
    Windows SPI test devices), but complain loudly so that users know it is not
    good idea to use it in production systems. Instead they should be using
    proper drivers for peripherals connected to the SPI bus.

    Signed-off-by: Mika Westerberg
    Signed-off-by: Mark Brown

    Mika Westerberg
     

12 Jan, 2016

1 commit


16 Dec, 2015

1 commit


30 Nov, 2015

1 commit


04 Nov, 2015

1 commit


28 Oct, 2015

1 commit


23 Sep, 2015

1 commit


11 Sep, 2015

1 commit

  • During the last close we are freeing spidev if spidev->spi is NULL, but
    just before checking if spidev->spi is NULL we are dereferencing it.
    Lets add a check there to avoid the NULL dereference.

    Fixes: 9169051617df ("spi: spidev: Don't mangle max_speed_hz in underlying spi device")
    Signed-off-by: Sudip Mukherjee
    Reviewed-by: Jarkko Nikula
    Tested-by: Jarkko Nikula
    Signed-off-by: Mark Brown

    Sudip Mukherjee
     

31 Aug, 2015

1 commit


05 Aug, 2015

1 commit


16 Jul, 2015

1 commit


07 Jul, 2015

1 commit

  • Since spidev is no more allowed to use in DT and is really loudly warned about
    it I'd like to add this compatible value.
    (Geert Uytterhoeven wrote: "Add the compatible value for your device to the
    spidev_dt_ids[] array in drivers/spi/spidev.c.")

    Signed-off-by: Mark Brown

    Jiri Prchal
     

18 Jun, 2015

1 commit


11 May, 2015

1 commit

  • Remove unneeded variable used to store return value.

    The semantic patch that makes this change is available
    in scripts/coccinelle/misc/returnvar.cocci.

    More information about semantic patching is available at
    http://coccinelle.lip6.fr/

    Signed-off-by: Fabio Estevam
    Signed-off-by: Mark Brown

    Fabio Estevam
     

23 Apr, 2015

1 commit


28 Mar, 2015

1 commit

  • Since spidev is a detail of how Linux controls a device rather than a
    description of the hardware in the system we should never have a node
    described as "spidev" in DT, any SPI device could be a spidev so this
    is just not a useful description.

    In order to help prevent users from writing such device trees generate a
    warning if spidev is instantiated as a DT node without an ID in the match
    table.

    Signed-off-by: Mark Brown

    Mark Brown
     

24 Mar, 2015

1 commit

  • `spidev_message()` sums the lengths of the individual SPI transfers to
    determine the overall SPI message length. It restricts the total
    length, returning an error if too long, but it does not check for
    arithmetic overflow. For example, if the SPI message consisted of two
    transfers and the first has a length of 10 and the second has a length
    of (__u32)(-1), the total length would be seen as 9, even though the
    second transfer is actually very long. If the second transfer specifies
    a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
    overrun the spidev's pre-allocated tx buffer before it reaches an
    invalid user memory address. Fix it by checking that neither the total
    nor the individual transfer lengths exceed the maximum allowed value.

    Thanks to Dan Carpenter for reporting the potential integer overflow.

    Signed-off-by: Ian Abbott
    Signed-off-by: Mark Brown

    Ian Abbott
     

24 Feb, 2015

1 commit

  • This patch changes the way space is reserved in spidev's pre-allocated
    TX and RX bounce buffers to avoid wasting space in the buffers for an
    SPI message consisting of multiple, half-duplex transfers in different
    directions.

    Background:

    spidev data structures have separate, pre-allocated TX and RX bounce
    buffers (`spidev->tx_buffer` and `spidev->rx_buffer`) of fixed size
    (`bufsiz`). The `SPI_IOC_MESSAGE(N)` ioctl processing uses a kernel
    copy of the N `struct spi_ioc_transfer` elements copied from the
    userspace ioctl arg pointer. In these elements: `.len` is the length of
    transfer in bytes; `.rx_buf` is either a userspace pointer to a buffer
    to copy the RX data to or is set to 0 to discard the data; and `.tx_buf`
    is either a userspace pointer to TX data supplied by the user or is set
    to 0 to transmit zeros for this transfer.

    `spidev_message()` uses the array of N `struct spi_ioc_transfer`
    elements to construct a kernel SPI message consisting of a `struct
    spi_message` containing a linked list (allocated as an array) of N
    `struct spi_transfer` elements. This involves iterating through the
    `struct spi_ioc_transfer` and `struct spi_transfer` elements (variables
    `u_tmp` and `k_tmp` respectively). Before the first iteration,
    variables `tx_buf` and `rx_buf` point to the start of the TX and RX
    bounce buffers `spidev->tx_buffer` and `spidev->rx_buffer` and variable
    `total` is set to 0. These variables keep track of the next available
    space in the bounce buffers and the total length of the SPI message.
    Each iteration checks that there is enough room left in the buffers for
    the transfer. If `u_tmp->rx_buf` is non-zero, `k_tmp->rx_buf` is set to
    `rx_buf`, otherwise it remains set to NULL. If `u_tmp->tx_buf` is
    non-zero, `k_tmp->tx_buf` is set to `tx_buf` and the userspace TX data
    copied there, otherwise it remains set to NULL. The variables `total`,
    `rx_buf` and `tx_buf` are advanced by the length of the transfer.

    The "problem":

    While iterating through the transfers, the local bounce buffer "free
    space" pointer variables `tx_buf` and `rx_buf` are always advanced by
    the length of the transfer. If `u_tmp->rx_buf` is 0 (so `k_tmp->rx_buf`
    is NULL), then `rx_buf` is advanced unnecessarily and that part of
    `spidev->rx_buffer` is wasted. Similarly, if `u_tmp->tx_buf` is 0 (so
    `k_tmp->tx_buf` is NULL), part of `spidev->tx_buffer` is wasted.

    What this patch does:

    To avoid wasting space unnecessarily in the RX bounce buffer, only
    advance `rx_buf` by the transfer length if `u_tmp->rx_buf` is non-zero.
    Similarly, to avoid wasting space unnecessarily in the TX bounce buffer,
    only advance `tx_buf` if `u_tmp->tx_buf is non-zero. To avoid pointer
    subtraction, use new variables `rx_total` and `tx_total` to keep track
    of the amount of space allocated in each of the bounce buffers. If
    these exceed the available space, a `-EMSGSIZE` error will be returned.

    Limit the total length of the transfers (tracked by variable `total`) to
    `INT_MAX` instead of `bufsiz`, returning an `-EMSGSIZE` error if
    exceeded. The total length is returned by `spidev_message()` on success
    and we want that to be non-negative. The message size limits for the
    `SPI_IOC_MESSAGE(N)` ioctl are now as follows:

    (a) total length of transfers is rx_buf` is non-zero. The variable `rx_buf` is again used to
    keep track of the corresponding positions in the bounce buffer. Now it
    is only advanced for those transfers that use the RX bounce buffer.

    Signed-off-by: Ian Abbott
    Signed-off-by: Mark Brown

    Ian Abbott
     

08 Feb, 2015

1 commit


03 Feb, 2015

1 commit

  • The SPI_IOC_MESSAGE(n) ioctl commands' argument points to an array of n
    struct spi_ioc_transfer elements. The spidev's compat_ioctl handler
    just converts this pointer and passes it on to the unlocked_ioctl
    handler to process it.

    The tx_buf and rx_buf members of struct spi_ioc_transfer are of type
    __u64 and hold pointer values. A 32-bit userspace application running
    in a 64-bit kernel might not have widened the 32-bit pointers correctly
    for the kernel. The application might have sign-extended the pointer to
    when the kernel expects it to be zero-extended, or vice versa, leading
    to an -EFAULT being returned by spidev_message() if the widened pointer
    is invalid.

    Handle the SPI_IOC_MESSAGE(n) ioctl commands specially in the
    compat_ioctl handler, calling new function spidev_compat_ioctl_message()
    to handle them. This processes them in the same way as the
    unlocked_ioctl handler except that it uses compat_ptr() to convert the
    tx_buf and rx_buf members of each struct spi_ioc_transfer element.

    To save code, factor out part of the unlocked_ioctl handler into a new
    function spidev_get_ioc_message(). This checks the ioctl command code
    is a valid SPI_IOC_MESSAGE(n), determines n and copies the array of n
    struct spi_ioc_transfer elements from userspace into dynamically
    allocated memory, returning either a pointer to the memory, an
    ERR_PTR(-err) value, or NULL (for SPI_IOC_MESSAGE(0)).

    Signed-off-by: Ian Abbott
    Signed-off-by: Mark Brown

    Ian Abbott
     

22 Dec, 2014

1 commit


12 Nov, 2014

1 commit

  • Currently spidev allows callers to set the default speed by overriding the
    max_speed_hz in the underlying device. This achieves the immediate goal but
    is not what devices expect and can easily lead to userspace trying to set
    unsupported speeds and succeeding, apart from anything else drivers can't
    set a limit on the speed using max_speed_hz as they'd expect and any other
    devices on the bus will be affected.

    Instead store the default speed in the spidev struct and fill this in on
    each transfer.

    Signed-off-by: Mark Brown

    Mark Brown
     

13 Oct, 2014

1 commit

  • By using separate TX and RX bounce buffers, we avoid potential cache
    flush and invalidation sequence issue that may be encountered when a
    single bounce buffer is shared between TX and RX

    Signed-off-by: Ray Jui
    Reviewed-by: JD (Jiandong) Zheng
    Signed-off-by: Mark Brown

    Ray Jui
     

27 Feb, 2014

2 commits

  • Add support for Dual/Quad SPI Transfers to the spidev API.
    As this uses SPI mode bits that don't fit in a single byte, two new
    ioctls (SPI_IOC_RD_MODE32 and SPI_IOC_WR_MODE32) are introduced.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • In commit f477b7fb13df2b843997559ff34e87d054ba6538 ("spi: DUAL and QUAD
    support"), spi_device.mode was enlarged from 8 to 16 bits.

    However, the spidev code still only saved 8 bits of data. If a spidev
    SPI_IOC_WR_MODE or SPI_IOC_WR_LSB_FIRST request failed, only the lower 8
    bits of the SPI mode were restored, inadvertently clearing the upper 8
    bits, possibly disabling Quad or Dual SPI transfers for the device.

    Save up to 32 bits to fix this.

    For SPI_IOC_WR_MODE this is probably not so important, as it doesn't allow
    setting Quad or Dual mode anyway, but SPI_IOC_WR_LSB_FIRST is used to just
    set or clear a single bit.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

15 Oct, 2013

1 commit


17 Sep, 2013

1 commit


15 Jul, 2013

1 commit


01 Apr, 2013

1 commit


08 Dec, 2012

1 commit

  • CONFIG_HOTPLUG is going away as an option. As result the __dev*
    markings will be going away.

    Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
    and __devexit.

    Bill Pemberton has done most of the legwork on this series. I've used
    his script to purge the attributes from the drivers/gpio tree.

    Reported-by: Bill Pemberton
    Signed-off-by: Grant Likely

    Grant Likely
     

01 Nov, 2012

2 commits