linux-kernel - RE: [PATCH V3 5/9] spi: export spi core function spi_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR12MB3398D133D1C71355BC530754C2390@BYAPR12MB3398.namprd12.prod.outlook.com>
Date:   Mon, 29 Apr 2019 22:02:46 +0000
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Mark Brown <broonie@...nel.org>
CC:     "thierry.reding@...il.com" <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Timo Alho <talho@...dia.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "Krishna Yarlagadda" <kyarlagadda@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH V3 5/9] spi: export spi core function spi_set_cs

> On Mon, Apr 15, 2019 at 02:30:30PM -0700, Sowjanya Komatineni wrote:
> > This patch exports spi_set_cs of the spi core to allow SPI masters to 
> > use when gpio based chip select is needed.
>
> This isn't really what I meant when I said it'd be good to use the core GPIO code - this function doesn't do a huge amount really and the usage of it in your subsequent patch for the > driver isn't exactly joined up with the little it does (which is mainly swapping in the GPIO chip select instead of the hardware chip select) isn't used in your driver usage of this as far as I can see.  The bulk of the chip select handling code in the core is actually in transfer_one_message() which your driver doesn't use as it's got it's own implementation of that; I've not looked in enough detail to figure out if it could use it.
>
>
>
In SPI Tegra driver, we wanted to have GPIO based CS control when cs-gpios is specified in parallel to HW/SW CS. Having parallel GPIO based CS is to mimic some of the timing stuff that's needed for some spi devices by not actually using HW CS on platform but only for SPI HW design logic inside the chip.

Tegra spi driver don't use set_cs callback so looking into spi_set_cs from spi core implementation when cs-gpios property is used it exactly the same that is needed for GPIO control CS. So used this in V3. 

Can you please provide more details on what you are suggesting?
Do you prefer not to use SPI core spi_set_cs and gpio_set_values APIs and instead implement in tegra SPI driver using GPIO descriptors ?

Thanks
Sowjanya