On 2/6/24 18:59, Sam Protsenko wrote: > On Tue, Feb 6, 2024 at 2:52 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: >> >> Depends on the simple cleanup patches from: >> https://lore.kernel.org/linux-spi/20240205124513.447875-1-tudor.ambarus@xxxxxxxxxx/ >> >> A slightly different version of the google,gs101-spi support was sent at: >> https://lore.kernel.org/linux-spi/20240125145007.748295-1-tudor.ambarus@xxxxxxxxxx/ >> >> Let's add support for gs101-spi so that I have a testing base for the >> driver rework patches that will follow. >> >> Tudor Ambarus (4): >> spi: s3c64xx: explicitly include <linux/types.h> >> spi: dt-bindings: samsung: add google,gs101-spi compatible >> spi: s3c64xx: add s3c64xx_iowrite{8,16}_32_rep accessors >> spi: s3c64xx: add support for google,gs101-spi >> > > Just a grumpy note: I wish this series (except for the [PATCH 1/4], > which I'd argue doesn't belong here) was submitted before the rest of > SPI cleanups and reworkings. Would've made reviewing much easier, > because this series doesn't apply without SPI cleanup series that has > to be applied prior to that. There are other benefits to that approach > too, as was discussed earlier. > I feel we're bike-shedding, it drains my energy. Your reasons were: 1/ easier review 2/ easier backporting of gs101 if that's ever wanted 3/ driver rework takes more review time and I risk not having gs101 integrated for next release 2/ is not true right now, I could cherry-pick the iowrite and gs101 patches on top of v6.7. With 1/ I don't agree as the gs101 patches are the same with or without the simple cleanup. 3/ is my responsibility and I'm ok with it, I feel there's enough time for all What matters, as I specified in the cover letter, is to have the gs101 patches before the functional driver rework which will follow, so that I can test each functional patch with gs101. I give up however, I'll do as you want. Will respin all.
