Message ID | 20201001152148.29747-1-l.stelmach@samsung.com (mailing list archive) |
---|---|
Headers | show |
Series | Some fixes for spi-s3c64xx | expand |
On Thu, Oct 01, 2020 at 05:21:39PM +0200, Łukasz Stelmach wrote: > This is a series of fixes created during porting a device driver (these > patches will be released soon too) for an SPI device to the current kernel. There appeared to be a number of outstanding review comments (misleading commit message on patch 7, some concerns about the non-CMU case), please address those. Please don't send new patches in reply to old ones, it buries them in threads and can make it hard to follow what's going on.
It was <2020-10-01 czw 17:13>, when Mark Brown wrote: > On Thu, Oct 01, 2020 at 05:21:39PM +0200, Łukasz Stelmach wrote: >> This is a series of fixes created during porting a device driver (these >> patches will be released soon too) for an SPI device to the current kernel. > > There appeared to be a number of outstanding review comments (misleading > commit message on patch 7, some concerns about the non-CMU case), please > address those. We discussed with Tomasz Figa and Krzysztof Kozłowski off the list that this is practically unused. Tomasz, Krzysztof, would you be so kind to share the details? Kind regards,
On Thu, Oct 01, 2020 at 08:23:00PM +0200, Lukasz Stelmach wrote: > It was <2020-10-01 czw 17:13>, when Mark Brown wrote: > > On Thu, Oct 01, 2020 at 05:21:39PM +0200, Łukasz Stelmach wrote: > >> This is a series of fixes created during porting a device driver (these > >> patches will be released soon too) for an SPI device to the current kernel. > > > > There appeared to be a number of outstanding review comments (misleading > > commit message on patch 7, some concerns about the non-CMU case), please > > address those. > > We discussed with Tomasz Figa and Krzysztof Kozłowski off the list that > this is practically unused. Tomasz, Krzysztof, would you be so kind to > share the details? That is correct. We did not provide final comments on the list so they could be added here - in change log. This would also be an explanation why there is a resend. Another solution would be to extend the commit #7 description - why only CMU case is covered. About patch #7: The decision was not to correct non-CMU case because there were not actual reports about clock rounding poblems, it would not be trivial change and we do not have the HW to test. Thanks Mark for looking into it. Best regards, Krzysztof
On Thu, Oct 01, 2020 at 09:02:57PM +0200, Krzysztof Kozlowski wrote: > That is correct. We did not provide final comments on the list so they > could be added here - in change log. This would also be an explanation > why there is a resend. Another solution would be to extend the commit #7 > description - why only CMU case is covered. If there's a new changelog then it's not a resend, the changelog is part of the content so I'd expect a version bump for that alone. IIRC the changelog needed some clarification anyway?
On Thu, 1 Oct 2020 at 21:44, Mark Brown <broonie@kernel.org> wrote: > > On Thu, Oct 01, 2020 at 09:02:57PM +0200, Krzysztof Kozlowski wrote: > > > That is correct. We did not provide final comments on the list so they > > could be added here - in change log. This would also be an explanation > > why there is a resend. Another solution would be to extend the commit #7 > > description - why only CMU case is covered. > > If there's a new changelog then it's not a resend, the changelog is part > of the content so I'd expect a version bump for that alone. IIRC the > changelog needed some clarification anyway? Yes, documenting the non-CMU case in changeloge would be good. It should be also v3 because of another reason: two patches got reordered to a more meaningful position in patchset, which brought minor differences in them. Best regards, Krzysztof