Re: [PATCH v2 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332 platform

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

 



On 15/12/2023 12:42, Jie Luo wrote:
>>>>>>>> Which clocks are these mentioned in the property? From where do they come?
>>>>>>>>
>>>>>>>> Anyway, property is in existing form is not correct - this is not a
>>>>>>>> generic property.
>>>>>>>>
>>>>>>>
>>>>>>> This property cmn-reference-clock is just the hardware register
>>>>>>> configuration, since the different IPQ platform needs to select
>>>>>>> the different reference clock source for the CMN PLL block that
>>>>>>> provides the various clock outputs to the all kinds of Ethernet
>>>>>>> devices, which is not from GCC provider.
>>>>>>
>>>>>> AGAIN: where do the clocks come from? Which device generates them?
>>>>>
>>>>> Oh, OK, the reference clock is from wifi that provides 48MHZ to
>>>>> Ethernet block.
>>>>
>>>> Then WiFi should be providing you the clock and this device should be
>>>> clock consumer, right?
>>>
>>> Yes, wifi provides 48MHz clock to CMM PLL block, there is no GCC
>>> for this 48MHZ clock output, it is the hardware PIN connection.
>>
>> All clocks are some hardware pin connections.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Yes, all reference clocks here are from hardware pin connection.

You keep answering with short sentences without touching the root of the
problem. I don't know exactly why, but I feel this discussion leads
nowhere. After long discussion you finally admitted that clocks came
from another device - Wifi. It took us like 6 emails?

So last statement: if you have clock provider and clock consumer, you
must represent it in the bindings or provide rationale why it should not
or must not be represented in the bindings. So far I do not see any of
such arguments.

If you use arguments like:
"My driver....": sorry, bindings are not about drivers
"I don't have clock driver for WiFi": sorry, it does not matter if you
can write one, right?

Please reach internally your colleagues to solve these problems and make
review process smoother.

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