Re: [PATCH net-next v12 08/14] dpll: zl3073x: Read DPLL types and pin properties from system firmware

[Ivan Vecera]

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 */
> > +}
>
> [...]