[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1249bfa8-2a40-449a-897c-a862d3a8e65a@linaro.org>
Date: Wed, 7 Feb 2024 07:50:43 +0000
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Sam Protsenko <semen.protsenko@...aro.org>
Cc: broonie@...nel.org, andi.shyti@...nel.org,
krzysztof.kozlowski@...aro.org, alim.akhtar@...sung.com,
linux-spi@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
andre.draszik@...aro.org, peter.griffin@...aro.org, kernel-team@...roid.com,
willmcvicker@...gle.com, robh+dt@...nel.org, conor+dt@...nel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 0/4] spi: s3c64xx: add support for google,gs101-spi
On 2/6/24 18:59, Sam Protsenko wrote:
> On Tue, Feb 6, 2024 at 2:52 AM Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
>>
>> Depends on the simple cleanup patches from:
>> https://lore.kernel.org/linux-spi/20240205124513.447875-1-tudor.ambarus@linaro.org/
>>
>> A slightly different version of the google,gs101-spi support was sent at:
>> https://lore.kernel.org/linux-spi/20240125145007.748295-1-tudor.ambarus@linaro.org/
>>
>> 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.
Powered by blists - more mailing lists