Quoting Hans de Goede (2019-05-06 08:05:42) > Hi, > > On 06-05-19 16:59, Andy Shevchenko wrote: > > On Mon, May 6, 2019 at 5:47 PM Hans de Goede <hdego...@redhat.com> wrote: > >> > >> Hi, > >> > >> On 06-05-19 14:38, Andy Shevchenko wrote: > >>> On Mon, Apr 29, 2019 at 6:01 PM Hans de Goede <hdego...@redhat.com> wrote: > >>>> > >>>> The Lex 3I380D industrial PC has 4 ethernet controllers on board > >>>> which need pmc_plt_clk0 - 3 to function, add it to the critclk_systems > >>>> DMI table, so that drivers/clk/x86/clk-pmc-atom.c will mark the clocks > >>>> as CLK_CRITICAL and they will not get turned off. > >>>> > >>> > >>> Acked-by: Andy Shevchenko <andy.shevche...@gmail.com> > >>> supposedly to go via CLK tree. > >>> > >>> P.S. If you want it through PDx86, I need immutable branch / tag from CLK. > >> > >> Stephen added the patches this depends on to his fixes branch, so they > >> are in the 5.1 / Torvald's master branch, since we are now in the 5.2 merge > >> window, you should be able to cleanly apply this directly. > > > > We don't do back merges, so, our base is v5.1-rc1. Does it mean the > > commit in question is in v5.1-rc1? > > AFAICS it was appeared in v5.1-rc5. > > Ah, I see, my bad. > > Stephen can you pick up this patch and the > "[PATCH 1/1] Add several Beckhoff Automation boards to critclk_systems DMI > table" > patch then? >
I guess this is urgent? I'm lost why Andy can't apply the patch and merge it up to Linus. I don't maintain this driver here, and even if there's a cross tree dependency I don't understand why a base of v5.1-rc1 is limiting abilities to apply patches. I'd think that if an "immutable branch" was all that was required you could 'git checkout 7c2e07130090ae001a97a6b65597830d6815e93e' and then apply the patch there and merge it all up into the PDx86 tree. In the end, when sending the PR to Linus the already merged changes won't show up in the diff because it's all been merged already on the other side. Either way, I'm going to send off the clk PR real soon so this may need to wait until after the merge window, or if it's really urgent I could send a fixes branch before the merge window closes next week.
