[PATCH v3 03/11] phy: sun4i-usb: add support for the USB PHY on F1C100s SoC

[Andre Przywara]

On Thu, 24 Nov 2022 23:19:30 +0530
Vinod Koul <vkoul at kernel.org> wrote:

> On 15-11-22, 17:57, Andre Przywara wrote:
> > On Tue, 15 Nov 2022 17:29:09 +0100
> > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> > 
> > Hi,
> >   
> > > On 15/11/2022 17:19, Andre Przywara wrote:  
> > > > On Tue, 15 Nov 2022 16:00:54 +0100
> > > > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> > > > 
> > > > Hi,
> > > >     
> > > >> On 15/11/2022 11:44, Andre Przywara wrote:    
> > > >>> On Tue, 15 Nov 2022 11:03:24 +0100
> > > >>> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> 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 at icenowy.me>
> > > >>>>>>>
> > > >>>>>>> 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@arm.com/

Hope that fits!

Cheers,
Andre

> 
> DTS or anything else should not be part of that
>