Hi Rob,
thanks for this clean-up series! I was not aware how far the duplication
has spread over time.
On Fri, 2017-02-03 at 21:36 -0600, Rob Herring wrote:
> The OF graph API leaves too much of the graph walking to clients when
> in many cases the driver doesn't care about accessing the port or
On Mon, 2017-02-06 at 07:54 -0600, Rob Herring wrote:
> On Mon, Feb 6, 2017 at 4:32 AM, Philipp Zabel wrote:
> > Hi Rob,
> >
> > thanks for this clean-up series! I was not aware how far the duplication
> > has spread over time.
> >
> > On Fri, 2017-02-03 at 21:36 -0600,
On Fri, Feb 03, 2017 at 09:36:31PM -0600, Rob Herring wrote:
> The OF graph API leaves too much of the graph walking to clients when
> in many cases the driver doesn't care about accessing the port or
> endpoint nodes. The drivers typically just want the device connected via
> a particular graph
On Mon, Feb 6, 2017 at 4:32 AM, Philipp Zabel wrote:
> Hi Rob,
>
> thanks for this clean-up series! I was not aware how far the duplication
> has spread over time.
>
> On Fri, 2017-02-03 at 21:36 -0600, Rob Herring wrote:
>> The OF graph API leaves too much of the graph
On Mon, Feb 6, 2017 at 2:50 AM, Daniel Vetter wrote:
> On Fri, Feb 03, 2017 at 09:36:31PM -0600, Rob Herring wrote:
>> The OF graph API leaves too much of the graph walking to clients when
>> in many cases the driver doesn't care about accessing the port or
>> endpoint nodes. The
The OF graph API leaves too much of the graph walking to clients when
in many cases the driver doesn't care about accessing the port or
endpoint nodes. The drivers typically just want the device connected via
a particular graph connection. of_graph_get_remote_node provides this
functionality.
Hi Rob,
On 02/04/2017 05:36 AM, Rob Herring wrote:
> The OF graph API leaves too much of the graph walking to clients when
> in many cases the driver doesn't care about accessing the port or
> endpoint nodes. The drivers typically just want the device connected via
> a particular graph