On 16/10/2023 06:32, Jacky Huang wrote:
Read comments carefully.+ '#size-cells':sys is quite generic. Description explains nothing except duplicating
+ const: 1
+
+ nuvoton,sys:
+ description:
+ phandle to the syscon node
known information. Drop duplicated info and instead explain to what this
phandle points and how it is going to be used.
Nothing improved.I would like to update this as:
+ $ref: /schemas/types.yaml#/definitions/phandle-arraySo just phandle, not phandle-array, unless it is defined like this in
+ items:
+ maxItems: 1
some other binding.
nuvoton,sys:
$ref: /schemas/types.yaml#/definitions/phandleDriver is not relevant here. Say which part of syscon are necessary for
description:
Help pinctrl driver to access system registers by means of regmap.
pinctrl operation.
[.] is redundant... What exactly do you want to match?
I will fix it.+allOf: goes after required: block.
+ ranges: true
+
+allOf:
+ - $ref: pinctrl.yaml#
I will fix this, and also fix the dtsi.+^gpio@[0-9a-f]+$":
+patternProperties:
+ "gpio[a-n]@[0-9a-f]+$":
I will fix it.+ type: objectDrop blank line
+ additionalProperties: false
+ properties:
+
I will fix the order.+ gpio-controller: trueKeep the same order as in list of properties.
+
+ '#gpio-cells':
+ const: 2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description:
+ The interrupt outputs to sysirq.
+ maxItems: 1
+
+ required:
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
I will use '"^pin-[a-z0-9-.]+$" instead.+Why using different naming than other Nuvoton SoCs? You also accept
+ "pcfg-[a-z0-9-.]+$":
"foobarpcfg-1", which does not look intentional.
OK, then go with nuvoton approach. List the properties (:true) and use
I will add unevaluatedProperties: false.+ type: objectmissing additional/unevaluatedProperties: false.
+ description:
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ allOf:
+ - $ref: pincfg-node.yaml#
We expect the pin configuration to select one of ==>+Why do you need this and other ones?
+ properties:
+ bias-disable: true
bias-disable;
bias-pull-down;
bias-pull-up;
This is the same as rockchip,pinctrl.yaml and renesas,rzv2m-pinctrl.yaml.
additionalProperties: false.
Instead treat it as mA. Is this possible?We treat this value as the value to be written to the control register,+0 mA? Is it really valid? Are you sure you used correct property?
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ drive-strength:
+ minimum: 0
not as
a current value in mA. I will correct this mistake.
There is actually power-source, but treated as actual choice of power+ maximum: 7Missing units in property name. power-source also does not really
+
+ input-enable: true
+
+ input-schmitt-enable: true
+
+ power-source:
+ description:
+ I/O voltage in millivolt.
+ enum: [ 1800, 3300 ]
describe the property.
The output voltage level of GPIO can be configured as 1.8V or 3.3V,
but I cannot find any suitable output properties in 'pincfg-node.yaml.'
supplies.
I noticed that 'xlnx,zynq-pinctrl.yaml' and 'xlnx,zynq-pinctrl.yaml' useMaybe Rob or Linus have here some recommendation, but I would suggest to
'power source' to specify the output voltage. Should I follow their
approach or define a vendor-specific one?
go either with rtd1319d-pinctrl.yaml approach or add a generic property
to pincfg-node expressed in real units like "io-microvolt".
Rob, Linus, any ideas for generic property replacing register-specific
power-source?
Best regards,
Krzysztof