On 15/11/2022 17:19, Andre Przywara wrote: > On Tue, 15 Nov 2022 16:00:54 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > Hi, > >> On 15/11/2022 11:44, Andre Przywara wrote: >>> On Tue, 15 Nov 2022 11:03:24 +0100 >>> Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: >>> >>> Hi, >>> >>>> On 15/11/2022 07:01, Jernej Škrabec wrote: >>>>> Dne četrtek, 10. november 2022 ob 08:35:39 CET je Vinod Koul napisal(a): >>>>>> On 06-11-22, 15:48, Andre Przywara wrote: >>>>>>> From: Icenowy Zheng <uwu@xxxxxxxxxx> >>>>>>> >>>>>>> The F1C100s SoC has one USB OTG port connected to a MUSB controller. >>>>>>> >>>>>>> Add support for its USB PHY. >>>>>> >>>>>> This does not apply for me, please rebase and resend >>>>>> >>>>>> Also, consider splitting phy patches from this. I dont think there is >>>>>> any dependency >>>>> >>>>> DT patches in this series depend on functionality added here. >>>>> >>>> >>>> DTS always goes separately from driver changes because it is a hardware >>>> description. Depending on driver means you have potential ABI break, so >>>> it is already a warning sign. >>> >>> We understand that ;-) >>> What Jernej meant was that the DTS patches at the end depend on patch >>> 01/10, which adds to the PHY binding doc. I am not sure if Vinod's >>> suggestion was about splitting off 01/10, 03/10, and 10/10, or just the >>> two latter which touch the driver. >>> >>> I can split off 03/10 and 10/10, rebased on top of linux-phy.git/next, and >>> send that to Vinod. >>> Then I would keep 01/10 in a respin of this series here, to satisfy the >>> dependency of the later DTS patches, and Vinod can pick that one patch from >>> there? >> >> There is no hard dependency of DTS on bindings. You can split these (and >> some maintainers prefer that way) and in DTS patches just provide the >> link to the bindings, saying it is in progress. > > But that breaks "make dtbs_check", doesn't it? The check will be broken anyway because binding goes via driver subsystem and DTS goes via arm-soc. If both make to the linux-next and next release, then it's not a problem. > > I would think that the DT bits - bindings first, then DTS files using it - > should be bundled. This is how I imagine the future(TM), where DTs and > bindings live outside the kernel repo. Yes, that's preferred. Therefore in DTS patch you say the binding is not merged and it is here - lore link. > >> The bindings should be however kept with driver changes as it goes the >> same way. > > I understand that the bindings describe the contract the driver acts on, > but going forward I think driver changes would need to come later, then > (since they will live in a separate repo at some day)? > Maybe pointing to the binding changes in progress? Later as one commit later - yes. Later as other option - not really, why? > So with a separate repo we would actually need to upstream just the > bindings first, then could push driver changes and .dts files > independently? There is no separate repo, so we talk about Linux case now. > And for now it looks like we are stuck with putting everything in one > series, to make both checkpatch and dtbs_check happy. You should rather make maintainers happy :) and here one asked to split. Best regards, Krzysztof
