From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
linux-gpio@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linux-acpi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Linux PWM List <linux-pwm@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH v2 02/12] device: property: find dependencies of a firmware node
Date: Sat, 11 Jul 2015 04:52:29 +0200 [thread overview]
Message-ID: <4693466.kRRNMahPuB@vostro.rjw.lan> (raw)
In-Reply-To: <CAAObsKC-71GsBWZdNjm5Cxek07=9dwzTp8mYezVXkt_k3mzKVw@mail.gmail.com>
On Friday, July 10, 2015 03:14:38 PM Tomeu Vizoso wrote:
> On 2 July 2015 at 02:02, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
> >> Adds API that allows callers to find out what other firmware nodes a
> >> node depends on.
> >>
> >> Implementors of bindings documentation can register callbacks that
> >> return the dependencies of a node.
> >>
> >> Dependency information can be used to change the order in which devices
> >> are probed, or to print a warning when a device node is going to be
> >> probed without all its dependencies fulfilled.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >
> > I'd like to see a description of the new API in English in the changelog.
>
> Agreed.
>
> >> ---
> >>
> >> Changes in v2:
> >> - Allow bindings implementations register a function instead of using
> >> class callbacks, as not only subsystems implement firmware bindings.
> >>
> >> drivers/base/property.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/fwnode.h | 5 +++
> >> include/linux/property.h | 12 +++++++
> >> 3 files changed, 108 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index 8ead1ba..9d38ede 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -19,7 +19,13 @@
> >> #include <linux/platform_device.h>
> >> #include <linux/property.h>
> >>
> >
> > Please add a comment describing this structure. In particular, what it is
> > supposed to be used for and how it is supposed to be used.
>
> Ok.
>
> >> +struct dependency_parser {
> >> + struct list_head parser;
> >
> > I'd rather call this "list_node" or something like that.
>
> Ok.
>
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps);
> >> +};
> >> +
> >> static bool fwnode_match_enable = false;
> >> +static LIST_HEAD(dependency_parsers);
> >>
> >> /**
> >> * device_add_property_set - Add a collection of properties to a device object.
> >> @@ -553,6 +559,27 @@ bool device_dma_is_coherent(struct device *dev)
> >> EXPORT_SYMBOL_GPL(device_dma_is_coherent);
> >>
> >> /**
> >> + * fwnode_add_dependency - add firmware node to the passed dependency list
> >> + * @fwnode: Firmware node to add to dependency list
> >> + * @list: Dependency list to add the fwnode to
> >> + */
> >> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
> >> + struct list_head *list)
> >> +{
> >> + struct fwnode_dependency *dep;
> >> +
> >> + dep = kzalloc(sizeof(*dep), GFP_KERNEL);
> >> + if (!dep)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&dep->dependency);
> >> + dep->fwnode = fwnode;
> >> +
> >> + list_add_tail(&dep->dependency, list);
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency);
> >> +
> >> +/**
> >> * fwnode_get_parent - return the parent node of a device node
> >> * @fwnode: Device node to find the parent node of
> >> */
> >> @@ -600,6 +627,70 @@ bool fwnode_is_compatible(struct fwnode_handle *fwnode, const char *compatible)
> >> EXPORT_SYMBOL_GPL(fwnode_is_compatible);
> >>
> >> /**
> >> + * fwnode_add_dependency_parser - register dependency parser
> >> + * @func: Function that will be called to find out dependencies of a node
> >> + *
> >> + * Registers a callback that will be called when collecting the dependencies
> >> + * of a firmware node. The callback should inspect the properties of the node
> >> + * and call fwnode_add_dependency() for each dependency it recognizes, from
> >> + * the bindings documentation.
> >> + */
> >> +void fwnode_add_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser;
> >> +
> >> + parser = kzalloc(sizeof(*parser), GFP_KERNEL);
> >> + if (!parser)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&parser->parser);
> >> + parser->func = func;
> >> +
> >> + list_add_tail(&parser->parser, &dependency_parsers);
> >
> > We're modifying a global list here. Any locking needed? RCU? Whatever?
>
> Oops.
>
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_remove_dependency_parser - unregister dependency parser
> >> + * @func: Function that was to be called to find out dependencies of a node
> >> + */
> >> +void fwnode_remove_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser, *tmp;
> >> +
> >> + list_for_each_entry_safe(parser, tmp, &dependency_parsers, parser) {
> >> + if (parser->func == func) {
> >> + list_del(&parser->parser);
> >> + kfree(parser);
> >> + return;
> >> + }
> >> + }
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_get_dependencies - find out what dependencies a firmware node has
> >> + * @fwnode: firmware node to find its dependencies
> >> + * @deps: list of struct fwnode_dependency in which dependencies will be placed
> >> + */
> >> +void fwnode_get_dependencies(struct fwnode_handle *fwnode,
> >> + struct list_head *deps)
> >> +{
> >> + struct dependency_parser *parser;
> >> + struct fwnode_handle *child;
> >> +
> >> + list_for_each_entry(parser, &dependency_parsers, parser)
> >> + parser->func(fwnode, deps);
> >> +
> >> + /* Some device nodes will have dependencies in non-device sub-nodes */
> >> + fwnode_for_each_child_node(fwnode, child)
> >> + if (!fwnode_property_present(child, "compatible"))
> >
> > This is a blatant OF-ism. We need to think about a generic way to express that.
>
> My impression from reading the existing usage of fwnode in gpiolib and
> the examples in the link below was that we were going to share the
> bindings between DT and ACPI. Doesn't that extend to the meaning of
> the compatible property?
>
> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Not entirely.
An ACPI device object without the "compatible" property may still represent a valid
device (and usually does), so it is not enough to check whether or not the "compatible"
property is present for that in general.
Thanks,
Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-fbdev@vger.kernel.org, linux-acpi@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
alsa-devel@alsa-project.org,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-gpio@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Linux PWM List <linux-pwm@vger.kernel.org>
Subject: Re: [PATCH v2 02/12] device: property: find dependencies of a firmware node
Date: Sat, 11 Jul 2015 04:52:29 +0200 [thread overview]
Message-ID: <4693466.kRRNMahPuB@vostro.rjw.lan> (raw)
In-Reply-To: <CAAObsKC-71GsBWZdNjm5Cxek07=9dwzTp8mYezVXkt_k3mzKVw@mail.gmail.com>
On Friday, July 10, 2015 03:14:38 PM Tomeu Vizoso wrote:
> On 2 July 2015 at 02:02, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
> >> Adds API that allows callers to find out what other firmware nodes a
> >> node depends on.
> >>
> >> Implementors of bindings documentation can register callbacks that
> >> return the dependencies of a node.
> >>
> >> Dependency information can be used to change the order in which devices
> >> are probed, or to print a warning when a device node is going to be
> >> probed without all its dependencies fulfilled.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >
> > I'd like to see a description of the new API in English in the changelog.
>
> Agreed.
>
> >> ---
> >>
> >> Changes in v2:
> >> - Allow bindings implementations register a function instead of using
> >> class callbacks, as not only subsystems implement firmware bindings.
> >>
> >> drivers/base/property.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/fwnode.h | 5 +++
> >> include/linux/property.h | 12 +++++++
> >> 3 files changed, 108 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index 8ead1ba..9d38ede 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -19,7 +19,13 @@
> >> #include <linux/platform_device.h>
> >> #include <linux/property.h>
> >>
> >
> > Please add a comment describing this structure. In particular, what it is
> > supposed to be used for and how it is supposed to be used.
>
> Ok.
>
> >> +struct dependency_parser {
> >> + struct list_head parser;
> >
> > I'd rather call this "list_node" or something like that.
>
> Ok.
>
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps);
> >> +};
> >> +
> >> static bool fwnode_match_enable = false;
> >> +static LIST_HEAD(dependency_parsers);
> >>
> >> /**
> >> * device_add_property_set - Add a collection of properties to a device object.
> >> @@ -553,6 +559,27 @@ bool device_dma_is_coherent(struct device *dev)
> >> EXPORT_SYMBOL_GPL(device_dma_is_coherent);
> >>
> >> /**
> >> + * fwnode_add_dependency - add firmware node to the passed dependency list
> >> + * @fwnode: Firmware node to add to dependency list
> >> + * @list: Dependency list to add the fwnode to
> >> + */
> >> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
> >> + struct list_head *list)
> >> +{
> >> + struct fwnode_dependency *dep;
> >> +
> >> + dep = kzalloc(sizeof(*dep), GFP_KERNEL);
> >> + if (!dep)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&dep->dependency);
> >> + dep->fwnode = fwnode;
> >> +
> >> + list_add_tail(&dep->dependency, list);
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency);
> >> +
> >> +/**
> >> * fwnode_get_parent - return the parent node of a device node
> >> * @fwnode: Device node to find the parent node of
> >> */
> >> @@ -600,6 +627,70 @@ bool fwnode_is_compatible(struct fwnode_handle *fwnode, const char *compatible)
> >> EXPORT_SYMBOL_GPL(fwnode_is_compatible);
> >>
> >> /**
> >> + * fwnode_add_dependency_parser - register dependency parser
> >> + * @func: Function that will be called to find out dependencies of a node
> >> + *
> >> + * Registers a callback that will be called when collecting the dependencies
> >> + * of a firmware node. The callback should inspect the properties of the node
> >> + * and call fwnode_add_dependency() for each dependency it recognizes, from
> >> + * the bindings documentation.
> >> + */
> >> +void fwnode_add_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser;
> >> +
> >> + parser = kzalloc(sizeof(*parser), GFP_KERNEL);
> >> + if (!parser)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&parser->parser);
> >> + parser->func = func;
> >> +
> >> + list_add_tail(&parser->parser, &dependency_parsers);
> >
> > We're modifying a global list here. Any locking needed? RCU? Whatever?
>
> Oops.
>
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_remove_dependency_parser - unregister dependency parser
> >> + * @func: Function that was to be called to find out dependencies of a node
> >> + */
> >> +void fwnode_remove_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser, *tmp;
> >> +
> >> + list_for_each_entry_safe(parser, tmp, &dependency_parsers, parser) {
> >> + if (parser->func == func) {
> >> + list_del(&parser->parser);
> >> + kfree(parser);
> >> + return;
> >> + }
> >> + }
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_get_dependencies - find out what dependencies a firmware node has
> >> + * @fwnode: firmware node to find its dependencies
> >> + * @deps: list of struct fwnode_dependency in which dependencies will be placed
> >> + */
> >> +void fwnode_get_dependencies(struct fwnode_handle *fwnode,
> >> + struct list_head *deps)
> >> +{
> >> + struct dependency_parser *parser;
> >> + struct fwnode_handle *child;
> >> +
> >> + list_for_each_entry(parser, &dependency_parsers, parser)
> >> + parser->func(fwnode, deps);
> >> +
> >> + /* Some device nodes will have dependencies in non-device sub-nodes */
> >> + fwnode_for_each_child_node(fwnode, child)
> >> + if (!fwnode_property_present(child, "compatible"))
> >
> > This is a blatant OF-ism. We need to think about a generic way to express that.
>
> My impression from reading the existing usage of fwnode in gpiolib and
> the examples in the link below was that we were going to share the
> bindings between DT and ACPI. Doesn't that extend to the meaning of
> the compatible property?
>
> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Not entirely.
An ACPI device object without the "compatible" property may still represent a valid
device (and usually does), so it is not enough to check whether or not the "compatible"
property is present for that in general.
Thanks,
Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-fbdev@vger.kernel.org, linux-acpi@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
alsa-devel@alsa-project.org,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-gpio@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Linux PWM List <linux-pwm@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH v2 02/12] device: property: find dependencies of a firmware node
Date: Sat, 11 Jul 2015 02:52:29 +0000 [thread overview]
Message-ID: <4693466.kRRNMahPuB@vostro.rjw.lan> (raw)
In-Reply-To: <CAAObsKC-71GsBWZdNjm5Cxek07=9dwzTp8mYezVXkt_k3mzKVw@mail.gmail.com>
On Friday, July 10, 2015 03:14:38 PM Tomeu Vizoso wrote:
> On 2 July 2015 at 02:02, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
> >> Adds API that allows callers to find out what other firmware nodes a
> >> node depends on.
> >>
> >> Implementors of bindings documentation can register callbacks that
> >> return the dependencies of a node.
> >>
> >> Dependency information can be used to change the order in which devices
> >> are probed, or to print a warning when a device node is going to be
> >> probed without all its dependencies fulfilled.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >
> > I'd like to see a description of the new API in English in the changelog.
>
> Agreed.
>
> >> ---
> >>
> >> Changes in v2:
> >> - Allow bindings implementations register a function instead of using
> >> class callbacks, as not only subsystems implement firmware bindings.
> >>
> >> drivers/base/property.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/fwnode.h | 5 +++
> >> include/linux/property.h | 12 +++++++
> >> 3 files changed, 108 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index 8ead1ba..9d38ede 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -19,7 +19,13 @@
> >> #include <linux/platform_device.h>
> >> #include <linux/property.h>
> >>
> >
> > Please add a comment describing this structure. In particular, what it is
> > supposed to be used for and how it is supposed to be used.
>
> Ok.
>
> >> +struct dependency_parser {
> >> + struct list_head parser;
> >
> > I'd rather call this "list_node" or something like that.
>
> Ok.
>
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps);
> >> +};
> >> +
> >> static bool fwnode_match_enable = false;
> >> +static LIST_HEAD(dependency_parsers);
> >>
> >> /**
> >> * device_add_property_set - Add a collection of properties to a device object.
> >> @@ -553,6 +559,27 @@ bool device_dma_is_coherent(struct device *dev)
> >> EXPORT_SYMBOL_GPL(device_dma_is_coherent);
> >>
> >> /**
> >> + * fwnode_add_dependency - add firmware node to the passed dependency list
> >> + * @fwnode: Firmware node to add to dependency list
> >> + * @list: Dependency list to add the fwnode to
> >> + */
> >> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
> >> + struct list_head *list)
> >> +{
> >> + struct fwnode_dependency *dep;
> >> +
> >> + dep = kzalloc(sizeof(*dep), GFP_KERNEL);
> >> + if (!dep)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&dep->dependency);
> >> + dep->fwnode = fwnode;
> >> +
> >> + list_add_tail(&dep->dependency, list);
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency);
> >> +
> >> +/**
> >> * fwnode_get_parent - return the parent node of a device node
> >> * @fwnode: Device node to find the parent node of
> >> */
> >> @@ -600,6 +627,70 @@ bool fwnode_is_compatible(struct fwnode_handle *fwnode, const char *compatible)
> >> EXPORT_SYMBOL_GPL(fwnode_is_compatible);
> >>
> >> /**
> >> + * fwnode_add_dependency_parser - register dependency parser
> >> + * @func: Function that will be called to find out dependencies of a node
> >> + *
> >> + * Registers a callback that will be called when collecting the dependencies
> >> + * of a firmware node. The callback should inspect the properties of the node
> >> + * and call fwnode_add_dependency() for each dependency it recognizes, from
> >> + * the bindings documentation.
> >> + */
> >> +void fwnode_add_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser;
> >> +
> >> + parser = kzalloc(sizeof(*parser), GFP_KERNEL);
> >> + if (!parser)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(&parser->parser);
> >> + parser->func = func;
> >> +
> >> + list_add_tail(&parser->parser, &dependency_parsers);
> >
> > We're modifying a global list here. Any locking needed? RCU? Whatever?
>
> Oops.
>
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_remove_dependency_parser - unregister dependency parser
> >> + * @func: Function that was to be called to find out dependencies of a node
> >> + */
> >> +void fwnode_remove_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser, *tmp;
> >> +
> >> + list_for_each_entry_safe(parser, tmp, &dependency_parsers, parser) {
> >> + if (parser->func = func) {
> >> + list_del(&parser->parser);
> >> + kfree(parser);
> >> + return;
> >> + }
> >> + }
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_get_dependencies - find out what dependencies a firmware node has
> >> + * @fwnode: firmware node to find its dependencies
> >> + * @deps: list of struct fwnode_dependency in which dependencies will be placed
> >> + */
> >> +void fwnode_get_dependencies(struct fwnode_handle *fwnode,
> >> + struct list_head *deps)
> >> +{
> >> + struct dependency_parser *parser;
> >> + struct fwnode_handle *child;
> >> +
> >> + list_for_each_entry(parser, &dependency_parsers, parser)
> >> + parser->func(fwnode, deps);
> >> +
> >> + /* Some device nodes will have dependencies in non-device sub-nodes */
> >> + fwnode_for_each_child_node(fwnode, child)
> >> + if (!fwnode_property_present(child, "compatible"))
> >
> > This is a blatant OF-ism. We need to think about a generic way to express that.
>
> My impression from reading the existing usage of fwnode in gpiolib and
> the examples in the link below was that we were going to share the
> bindings between DT and ACPI. Doesn't that extend to the meaning of
> the compatible property?
>
> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Not entirely.
An ACPI device object without the "compatible" property may still represent a valid
device (and usually does), so it is not enough to check whether or not the "compatible"
property is present for that in general.
Thanks,
Rafael
next prev parent reply other threads:[~2015-07-11 6:26 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 9:40 [PATCH v2 0/12] Discover and probe dependencies Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` [PATCH v2 01/12] device: property: delay device-driver matches Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 23:29 ` Rafael J. Wysocki
2015-07-01 23:29 ` Rafael J. Wysocki
2015-07-10 11:39 ` Tomeu Vizoso
2015-07-10 11:39 ` Tomeu Vizoso
2015-07-10 11:39 ` Tomeu Vizoso
2015-07-16 20:23 ` Mark Brown
2015-07-16 20:23 ` Mark Brown
2015-07-16 23:41 ` Rafael J. Wysocki
2015-07-16 23:41 ` Rafael J. Wysocki
2015-07-16 23:41 ` Rafael J. Wysocki
2015-07-17 0:06 ` Mark Brown
2015-07-17 0:06 ` Mark Brown
2015-07-01 9:40 ` [PATCH v2 02/12] device: property: find dependencies of a firmware node Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 23:36 ` Rafael J. Wysocki
2015-07-02 0:02 ` Rafael J. Wysocki
2015-07-10 13:14 ` [alsa-devel] " Tomeu Vizoso
2015-07-10 13:14 ` Tomeu Vizoso
2015-07-10 13:14 ` Tomeu Vizoso
2015-07-11 2:52 ` Rafael J. Wysocki [this message]
2015-07-11 2:52 ` Rafael J. Wysocki
2015-07-11 2:52 ` Rafael J. Wysocki
2015-07-01 9:40 ` [PATCH v2 03/12] string: Introduce strends() Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` [PATCH v2 04/12] gpio: register dependency parser for firmware nodes Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:40 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 05/12] gpu: host1x: " Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 06/12] backlight: Document consumers of backlight nodes Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 07/12] backlight: register dependency parser for firmware nodes Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 08/12] USB: EHCI: " Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 09/12] regulator: " Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-16 21:38 ` Mark Brown
2015-07-16 21:38 ` Mark Brown
2015-07-01 9:41 ` [PATCH v2 10/12] pwm: " Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` [PATCH v2 11/12] ASoC: tegra: " Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 17:38 ` Mark Brown
2015-07-01 17:38 ` Mark Brown
2015-07-13 12:10 ` [alsa-devel] " Tomeu Vizoso
2015-07-13 12:10 ` Tomeu Vizoso
2015-07-13 12:10 ` Tomeu Vizoso
2015-07-13 15:42 ` Mark Brown
2015-07-13 15:42 ` Mark Brown
2015-07-13 15:42 ` Mark Brown
2015-07-14 7:34 ` Tomeu Vizoso
2015-07-14 7:34 ` Tomeu Vizoso
2015-07-14 7:34 ` Tomeu Vizoso
2015-07-14 11:07 ` Mark Brown
2015-07-14 11:07 ` Mark Brown
2015-07-14 11:07 ` Mark Brown
2015-07-14 12:47 ` Tomeu Vizoso
2015-07-14 12:47 ` Tomeu Vizoso
2015-07-14 12:47 ` Tomeu Vizoso
2015-07-16 23:04 ` Mark Brown
2015-07-16 23:04 ` Mark Brown
2015-07-01 9:41 ` [PATCH v2 12/12] driver-core: probe dependencies before probing Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
2015-07-01 9:41 ` Tomeu Vizoso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4693466.kRRNMahPuB@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.