If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.
This helps the component master bind call to get triggered,
even if no component is registered for that particular master.
This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.
In such PCI device driver Load, if we use the component master for
waiting for few components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.
v2:
No Change.
Signed-off-by: Ramalingam C <[email protected]>
Suggested-by: Daniel Vetter <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Kate Stewart <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Philippe Ombredanne <[email protected]>
Cc: [email protected]
---
drivers/base/component.c | 30 ++++++++++++++++++++++++++++++
include/linux/component.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e8d676fad0c9..0ab36b2255ea 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
}
/*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr)
+{
+ struct component_match *match = *matchptr;
+
+ if (IS_ERR(match))
+ return;
+
+ if (match)
+ return;
+
+ match = devres_alloc(devm_component_match_release,
+ sizeof(*match), GFP_KERNEL);
+ if (!match) {
+ *matchptr = ERR_PTR(-ENOMEM);
+ return;
+ }
+
+ devres_add(master, match);
+
+ *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
* Add a component to be matched, with a release function.
*
* The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr);
static inline void component_match_add(struct device *master,
struct component_match **matchptr,
--
2.7.4
On Thu, Dec 13, 2018 at 09:31:06AM +0530, Ramalingam C wrote:
> If all the components associated to a component master is not added
> to the component framework due to the HW capability or Kconfig
> selection, component_match will be NULL at
> component_master_add_with_match().
>
> To avoid this, component_match_alloc() is added to the framework,
> to allcoate the struct component_match with zero associated components.
> Hence component master can be added with a component_match with zero
> associated components.
>
> This helps the component master bind call to get triggered,
> even if no component is registered for that particular master.
>
> This is meant for big PCI device drivers where small/optional
> features are external components, and based on usecases different
> combination of components are build as entire driver.
>
> In such PCI device driver Load, if we use the component master for
> waiting for few components(features) availability, only if they are
> supported by the underlying HW, then we need to allocate memory for
> component_match using the API introduced in this change before
> the call to component_master_add_with_match.
>
> v2:
> No Change.
>
> Signed-off-by: Ramalingam C <[email protected]>
> Suggested-by: Daniel Vetter <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Kate Stewart <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Philippe Ombredanne <[email protected]>
> Cc: [email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Greg, I expect the i915 feature that needs this will only land in 4.22.
I'm also not aware of anyone else using this (all the other component
users always use components). How do you want to get this landed?
I think either getting this into 4.21, or an ack for merging through drm
trees would work well for us.
-Daniel
> ---
> drivers/base/component.c | 30 ++++++++++++++++++++++++++++++
> include/linux/component.h | 2 ++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index e8d676fad0c9..0ab36b2255ea 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
> }
>
> /*
> + * Allocate the match without any component_match_array elements.
> + *
> + * This function is useful when the component master might end up
> + * registering itself without any matching components.
> + */
> +void component_match_alloc(struct device *master,
> + struct component_match **matchptr)
> +{
> + struct component_match *match = *matchptr;
> +
> + if (IS_ERR(match))
> + return;
> +
> + if (match)
> + return;
> +
> + match = devres_alloc(devm_component_match_release,
> + sizeof(*match), GFP_KERNEL);
> + if (!match) {
> + *matchptr = ERR_PTR(-ENOMEM);
> + return;
> + }
> +
> + devres_add(master, match);
> +
> + *matchptr = match;
> +}
> +EXPORT_SYMBOL(component_match_alloc);
> +
> +/*
> * Add a component to be matched, with a release function.
> *
> * The match array is first created or extended if necessary.
> diff --git a/include/linux/component.h b/include/linux/component.h
> index e71fbbbc74e2..3f6b420a58f8 100644
> --- a/include/linux/component.h
> +++ b/include/linux/component.h
> @@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
> struct component_match **matchptr,
> void (*release)(struct device *, void *),
> int (*compare)(struct device *, void *), void *compare_data);
> +void component_match_alloc(struct device *master,
> + struct component_match **matchptr);
>
> static inline void component_match_add(struct device *master,
> struct component_match **matchptr,
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Dec 19, 2018 at 02:42:45PM +0100, Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 09:31:06AM +0530, Ramalingam C wrote:
> > If all the components associated to a component master is not added
> > to the component framework due to the HW capability or Kconfig
> > selection, component_match will be NULL at
> > component_master_add_with_match().
> >
> > To avoid this, component_match_alloc() is added to the framework,
> > to allcoate the struct component_match with zero associated components.
> > Hence component master can be added with a component_match with zero
> > associated components.
> >
> > This helps the component master bind call to get triggered,
> > even if no component is registered for that particular master.
> >
> > This is meant for big PCI device drivers where small/optional
> > features are external components, and based on usecases different
> > combination of components are build as entire driver.
> >
> > In such PCI device driver Load, if we use the component master for
> > waiting for few components(features) availability, only if they are
> > supported by the underlying HW, then we need to allocate memory for
> > component_match using the API introduced in this change before
> > the call to component_master_add_with_match.
> >
> > v2:
> > No Change.
> >
> > Signed-off-by: Ramalingam C <[email protected]>
> > Suggested-by: Daniel Vetter <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: Kate Stewart <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: Philippe Ombredanne <[email protected]>
> > Cc: [email protected]
>
> Reviewed-by: Daniel Vetter <[email protected]>
>
> Greg, I expect the i915 feature that needs this will only land in 4.22.
> I'm also not aware of anyone else using this (all the other component
> users always use components). How do you want to get this landed?
>
> I think either getting this into 4.21, or an ack for merging through drm
> trees would work well for us.
I have no objection to you taking this through the drm tree. As I
really do not know the component code at all (that would be Russell
King), feel free to add my:
Acked-by: Greg Kroah-Hartman <[email protected]>
as it looks sane to me.
thanks,
greg k-h