On 02. 07. 25 12:41 odp., Jiri Pirko wrote:
Sun, Jun 29, 2025 at 09:10:43PM +0200, ivecera@xxxxxxxxxx wrote:
[...]
+/**
+ * zl3073x_prop_dpll_type_get - get DPLL channel type
+ * @zldev: pointer to zl3073x device
+ * @index: DPLL channel index
+ *
+ * Return: DPLL type for given DPLL channel
+ */
+enum dpll_type
+zl3073x_prop_dpll_type_get(struct zl3073x_dev *zldev, u8 index)
+{
+ const char *types[ZL3073X_MAX_CHANNELS];
+ int count;
+
+ /* Read dpll types property from firmware */
+ count = device_property_read_string_array(zldev->dev, "dpll-types",
+ types, ARRAY_SIZE(types));
+
+ /* Return default if property or entry for given channel is missing */
+ if (index >= count)
+ return DPLL_TYPE_PPS;
Not sure how this embedded stuff works, but isn't better to just bail
out in case this is not present/unknown_value? Why assuming PPS is
correct?
Per discussion with Microchip, the PPS should be reported as default.
The platform can define either via DT or APCI or software_node the
values for the DPLLs. Anyway this attribute is informational.
+
+ if (!strcmp(types[index], "pps"))
+ return DPLL_TYPE_PPS;
+ else if (!strcmp(types[index], "eec"))
+ return DPLL_TYPE_EEC;
+
+ dev_info(zldev->dev, "Unknown DPLL type '%s', using default\n",
+ types[index]);
+
+ return DPLL_TYPE_PPS; /* Default */
+}
[...]
