Patch Set 1:

Patch Set 1:

The implementation in soc/amd was probably forked while some other changes in SPI subsystem were in progress. Some things were probably lost in rebase, grep for SPI_CNTRLR_DEDUCT_CMD_LEN, notice it being used for {agesa,pi}/hudson.

Ideally amd/block/spi would work with hudson too.

We would've forked mid-2017. IIRC correctly from earlier this year, Richard was asked to write a brand new driver for common/block/spi and get us away from the generic one and variable length arrays. FWIW, it looks like we used to have SPI_CNTRLR_DEDUCT_CMD_LEN | _DEDUCT_OPCODE_LEN in our old spi.c. Things look a bit different now than hudson. I agree the common code should work on all AMD FCHs, but I never had the time to review his code closely. Not sure I see where VLAs went away yet.

I have pending work on it and will push a patch soon. AFAIK not all hudsons will be able to use the common SPI block (lack of shadow registers at SPIx4X)

After looking deeper into the SPI block code I can see why this is a brand new driver. Especially the existence of "non_standard_sst_*" makes it not necessarily common or generic. Given the situation, I put my work on the common SPI block for AMD on hold until it clarifies a bit. For now, the only way I see it could be "common" is to separate the "new driver" exclusively used by Picasso and Stoneyridge. But maybe I am lacking the rationale why the SPI block ended like this. Any guidance on how to address it very welcome and appreicated.

View Change

To view, visit change 37721. To unsubscribe, or for help writing mail filters, visit settings.