On 12/05/2023 12:22, Minda Chen wrote: > > > On 2023/5/11 22:49, Krzysztof Kozlowski wrote: >> On 11/05/2023 14:16, Roger Quadros wrote: >>> >>> >>> On 11/05/2023 12:26, Krzysztof Kozlowski wrote: >>>> On 10/05/2023 15:28, Minda Chen wrote: >>>>> To support generic clock and reset init in Cadence USBSS >>>>> controller, add clock and reset dts configuration. >>>>> >>>>> Signed-off-by: Minda Chen <minda.chen@xxxxxxxxxxxxxxxx> >>>>> --- >>>>> .../devicetree/bindings/usb/cdns,usb3.yaml | 14 ++++++++++++++ >>>>> 1 file changed, 14 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml >>>>> index cae46c4982ad..623c6b34dee3 100644 >>>>> --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml >>>>> +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml >>>>> @@ -42,6 +42,18 @@ properties: >>>>> - const: otg >>>>> - const: wakeup >>>>> >>>>> + clocks: >>>>> + minItems: 1 >>>>> + maxItems: 8 >>>>> + description: >>>>> + USB controller clocks. >>>> >>>> You need to list the items. And why is it variable? Your clock choice in >>>> the example is poor, I doubt it is real. >>>> >>>>> + >>>>> + resets: >>>>> + minItems: 1 >>>>> + maxItems: 8 >>>>> + description: >>>>> + USB controller generic resets. >>>> >>>> Here as well. >>>> >>>> You had one clock last time, thus the review was - drop the names. Now >>>> you changed it to 8 clocks... I don't understand. >>>> >>> >>> Different platforms may have different number of clocks/resets or none. >>> So I don't think minItems/maxItems should be specified. >> >> Yeah, but we want the clocks to be specific per platform. Not anything >> anywhere. >> >> Best regards, >> Krzysztof >> > > I can change like these. Are these changes can be approved? > lpm , bus clock and "pwrup" reset can be specific cases. (The changes are from snps,dwc3.yaml.) > > clocks: > description: > In general the core supports two types of clocks. bus is a SoC Bus > Clock(AHB/AXI/APB). lpm is a link power management clock. But particular > cases may differ from that having less or more clock sources with > another names. > > clock-names: > contains: > anyOf: > - enum: [bus, lpm] > - true > No because this does not solve my concern. You allow here anything, which is not desired. The device bindings should specify what clocks (and resets) you have here. Order is also fixed (with exceptions). Now, if this is generic IP block used by different SoC vendors and it has different clocks in different implementations, it means one compatible for all of them is not enough anymore. Best regards, Krzysztof
