linux-kernel - Re: [PATCH v2 3/6] spi: dw: Add Microchip Sparx5 support

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-next>] [day] [month] [year] [list]

Message-ID: <878sgddh2l.fsf@soft-dev15.microsemi.net>
Date:   Tue, 23 Jun 2020 15:53:22 +0200
From:   Lars Povlsen <lars.povlsen@...rochip.com>
To:     Mark Brown <broonie@...nel.org>
CC:     Lars Povlsen <lars.povlsen@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        <linux-spi@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Serge Semin <fancer.lancer@...il.com>,
        Serge Semin <Sergey.Semin@...kalelectronics.ru>
Subject: Re: [PATCH v2 3/6] spi: dw: Add Microchip Sparx5 support


Mark Brown writes:

On Mon, Jun 22, 2020 at 12:46:33PM +0200, Lars Povlsen wrote:
>> On Fri, Jun 19, 2020 at 01:31:18PM +0200, Lars Povlsen wrote:
>
>> >> +	if (!nEnable) {
>> >> +		/* Ensure CS toggles, so start off all disabled */
>> >> +		regmap_write(dwsmscc->syscon, SPARX5_FORCE_VAL, ~0);
>> >> +		/* CS override drive enable */
>> >> +		regmap_write(dwsmscc->syscon, SPARX5_FORCE_ENA, 1);
>
>> >This should just be setting the value to whatever the core asked for it
>> >to be set to, the driver adding extra toggles is likely to disrupt
>> >things.
>
>> I will have a look at this again. But it was added for a reason. The
>> issue is that we have two different busses in front of the controller,
>> so we might need more settle time when switching interface.
>
>If there's a mux that needs to be handled specially that mux should be
>described in DT on the relevant boards, there shouldn't just be
>something hard coded in the controller driver.

I have been able to change this into a straight setting - no
toggling. Just needed a settle delay.

I looked at the spi-mux driver, but that is more for muxing the CS's, as
I understand - not the actual bus segment. I could use it, but it would
require encoding the bus segment into the CS (double the normal
range). Also, selecting the bus interface is tightly coupled to the
controller - its not an externally constructed board mux.

I feel the current implementation is more to the point, and easily
understandable. It just adds the "microchip,spi-interface2" DT property.

It might be that a better way exists using the spi-mux framework, and if
you have some ideas for that I'd be all ears.

>
>BTW please do not CC subsystem patches to soc@...nel.org unless there's
>a specific reason to do so - there's no need for it, these patches won't
>get merged via there unless something is going wrong.  Generally the
>subsystem maintainers take patches for a given subsystem.

Ok, duly noted.

Thank you for the comments.

---Lars


-- 
Lars Povlsen,
Microchip