Re: [PATCH v5 1/2] dt-bindings: usb: dwc3: Clean up hs_phy_irq in binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/12/2023 16:03, Krishna Kurapati PSSNV wrote:
> 
> 
> On 12/26/2023 5:52 PM, Krzysztof Kozlowski wrote:
> 
>>>>
>>>> This does not answer why, you sc8280xp and x1e80100 not get one optional
>>>> interrupt. I asked "why" you are doing this change. Why do you need it?
>>>> What is the rationale?
>>>>
>>>> Then I grunted about unmanageable commit, because all my troubles to
>>>> review it are the effect of it: it is very difficult to read. It is also
>>>> difficult for you, because you keep making here mistakes. So if you
>>>> cannot write this commit properly and I cannot review it, then it is way
>>>> over-complicated, don't you think? But this is still second problem
>>>> here, don't ignore the fist - "why?"
>>>
>>> HI Krzysztof,
>>>
>>>    Thanks for the review.
>>>    To answer the question,
>>>
>>> "why ?" : The interrupts have been mis-interpreted on many platforms or
>>> many interrupts are missing.
>>
>> I asked about these two specific platforms. Please explain these
>> changes. Above is so generic that tells me nothing.
>>
> 
> Is the question, "Why do x1e80100 and sc8280 don't have hs_phy_irq ?"

 No, not entirely, the question was why these have flexible number of
IRQs (last one optional)?


> If so, I checked the SC8280 HW specifics and I see one small error. The 
> name was printed wrong. I got it from another source. Will move sc8280 
> to list having 5 interrupts. As per x1e80100, I wasn't able to get my 
> hands on the hw specifics and I followed the following link by Abel Vesa:
> 
> https://lore.kernel.org/r/20231214-x1e80100-usb-v1-1-c22be5c0109e@xxxxxxxxxx
> 
> As per the above patch, x1e80100 had only 4 interrupts.

Hm, ok, you say "4" but your patch says "minItems: 3". 3 != 4.

> For ipq5332, it has no hs_phy_irq and so I kept it under this section.
> 
>>>
>>> Now, if I am adding the missing interrupts, I need to segregate targets
>>> also into respective buckets in the same patch and that is what making
>>> this patch a little complicated. Is it possible / acceptable to split
>>> this into two patches if this is the case. Can you help with suggestions
>>> from your end ? Or may be I am understanding your question wrong ? 😅
>>
>> Split the patch into manageable chunks.
>>
> 
> I will try to split it up, but not sure if it is a good idea. I say so 
> because all permutations should be added in single patch and I can't 
> split that.
Best regards,
Krzysztof





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux