[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2580b45b-5d66-d716-41f3-4050236e89c2@linaro.org>
Date: Fri, 10 Mar 2023 10:55:26 +0000
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Michael Walle <michael@...le.cc>,
Rafał Miłecki <rafal@...ecki.pl>,
Robert Marko <robert.marko@...tura.hr>,
Luka Perkov <luka.perkov@...tura.hr>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
devicetree@...r.kernel.org
Subject: Re: [PATCH v3 09/20] nvmem: core: introduce NVMEM layouts
On 08/03/2023 15:31, Miquel Raynal wrote:
> +const void *nvmem_layout_get_match_data(struct nvmem_device *nvmem,
> + struct nvmem_layout *layout)
> +{
> + struct device_node __maybe_unused *layout_np;
> + const struct of_device_id *match;
> +
> + layout_np = of_nvmem_layout_get_container(nvmem);
> + match = of_match_node(layout->of_match_table, layout_np);
> +
> + return match ? match->data : NULL;
> +}
> +EXPORT_SYMBOL_GPL(nvmem_layout_get_match_data);
who is the user of this function, in the current patchset I see none?
On the other hand interpretation of match data is pretty much driver
specific i see no reason for this to be in core.
--srini
> +
Powered by blists - more mailing lists