Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 9月, 2014 3 次提交
  3. 01 9月, 2014 5 次提交
  5. 02 8月, 2014 4 次提交
  7. 01 8月, 2014 1 次提交
  9. 31 7月, 2014 1 次提交
  11. 30 7月, 2014 1 次提交
  13. 29 7月, 2014 1 次提交
    • T
      spi: orion: fix incorrect handling of cell-index DT property · e06871cd
      由 Thomas Petazzoni 提交于 
      In commit f814f9ac ("spi/orion: add device tree binding"), Device
Tree support was added to the spi-orion driver. However, this commit
reads the "cell-index" property, without taking into account the fact
that DT properties are big-endian encoded.

Since most of the platforms using spi-orion with DT have apparently
not used anything but cell-index = <0>, the problem was not
visible. But as soon as one starts using cell-index = <1>, the problem
becomes clearly visible, as the master->bus_num gets a wrong value
(actually it gets the value 0, which conflicts with the first bus that
has cell-index = <0>).

This commit fixes that by using of_property_read_u32() to read the
property value, which does the appropriate endianness conversion when
needed.

Fixes: f814f9ac ("spi/orion: add device tree binding")
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # v3.6+
      e06871cd
  15. 26 7月, 2014 5 次提交
  17. 18 7月, 2014 2 次提交
    • N
      spi: s3c64xx: use the generic SPI "cs-gpios" property · 306972ce
      由 Naveen Krishna Chatradhi 提交于 
      The s3c64xx SPI driver uses a custom DT binding to specify
the GPIO used to drive the chip select (CS) line instead of
using the generic "cs-gpios" property already defined in:
Documentation/devicetree/bindings/spi/spi-bus.txt.

It's unfortunate that drivers are not using standard bindings
and creating custom ones instead but in most cases this can't
be changed without breaking Device Tree backward compatibility.

But in the case of this driver, its DT binding has been broken
for more than a year. Since after commit (dated June, 21 2013):

3146beec ("spi: s3c64xx: Added provision for dedicated cs pin")

DT backward compatibility was broken and nobody noticed until
now when the commit was reverted. So it seems to be safe to
change the binding to use the standard SPI "cs-gpios" property
instead of using a custom one just for this driver.

This patch also allows boards that don't use a GPIO pin for the
CS to work with the driver since the SPI core will take care of
setting spi->cs_gpio to -ENOENT if a board wants to use the built
in CS instead of a GPIO as explained in the SPI bus DT binding:
Documentation/devicetree/bindings/spi/spi-bus.txt.

For non-DT platforms, spi->cs_gpio will be set to -ENOENT as well
unless they specify a GPIO pin in their platform data. So both
native and GPIO chip select is also supported for legacy boards.

The above use case was what motivated commit 3146beec which broke
the DT binding backward compatibility in the first place.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
[javier.martinez@collabora.co.uk: split changes and improve commit message]
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      306972ce
    • J
      spi: s3c64xx: Revert "spi: s3c64xx: Added provision for dedicated cs pin" · e2689b94
      由 Javier Martinez Canillas 提交于 
      This reverts commit 3146beec.

This commit resulted in a DT backward compatibility breakage.

Some devices use the native chip select (CS) instead of a GPIO
pin to drive the CS line. But the SPI driver made it mandatory
to specify a GPIO pin in the SPI device node controller-data.
So, using the built-in CS was not possible with the driver.

Commit 3146beec tried to fix that by adding a "cs-gpio" property
which could be defined in the SPI device node to make the driver
request the GPIO from the controller-data node.

Unfortunately that changed the old DT binding semantics since
now it's mandatory to have the "cs-gpio" property defined in
the SPI device node in order to use a GPIO pin to drive the CS.

As an example, a SPI device was defined before the commit with:

spi@12d20000 {
    slave-node@0 {
        controller-data {
             cs-gpio = <&gpb1 2 0>;
        }
   }
}

and after the commit, the following DTS snippet must be used:

spi@12d20000 {
    cs-gpio;
    slave-node@0 {
        controller-data {
             cs-gpio = <&gpb1 2 0>;
        }
   }
}

So, after commit 3146beec the driver does not look for the GPIO
by default and it only looks for it if the top level "cs-gpio"
property is defined while the default used to be the opposite.
To always request the GPIO defined in the controller-data node.

This means that old FDT that of course didn't have this added
"cs-gpio" DT property in the SPI node broke after this change.

The offending commit can't be reverted cleanly since more than
a year have passed and other changes were made in the meantime
but this patch partially reverts the driver to it's original
state so old FDT can work again.

This patch will break Device Trees that were relying on the new
behavior of course but the patch should be reverted because:

a) There aren't DTS in mainline that use this new property.
b) They were relying on a behavior that broke DT compatibility.
c) The new binding is awkard, needing two properties with the
   same name (cs-gpio) on different nodes is confusing at least.
d) The new property was not added to the DT binding doc:
   Documentation/devicetree/bindings/spi/spi-samsung.txt
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      e2689b94
  19. 17 7月, 2014 5 次提交
  21. 13 7月, 2014 1 次提交
  23. 11 7月, 2014 9 次提交
  25. 10 7月, 2014 2 次提交