diff mbox

of: add empty of_find_node_by_path() for !OF

Message ID 1397630960-26677-1-git-send-email-shc_work@mail.ru (mailing list archive)
State New, archived
Headers show

Commit Message

Alexander Shiyan April 16, 2014, 6:49 a.m. UTC
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(+)

Comments

Rob Herring April 16, 2014, 12:26 p.m. UTC | #1
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
Mark Brown April 16, 2014, 2:25 p.m. UTC | #2
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.
Rob Herring April 16, 2014, 2:32 p.m. UTC | #3
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
Mark Brown April 16, 2014, 4:03 p.m. UTC | #4
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?
Rob Herring April 16, 2014, 4:10 p.m. UTC | #5
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
Mark Brown April 16, 2014, 5:15 p.m. UTC | #6
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.
Rob Herring April 16, 2014, 5:39 p.m. UTC | #7
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
diff mbox

Patch

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;