On 12/6/21 11:10 AM, Guenter Roeck wrote: > On 12/6/21 10:55 AM, Lee Jones wrote: >> On Mon, 06 Dec 2021, Florian Fainelli wrote: >> >>> On 12/6/21 1:05 AM, Lee Jones wrote: >>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>> >>>>> On 06.12.2021 09:44, Lee Jones wrote: >>>>>> On Mon, 06 Dec 2021, Rafał Miłecki wrote: >>>>>>> On 15.11.2021 06:53, Rafał Miłecki wrote: >>>>>>>> From: Rafał Miłecki <rafal@xxxxxxxxxx> >>>>>>>> >>>>>>>> This helps validating DTS files. >>>>>>>> >>>>>>>> Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx> >>>>>>>> Acked-by: Florian Fainelli <f.fainelli@xxxxxxxxx> >>>>>>>> Reviewed-by: Rob Herring <robh@xxxxxxxxxx> >>>>>>> >>>>>>> I'm not familiar with handling multi-subsystem patchsets (here: >>>>>>> watchdog >>>>>>> & MFD). >>>>>>> >>>>>>> Please kindly let me know: how to proceed with this patchset now >>>>>>> to get >>>>>>> it queued for Linus? >>>>>> >>>>>> What is the requirement for these to be merged together? >>>>> >>>>> If you merge 2/2 without 1/2 then people running "make >>>>> dt_binding_check" >>>>> may see 1 extra warning until both patches meet in Linus's tree. >>>>> >>>>> So it all comes to how much you care about amount of warnings produced >>>>> by "dt_binding_check". >>>> >>>> In -next, I don't, but I know Rob gets excited about it. >>>> >>>> Rob, what is your final word on this? Is it a forced requirement for >>>> all interconnected document changes to go in together? >>> >>> The first patch is queued up in Guenter's watchdog tree here: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=a5b2ebc8f6e67b5c81023e8bde6b19ff48ffdb02 >>> >>> >>> and will be submitted to Wim shortly I believe, so I suppose we should >>> take patch #2 via Guenter and Wim's tree as well logically. >> >> If that happens, I would like a PR to an immutable branch. >> > > I don't entirely see the point of that complexity for dt changes, > but whatever. Since my tree is not the official watchdog-next tree, > that means I can not take the entire series (which goes way beyond > the dt changes and also drops the bcm63xx driver). Unless I hear > otherwise, I'll drop the series from my tree for the time being > and wait for the dt changes to be sorted out. There is simply no rush in getting the bcm7038-wdt driver to support 4908 *just now*, so why don't you just take the bcm63xx-wdt series that I posed, and Rafal posts an updated series that adds support for the 4908 watchdog for the 5.18 cycle? -- Florian
