Re: [PATCH v2 2/3] spi: Add HiSilicon v3xx SPI NOR flash controller driver

From: John Garry
Date: Fri Jan 31 2020 - 11:26:53 EST


On 31/01/2020 15:46, Andy Shevchenko wrote:
On Fri, Jan 31, 2020 at 2:03 PM John Garry <john.garry@xxxxxxxxxx> wrote:
On 31/01/2020 11:39, Andy Shevchenko wrote:
On Fri, Jan 31, 2020 at 12:08 PM John Garry <john.garry@xxxxxxxxxx> wrote:
On 13/01/2020 14:34, Andy Shevchenko wrote:

...

About this topic of ACPI having no method to describe device buswidth in
the resource descriptor, it may be an idea for me to raise a Tianocore
feature request @ https://bugzilla.tianocore.org/


The 19.6.126 describes the SPI resource, in particular:

---8<---8<---
DataBitLength is the size, in bits, of the smallest transfer unit for
this connection. _LEN is automatically
created to refer to this portion of the resource descriptor.
---8<---8<---


Hi Andy,

Is it what you are looking for? (As far as I know most of the
firmwares simple abuse this field among others)

I didn't think so - I thought that there was a distinction between width
and length in SPI terms.

My interpretation of this field is a data width of the slave.
Basically what we have as transfer->size inside SPI in the Linux
kernel.

So how do you find that most firmwares abuse this field? AFAICS, linux
kernel doesn't interpret this field at all.

From all tables I have this is the result of appearance (some of the
tables are like 10x times present in my data base, but nevertheless)

140 SpiSerialBusV2(0x0000,PolarityHigh,FourWireMode,0x08,
411 SpiSerialBusV2(0x0000,PolarityLow,FourWireMode,0x08,
1 SpiSerialBusV2(0x0000,PolarityLow,FourWireMode,0x08,
36 SpiSerialBusV2(0x0000,PolarityLow,FourWireMode,0x10,
35 SpiSerialBusV2(0x0000,PolarityLow,FourWireMode,0x18,
35 SpiSerialBusV2(0x0000,PolarityLow,FourWireMode,0x20,
1 SpiSerialBusV2(0x0000,PolarityLow,ThreeWireMode,0x10,
8 SpiSerialBusV2(0x0001,PolarityLow,FourWireMode,0x08,
1 SpiSerialBusV2(0x0001,PolarityLow,FourWireMode,0x10,

So, it seems I stand corrected, the field is in right use, although
cases like 0x10 and 0x20 should be carefully checked.

We may teach kernel to get something meaningful out of it.


It seems that someone already had a go at that:
https://lore.kernel.org/lkml/20170317212143.bogj6efzyvvf24yd@xxxxxxxxxxxxx/

Thanks,
John