On 05/01/2014 11:11 AM, Russell King - ARM Linux wrote:
On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
2. You replace calls of component_add and component_del with calls
to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,
specific_component_ops),
or
Russell King - ARM Linux wrote, On 01.05.2014 00:28:
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
The main problem with component framework is that componentization
significantly changes every driver and changes it in a way which is not
compatible with traditional drivers, so
On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
2. You replace calls of component_add and component_del with calls
to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,
specific_component_ops),
or interface_tracker_ifdown.
Thats all for components.
How does the
Generic framework for tracking internal interfaces
==
Summary
---
interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of
On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
Generic framework for tracking internal interfaces
==
Summary
---
interface_tracker is a generic framework which allows to track appearance
and disappearance of different
Hi Greg,
Thanks for comments. I CC Laurent, I hope it could be interesting for
him also.
Greg Kroah-Hartman wrote, On 30.04.2014 17:49:
On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
Generic framework for tracking internal interfaces
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
The main problem with component framework is that componentization
significantly changes every driver and changes it in a way which is not
compatible with traditional drivers, so devices which are intended to
work with
