On Thu, Jan 10, 2019 at 4:52 PM Janek Kotas <jank@xxxxxxxxxxx> wrote: > >> However, the chip select signal is inverted. > >> The moment the SPI HW is initialized it goes low. > >> It is driven high during SPI transmissions. > > > > Ouch! Which device tree file is this? > > I’m using a custom one for out test system. > Here’s the SPI part: > > spi0: spi@fd0b0000 { > compatible = "cdns,spi-r1p6"; > reg = <0x0 0xfd0b0000 0x0 0x1000>; > clock-names = "ref_clk", "pclk"; > clocks = <&sysclock>, <&sysclock>; > interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>; > interrupt-parent = <&gic>; > num-cs = <4>; > is-decoded-cs = <0>; > #address-cells = <1>; > #size-cells = <0>; > > eeprom@0 { > compatible = "at,at25"; > reg = <0>; > spi-max-frequency = <10000000>; > /* spi-cpha; */ > /* spi-cpol; */ > pagesize = <16>; > size = <1024>; > address-width = <16>; > }; > }; Ah! You're using native chip selects! And now I enforce CS as high, and that will not just affect the GPIO CS but also the native CS. How sloppy of me. I will send a separate patch for that that you can test toghether with the first patch (which I think is fine in itself). > > My intention was that of_gpio_flags_quirks() in > > drivers/gpio/gpiolib-of.c would activate and you would > > get a print like this in dmesg: > > > > of_gpio_flags_quirks: enforce active low on chipselect handle > > I haven’t seen that in my logs. Not strange as you're not using GPIOs. Yours, Linus Walleij