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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof