linux-kernel - Re: [PATCH] spi: pxa2xx: Only claim CS GPIOs when the slave device is created

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]

Date:   Mon, 24 Jul 2017 14:02:57 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jan Kiszka <jan.kiszka@....de>
Cc:     Daniel Mack <daniel@...que.org>,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Mark Brown <broonie@...nel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] spi: pxa2xx: Only claim CS GPIOs when the slave device is created

On Mon, Jul 24, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@....de> wrote:
> On 2017-07-24 12:44, Andy Shevchenko wrote:
>> +Cc: Mika
>>
>> On Sat, Jul 8, 2017 at 11:41 AM, Jan Kiszka <jan.kiszka@....de> wrote:
>>> From: Jan Kiszka <jan.kiszka@...mens.com>
>>>
>>> Avoid hogging chip select GPIOs just because they are listed for the
>>> master. They might be mulitplexed and, if no slave device is attached,
>>> used for different purposes. Moreover, this strategy avoids having to
>>> allocate a cs_gpiods structure.
>>>
>>> Tested on the IOT2000 where the second SPI bus is connected to an
>>> Arduino-compatible connector and multiplexed between SPI, GPIO and PWM
>>> usage.

>> This breaks all systems which are using _DSD.
>
> Err, can you elaborate? Worked fine here with _DSD on the IOT2000.

Sure, the setup() function can be called several times for the same
chip (as written in the comment inside the function).
Definitely your code doesn't follow this, since gpiod_get_index() is
returning -EBUSY when called 2+ time, that's what I got on all my
tests.

>> While I'm looking for fix, I get feeling that the approach itself is not right,
>>
>> So, for now I would vote for immediate revert and then rethink what we
>> can do here.
>
> I'm fine with reverting because the patch wasn't clean anyway (mixed old
> and new GPIO API) - aside from whatever you found in addition.

> I had an
> update pending but, as you are looking into this anyway, I'm sure your
> patches will be more holistic.

Please, send it as RFC, because it might have something we can use/re-use.

-- 
With Best Regards,
Andy Shevchenko