On Thu, 24 Nov 2022 23:19:30 +0530 Vinod Koul <vkoul@xxxxxxxxxx> wrote: > On 15-11-22, 17:57, Andre Przywara wrote: > > On Tue, 15 Nov 2022 17:29:09 +0100 > > Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > > > Hi, > > > > > 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. > > > > Well, he asked to split off the USB PHY patches from the rest of the > > series, since there is some conflict with the recently merged H616 USB PHY > > patches. It is still unclear to me whether this split includes the binding > > patch, or just the two patches touching the actual code. > > That mean split off USB phy and binding patches from rest and send for > review Thanks, I figured, and that's what I did: https://lore.kernel.org/linux-arm-kernel/20221116151603.819533-1-andre.przywara@xxxxxxx/ Hope that fits! Cheers, Andre > > DTS or anything else should not be part of that >
