[alsa-devel] [PATCH] of: add empty of_find_node_by_path() for !OF
Add an empty version of of_find_node_by_path(). This fixes following build error for asoc tree: sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe': sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function 'of_find_node_by_path' [-Werror=implicit-function-declaration] sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Signed-off-by: Alexander Shiyan shc_work@mail.ru --- include/linux/of.h | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h index 919bf21..3bad8d1 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -374,6 +374,11 @@ static inline struct device_node *of_find_matching_node_and_match( return NULL; }
+static inline struct device_node *of_find_node_by_path(const char *path) +{ + return NULL; +} + static inline struct device_node *of_get_parent(const struct device_node *node) { return NULL;
On Wed, Apr 16, 2014 at 1:49 AM, Alexander Shiyan shc_work@mail.ru wrote:
Add an empty version of of_find_node_by_path(). This fixes following build error for asoc tree: sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe': sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function 'of_find_node_by_path' [-Werror=implicit-function-declaration] sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Signed-off-by: Alexander Shiyan shc_work@mail.ru
Applied.
Rob
On Wed, Apr 16, 2014 at 07:26:13AM -0500, Rob Herring wrote:
On Wed, Apr 16, 2014 at 1:49 AM, Alexander Shiyan shc_work@mail.ru wrote:
Add an empty version of of_find_node_by_path(). This fixes following build error for asoc tree: sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe': sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function 'of_find_node_by_path' [-Werror=implicit-function-declaration] sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Signed-off-by: Alexander Shiyan shc_work@mail.ru
Applied.
Is there a branch I can pull into ASoC, or can I apply it there? This fixes a build failure introduced into there by some recent work.
On Wed, Apr 16, 2014 at 9:25 AM, Mark Brown broonie@kernel.org wrote:
On Wed, Apr 16, 2014 at 07:26:13AM -0500, Rob Herring wrote:
On Wed, Apr 16, 2014 at 1:49 AM, Alexander Shiyan shc_work@mail.ru wrote:
Add an empty version of of_find_node_by_path(). This fixes following build error for asoc tree: sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe': sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function 'of_find_node_by_path' [-Werror=implicit-function-declaration] sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Signed-off-by: Alexander Shiyan shc_work@mail.ru
Applied.
Is there a branch I can pull into ASoC, or can I apply it there? This fixes a build failure introduced into there by some recent work.
I haven't pushed it out yet. You can take it and add my ack if you want instead. Otherwise, I do plan to send fixes to Linus this week.
Rob
On Wed, Apr 16, 2014 at 09:32:37AM -0500, Rob Herring wrote:
On Wed, Apr 16, 2014 at 9:25 AM, Mark Brown broonie@kernel.org wrote:
Is there a branch I can pull into ASoC, or can I apply it there? This fixes a build failure introduced into there by some recent work.
I haven't pushed it out yet. You can take it and add my ack if you want instead. Otherwise, I do plan to send fixes to Linus this week.
OK, this is needed for new development so I'll apply it temporarily so I don't break my tree in -next and then discard it once Linus merges - sound sensible?
On Wed, Apr 16, 2014 at 11:03 AM, Mark Brown broonie@kernel.org wrote:
On Wed, Apr 16, 2014 at 09:32:37AM -0500, Rob Herring wrote:
On Wed, Apr 16, 2014 at 9:25 AM, Mark Brown broonie@kernel.org wrote:
Is there a branch I can pull into ASoC, or can I apply it there? This fixes a build failure introduced into there by some recent work.
I haven't pushed it out yet. You can take it and add my ack if you want instead. Otherwise, I do plan to send fixes to Linus this week.
OK, this is needed for new development so I'll apply it temporarily so I don't break my tree in -next and then discard it once Linus merges - sound sensible?
Yes. If this going to be a common pattern, a of_get_machine_compatible() helper might be useful. Usually, any code searching by path makes me suspicious.
Rob
On Wed, Apr 16, 2014 at 11:10:15AM -0500, Rob Herring wrote:
Yes. If this going to be a common pattern, a of_get_machine_compatible() helper might be useful. Usually, any code searching by path makes me suspicious.
I've always been surprised we don't have more infrastructure for quirking off machine type in a similar way to how ACPI systems use DMI.
On Wed, Apr 16, 2014 at 12:15 PM, Mark Brown broonie@kernel.org wrote:
On Wed, Apr 16, 2014 at 11:10:15AM -0500, Rob Herring wrote:
Yes. If this going to be a common pattern, a of_get_machine_compatible() helper might be useful. Usually, any code searching by path makes me suspicious.
I've always been surprised we don't have more infrastructure for quirking off machine type in a similar way to how ACPI systems use DMI.
We used to have machine_is_blah which is kind of replaced by of_machine_is_compatible, but yes that is a bit limited. What the fsl ssi driver is doing isn't really a quirk anyway.
PCI also has a whole infrastructure for applying quirks. We could do something similar which could add/fix properties or do various setup. Then we'd be able to scatter calls everywhere:
OF_FIXUP("some-compatible-str", fixup_function);
I don't know that we want to encourge that, but would be a way to separate handling old/broken bindings separately from current code paths. I guess the question is whether we have many existing cases (PPC, I'm looking at you) that would benefit.
BTW, I did propose something similar with conditional initcalls a while back[1]. Perhaps as a fixup would be more acceptable than an initcall.
Rob
[1] http://comments.gmane.org/gmane.linux.drivers.devicetree/50117
participants (3)
-
Alexander Shiyan -
Mark Brown -
Rob Herring