[EXT] Re: [PATCH v2 1/3] dt-bindings: usb: cdns-imx8qm: add imx8qm cdns3 glue bindings

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Mon Mar 20 10:28:22 PDT 2023


On 20/03/2023 18:02, Frank Li wrote:

>>> Although frequency is fixed, clock name may change for difference
>> platform.
>>>
>>>                 assigned-clocks = <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_PER>,
>>>                                            <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_MISC>,
>>>                                            <&clk IMX_SC_R_USB_2
>> IMX_SC_PM_CLK_MST_BUS>;
>>>                assigned-clock-rates = <125000000>, <12000000>, <250000000>;
>>>
>>> some platform use IMX_SC_R_USB_2, other platform may use
>> IMX_SC_R_USB_3.
>>
>> This I understand, you wrote it above, so nothing new and my concerns
>> are still there.
> 
> I think Fixed value is not good reason. All reg base address, irq number are all for fixed number. The same

No, because one device - IP block - could have different addresses,
depending how it is wired/implemented in given SoC. Also our
representation of devices in the kernel requires regs/interrupts coming
from DTS, thus DTS is also answer to entire design of kernel and other SW.

That's not the case here at all.

> Logic can be applied to irq-provider driver. But why still be descript in dts? It is hardware property.    
> 
> https://elixir.bootlin.com/linux/v4.8/source/Documentation/devicetree/bindings/clock/clock-bindings.txt
> have not said that can't set to fixed clock frequency. 

I don't understand this.

> 
> This is quick common case for network, USB, SATA, PCIE,  which protocol defined
> Frequency.  

And they do not define fixed values in the bindings, so? There are
exceptions, but it's usually not argument, right?

> 
> https://elixir.bootlin.com/linux/v6.3-rc3/source/Documentation/devicetree/bindings/ata/qcom-sata.txt
> https://elixir.bootlin.com/linux/v6.3-rc3/source/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml

The second is a good example - as you can see, there is a choice of
values, so they are not exactly fixed.

> 
> Such frequency information is necessary.  We can put to dts or clock drivers.  The clock driver

If this is the argument, then the answer is NAK. Sorry, but DTS is not
for offloading fixed stuff just because you do not want to work on
drivers. The same for discoverable stuff.

> Become bigger, or dts become bigger.  I think the key point is if property to descript hardware information.  

You have to understand that with your binding you are not allowing to
any changes of these frequencies.

Best regards,
Krzysztof




More information about the linux-arm-kernel mailing list