On Wednesday, 1 June 2022 19:04:27 CEST Heinrich Schuchardt wrote: > On 6/1/22 11:28, Diederik de Haas wrote: > > On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings <ben@decadent.org.uk> wrote: > >> Version: 4.17.2-1~exp1 > >> > >> On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >>> Please, add this patch to the Debian kernel patches until it is added > >>> upstream. Cf. > >>> https://lkml.org/lkml/2018/6/4/781 > >> > >> This was applied in the above merge but not mentioned in the changelog > >> due to a mis-merge. > > > > In response Heiko says in https://lkml.org/lkml/2018/6/19/1167: > > "and dropped again. > > > > Sadly it looks like the patch causes conflicts with at least one firefly > > board in a kernelci lab. My own is currently not ready to use, so I cannot > > look myself right now. > > > > The issue kernelci people described sounded quite a lot like the one > > in your commit message, so my current theory is that the > > suspend-voltage-selector must in some form corespond to the > > cpu_b_sleep_h gpio setting we're currently not handling at all, which > > would therefore depend on how the bootloader sets this up." > > > > It's also not part of current upstream master, so this is a DTS change > > that is specific for Debian and possibly not needed and/or incorrect? > > > > Heinrich, can you tell us more about the current status of this patch? > > I have not been working on the board in the last years. > > My impression at the time was that one would have to detect the current > state of the board at runtime which matches what you wrote. Thanks for your response. FTR: It was all part of Heiko's quote; I have no insight in this matter. Normally, AIUI, patches like these are added in expectation that they can be dropped later when it's merged into upstream source code. As that did not happen in this case I think it would be better to just drop this patch from the Debian kernel. It may be that upstream has fixed this issue in another way (I have no idea whether this is the case). And if the issue resurfaces again (against a current kernel), then we can see whether this patch would fix it (again) and then we'd have a better case to actually get it integrated in the upstream source. But that's a decision that one of the Debian kernel maintainers should make. Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.