On Tue, Dec 08, 2020 at 04:17:45PM -0500, Sasha Levin wrote: > On Tue, Dec 08, 2020 at 06:11:45PM +0100, Lukas Wunner wrote: > > On Tue, Dec 08, 2020 at 08:47:39AM -0500, Sasha Levin wrote: > > > Could we instead have the backports exhibit the issue (like they did > > > upstream) and then take d853b3406903 on top? > > > > The upstream commit e13ee6cc4781 did not apply cleanly to 4.19 and earlier, > > several adjustments were required. Could I have made it so that the fixup > > d853b3406903 would have still been required? Probably, but it seems a > > little silly to submit a known-bad patch. [...] > 2. It'll make auditing later easier. What will happen now is that after > this patch is merges, we'll trigger a warning saying that there's a fix > upstream for one of these patches, and we'll end up wasting the time (of > probably a few folks) figuring this out. Would it be possible to amend the tooling such that multiple "[ Upstream commit ... ]" lines are supported at the top of the commit message, signifying that the backport patch subsumes all cited upstream commits? Could the extra work for stable maintainers be avoided that way? I imagine there might be more cases where a "clean" backport is not possible, requiring multiple upstream patches to be combined. > Note I'm not asking to submit a broken patch, but I'm asking to submit a > minimal backport followed by the upstream fix to that upstream bug :) Then please apply the series sans bcm2835aux patch and I'll follow up with a two-patch series specifically for that driver. Alternatively, please consider whether multiple "[ Upstream commit ... ]" lines would be a viable solution and if it is, add a line as follows when applying the bcm2835aux patch: [ Upstream commit d853b3406903a7dc5b14eb5bada3e8cd677f66a2 ] Thanks, Lukas
