linux-kernel - Re: [PATCH v2 2/2] spi: fsl-spi: Implement trailing bits

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: <f9046e68-ff22-2652-48dc-d277b4af75dd@csgroup.eu>
Date:   Thu, 18 Aug 2022 18:35:39 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Mark Brown <broonie@...nel.org>
CC:     Rob Herring <robh+dt@...nel.org>, Pratyush Yadav <p.yadav@...com>,
        "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>,
        Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH v2 2/2] spi: fsl-spi: Implement trailing bits



Le 28/02/2022 à 17:14, Mark Brown a écrit :
> 
>> We discussed that back in 2016 in
>> https://lore.kernel.org/linux-spi/20160824112701.GE22076@sirena.org.uk/
>> and my understanding at that time was that it was not something that
>> could be done at core level.
> 
>> But maybe things have changed since then ?
> 
> What I said then was "it would need a new core feature" which is what
> the binding does, I'm suggesting that you also do that for the handling
> of the implementation as well.
> 
> Actually now I think about it perhaps this shouldn't be a binding at all
> but rather something specified by the client driver - presumably any
> system using an affected device is going to need these extra clock
> cycles so they'll all need to add the same property.

Yes indeed. Therefore in v3 I took a different approach : a flag .cs_off 
tells to spi_transfer_one_message() that a given transfer has to be 
performed with chipselect OFF, therefore the consumer has full control 
of how and when to add those additional fake clock cycles during a 
transfer, and can eventually add one at anyplace during the transfer.

Here an exemple of what will do the consumer.


static int idt821034_8bit_write(struct idt821034 *idt821034, u8 val)
{
	struct spi_transfer xfer[] = {{
		.tx_buf = &idt821034->spi_tx_buf,
		.len = 1,
	},{
		.tx_buf = &idt821034->spi_tx_buf,
		.len = 1,
		.cs_off = 1,
	}};
	int ret;

	idt821034->spi_tx_buf = val;

	ret = spi_sync_transfer(idt821034->spi, xfer, ARRAY_SIZE(xfer));
	if (ret)
		return ret;

	return 0;
}



Christophe