On Thu, Oct 15, 2020 at 11:52 AM Robin Murphy robin.murphy@arm.com wrote:
On 2020-10-14 19:39, Rob Herring wrote:
On Wed, Oct 14, 2020 at 9:54 AM Richard Fitzgerald rf@opensource.cirrus.com wrote:
Add an equivalent of of_count_phandle_with_args() for fixed argument sets, to pair with of_parse_phandle_with_fixed_args().
Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com
drivers/of/base.c | 42 ++++++++++++++++++++++++++++++++++++++++++ include/linux/of.h | 9 +++++++++ 2 files changed, 51 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c index ea44fea99813..45d8b0e65345 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1772,6 +1772,48 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na } EXPORT_SYMBOL(of_count_phandle_with_args);
+/**
- of_count_phandle_with_fixed_args() - Find the number of phandles references in a property
- @np: pointer to a device tree node containing a list
- @list_name: property name that contains a list
- @cell_count: number of argument cells following the phandle
- Returns the number of phandle + argument tuples within a property. It
- is a typical pattern to encode a list of phandle and variable
- arguments into a single property.
- */
+int of_count_phandle_with_fixed_args(const struct device_node *np,
const char *list_name,int cells_count)+{
Looks to me like you can refactor of_count_phandle_with_args to handle both case and then make this and of_count_phandle_with_args simple wrapper functions.
Although for just counting the number of phandles each with n arguments that a property contains, isn't that simply a case of dividing the property length by n + 1? The phandles themselves will be validated by any subsequent of_parse_phandle*() call anyway, so there doesn't seem much point in doing more work then necessary here.
struct of_phandle_iterator it;int rc, cur_index = 0;if (!cells_count) {const __be32 *list;int size;list = of_get_property(np, list_name, &size);if (!list)return -ENOENT;return size / sizeof(*list);Case in point - if it's OK to do exactly that for n == 0, then clearly we're *aren't* fussed about validating anything, so the n > 0 code below is nothing more than a massively expensive way to check for a nonzero remainder :/
Indeed. We should just generalize this. It can still be refactored to shared code.
It's probably worthwhile to check for a remainder here IMO.
Rob