When I started looking into the intel_cht_int33fe driver for an example of use
software node API, I have noticed that it's hard to get and code a bit messy.
Here is a clean up, main part of which is to introduce node groups and API to
register and unregister them. This and some pre-existing APIs can be used in
the driver.
So, because of cross-subsystem nature of this series, I may recommend to create
myself the immutable branch which can be pulled to Rafael's and Greg's trees
respectively. I'm also open for other proposals how to proceed.
Andy Shevchenko (6):
device property: export set_secondary_fwnode() to modules
software node: Allow register and unregister software node groups
platform/x86: intel_cht_int33fe: Convert software node array to group
platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()
platform/x86: intel_cht_int33fe: Switch to use
acpi_dev_hid_uid_match()
platform/x86: intel_cht_int33fe: Fix spelling issues
drivers/base/core.c | 1 +
drivers/base/swnode.c | 48 ++++++++
.../platform/x86/intel_cht_int33fe_typec.c | 106 +++++++++---------
include/linux/property.h | 3 +
4 files changed, 108 insertions(+), 50 deletions(-)
--
2.25.1
Sometimes it's more convenient to register a set of individual software nodes
grouped together. Add couple of functions for that.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/base/swnode.c | 48 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 3 +++
2 files changed, 51 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index de8d3543e8fe..2079937ddb51 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -726,6 +726,54 @@ void software_node_unregister_nodes(const struct software_node *nodes)
}
EXPORT_SYMBOL_GPL(software_node_unregister_nodes);
+/**
+ * software_node_register_node_group - Register a group of software nodes
+ * @node_group: NULL terminated array of software node pointers to be registered
+ *
+ * Register multiple software nodes at once.
+ */
+int software_node_register_node_group(const struct software_node **node_group)
+{
+ unsigned int i;
+ int ret;
+
+ if (!node_group)
+ return 0;
+
+ for (i = 0; node_group[i]; i++) {
+ ret = software_node_register(node_group[i]);
+ if (ret) {
+ software_node_unregister_node_group(node_group);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(software_node_register_node_group);
+
+/**
+ * software_node_unregister_node_group - Unregister a group of software nodes
+ * @node_group: NULL terminated array of software node pointers to be unregistered
+ *
+ * Unregister multiple software nodes at once.
+ */
+void software_node_unregister_node_group(const struct software_node **node_group)
+{
+ struct swnode *swnode;
+ unsigned int i;
+
+ if (!node_group)
+ return;
+
+ for (i = 0; node_group[i]; i++) {
+ swnode = software_node_to_swnode(node_group[i]);
+ if (swnode)
+ fwnode_remove_software_node(&swnode->fwnode);
+ }
+}
+EXPORT_SYMBOL_GPL(software_node_unregister_node_group);
+
/**
* software_node_register - Register static software node
* @node: The software node to be registered
diff --git a/include/linux/property.h b/include/linux/property.h
index d86de017c689..c7b5f3db36aa 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -440,6 +440,9 @@ software_node_find_by_name(const struct software_node *parent,
int software_node_register_nodes(const struct software_node *nodes);
void software_node_unregister_nodes(const struct software_node *nodes);
+int software_node_register_node_group(const struct software_node **node_group);
+void software_node_unregister_node_group(const struct software_node **node_group);
+
int software_node_register(const struct software_node *node);
int software_node_notify(struct device *dev, unsigned long action);
--
2.25.1
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/platform/x86/intel_cht_int33fe_typec.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe_typec.c b/drivers/platform/x86/intel_cht_int33fe_typec.c
index 904e75d39953..e89defb33067 100644
--- a/drivers/platform/x86/intel_cht_int33fe_typec.c
+++ b/drivers/platform/x86/intel_cht_int33fe_typec.c
@@ -40,16 +40,13 @@ static int cht_int33fe_check_for_max17047(struct device *dev, void *data)
{
struct i2c_client **max17047 = data;
struct acpi_device *adev;
- const char *hid;
adev = ACPI_COMPANION(dev);
if (!adev)
return 0;
- hid = acpi_device_hid(adev);
-
/* The MAX17047 ACPI node doesn't have an UID, so we don't check that */
- if (strcmp(hid, "MAX17047"))
+ if (!acpi_dev_hid_uid_match(adev, "MAX17047", NULL))
return 0;
*max17047 = to_i2c_client(dev);
--
2.25.1
In one place we open coded set_secondary_fwnode().
Let's replace it with a helper.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/platform/x86/intel_cht_int33fe_typec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe_typec.c b/drivers/platform/x86/intel_cht_int33fe_typec.c
index 0f547d35c90d..904e75d39953 100644
--- a/drivers/platform/x86/intel_cht_int33fe_typec.c
+++ b/drivers/platform/x86/intel_cht_int33fe_typec.c
@@ -239,8 +239,7 @@ cht_int33fe_register_max17047(struct device *dev, struct cht_int33fe_data *data)
i2c_for_each_dev(&max17047, cht_int33fe_check_for_max17047);
if (max17047) {
/* Pre-existing i2c-client for the max17047, add device-props */
- fwnode->secondary = ERR_PTR(-ENODEV);
- max17047->dev.fwnode->secondary = fwnode;
+ set_secondary_fwnode(&max17047->dev, fwnode);
/* And re-probe to get the new device-props applied. */
ret = device_reprobe(&max17047->dev);
if (ret)
--
2.25.1
Some drivers when compiled as modules may need to set secondary firmware node.
Export set_secondary_fwnode() to make it possible without code duplication.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/base/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index dbb0f9130f42..11ab8fa7bd00 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3738,6 +3738,7 @@ void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode)
else
dev->fwnode = fwnode;
}
+EXPORT_SYMBOL_GPL(set_secondary_fwnode);
/**
* device_set_of_node_from_dev - reuse device-tree node of another device
--
2.25.1
Code looks and be read cleaner when software nodes are defined individually.
Convert software node array to a group in order to achieve above.
While here, switch struct initializers to C99 standard.
Signed-off-by: Andy Shevchenko <[email protected]>
---
.../platform/x86/intel_cht_int33fe_typec.c | 78 +++++++++++--------
1 file changed, 44 insertions(+), 34 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe_typec.c b/drivers/platform/x86/intel_cht_int33fe_typec.c
index 04138215956b..0f547d35c90d 100644
--- a/drivers/platform/x86/intel_cht_int33fe_typec.c
+++ b/drivers/platform/x86/intel_cht_int33fe_typec.c
@@ -21,21 +21,13 @@
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/usb/pd.h>
#include "intel_cht_int33fe_common.h"
-enum {
- INT33FE_NODE_FUSB302,
- INT33FE_NODE_MAX17047,
- INT33FE_NODE_PI3USB30532,
- INT33FE_NODE_DISPLAYPORT,
- INT33FE_NODE_USB_CONNECTOR,
- INT33FE_NODE_MAX,
-};
-
/*
* Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
* the max17047 both through the INT33FE ACPI device (it is right there
@@ -66,11 +58,16 @@ static int cht_int33fe_check_for_max17047(struct device *dev, void *data)
static const char * const max17047_suppliers[] = { "bq24190-charger" };
-static const struct property_entry max17047_props[] = {
+static const struct property_entry max17047_properties[] = {
PROPERTY_ENTRY_STRING_ARRAY("supplied-from", max17047_suppliers),
{ }
};
+static const struct software_node max17047_node = {
+ .name = "max17047",
+ .properties = max17047_properties,
+};
+
/*
* We are not using inline property here because those are constant,
* and we need to adjust this one at runtime to point to real
@@ -80,12 +77,17 @@ static struct software_node_ref_args fusb302_mux_refs[] = {
{ .node = NULL },
};
-static const struct property_entry fusb302_props[] = {
+static const struct property_entry fusb302_properties[] = {
PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
PROPERTY_ENTRY_REF_ARRAY("usb-role-switch", fusb302_mux_refs),
{ }
};
+static const struct software_node fusb302_node = {
+ .name = "fusb302",
+ .properties = fusb302_properties,
+};
+
#define PDO_FIXED_FLAGS \
(PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP | PDO_FIXED_USB_COMM)
@@ -98,31 +100,40 @@ static const u32 snk_pdo[] = {
PDO_VAR(5000, 12000, 3000),
};
-static const struct software_node nodes[];
+static const struct software_node pi3usb30532_node = {
+ .name = "pi3usb30532",
+};
+
+static const struct software_node displayport_node = {
+ .name = "displayport",
+};
-static const struct property_entry usb_connector_props[] = {
+static const struct property_entry usb_connector_properties[] = {
PROPERTY_ENTRY_STRING("data-role", "dual"),
PROPERTY_ENTRY_STRING("power-role", "dual"),
PROPERTY_ENTRY_STRING("try-power-role", "sink"),
PROPERTY_ENTRY_U32_ARRAY("source-pdos", src_pdo),
PROPERTY_ENTRY_U32_ARRAY("sink-pdos", snk_pdo),
PROPERTY_ENTRY_U32("op-sink-microwatt", 2500000),
- PROPERTY_ENTRY_REF("orientation-switch",
- &nodes[INT33FE_NODE_PI3USB30532]),
- PROPERTY_ENTRY_REF("mode-switch",
- &nodes[INT33FE_NODE_PI3USB30532]),
- PROPERTY_ENTRY_REF("displayport",
- &nodes[INT33FE_NODE_DISPLAYPORT]),
+ PROPERTY_ENTRY_REF("orientation-switch", &pi3usb30532_node),
+ PROPERTY_ENTRY_REF("mode-switch", &pi3usb30532_node),
+ PROPERTY_ENTRY_REF("displayport", &displayport_node),
{ }
};
-static const struct software_node nodes[] = {
- { "fusb302", NULL, fusb302_props },
- { "max17047", NULL, max17047_props },
- { "pi3usb30532" },
- { "displayport" },
- { "connector", &nodes[0], usb_connector_props },
- { }
+static const struct software_node usb_connector_node = {
+ .name = "connector",
+ .parent = &fusb302_node,
+ .properties = usb_connector_properties,
+};
+
+static const struct software_node *node_group[] = {
+ &fusb302_node,
+ &max17047_node,
+ &pi3usb30532_node,
+ &displayport_node,
+ &usb_connector_node,
+ NULL
};
static int cht_int33fe_setup_dp(struct cht_int33fe_data *data)
@@ -130,7 +141,7 @@ static int cht_int33fe_setup_dp(struct cht_int33fe_data *data)
struct fwnode_handle *fwnode;
struct pci_dev *pdev;
- fwnode = software_node_fwnode(&nodes[INT33FE_NODE_DISPLAYPORT]);
+ fwnode = software_node_fwnode(&displayport_node);
if (!fwnode)
return -ENODEV;
@@ -155,11 +166,10 @@ static int cht_int33fe_setup_dp(struct cht_int33fe_data *data)
static void cht_int33fe_remove_nodes(struct cht_int33fe_data *data)
{
- software_node_unregister_nodes(nodes);
+ software_node_unregister_node_group(node_group);
if (fusb302_mux_refs[0].node) {
- fwnode_handle_put(
- software_node_fwnode(fusb302_mux_refs[0].node));
+ fwnode_handle_put(software_node_fwnode(fusb302_mux_refs[0].node));
fusb302_mux_refs[0].node = NULL;
}
@@ -192,7 +202,7 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
*/
fusb302_mux_refs[0].node = mux_ref_node;
- ret = software_node_register_nodes(nodes);
+ ret = software_node_register_node_group(node_group);
if (ret)
return ret;
@@ -222,7 +232,7 @@ cht_int33fe_register_max17047(struct device *dev, struct cht_int33fe_data *data)
struct fwnode_handle *fwnode;
int ret;
- fwnode = software_node_fwnode(&nodes[INT33FE_NODE_MAX17047]);
+ fwnode = software_node_fwnode(&max17047_node);
if (!fwnode)
return -ENODEV;
@@ -294,7 +304,7 @@ int cht_int33fe_typec_probe(struct cht_int33fe_data *data)
if (ret)
goto out_remove_nodes;
- fwnode = software_node_fwnode(&nodes[INT33FE_NODE_FUSB302]);
+ fwnode = software_node_fwnode(&fusb302_node);
if (!fwnode) {
ret = -ENODEV;
goto out_unregister_max17047;
@@ -312,7 +322,7 @@ int cht_int33fe_typec_probe(struct cht_int33fe_data *data)
goto out_unregister_max17047;
}
- fwnode = software_node_fwnode(&nodes[INT33FE_NODE_PI3USB30532]);
+ fwnode = software_node_fwnode(&pi3usb30532_node);
if (!fwnode) {
ret = -ENODEV;
goto out_unregister_fusb302;
--
2.25.1
Fix spelling issues over the comments in the code.
Signed-off-by: Andy Shevchenko <[email protected]>
---
.../platform/x86/intel_cht_int33fe_typec.c | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/intel_cht_int33fe_typec.c b/drivers/platform/x86/intel_cht_int33fe_typec.c
index e89defb33067..48638d1c56e5 100644
--- a/drivers/platform/x86/intel_cht_int33fe_typec.c
+++ b/drivers/platform/x86/intel_cht_int33fe_typec.c
@@ -6,14 +6,14 @@
*
* Some Intel Cherry Trail based device which ship with Windows 10, have
* this weird INT33FE ACPI device with a CRS table with 4 I2cSerialBusV2
- * resources, for 4 different chips attached to various i2c busses:
- * 1. The Whiskey Cove pmic, which is also described by the INT34D3 ACPI device
+ * resources, for 4 different chips attached to various I²C buses:
+ * 1. The Whiskey Cove PMIC, which is also described by the INT34D3 ACPI device
* 2. Maxim MAX17047 Fuel Gauge Controller
* 3. FUSB302 USB Type-C Controller
* 4. PI3USB30532 USB switch
*
* So this driver is a stub / pseudo driver whose only purpose is to
- * instantiate i2c-clients for chips 2 - 4, so that standard i2c drivers
+ * instantiate I²C clients for chips 2 - 4, so that standard I²C drivers
* for these chips can bind to the them.
*/
@@ -29,11 +29,11 @@
#include "intel_cht_int33fe_common.h"
/*
- * Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
+ * Grrr, I severely dislike buggy BIOS-es. At least one BIOS enumerates
* the max17047 both through the INT33FE ACPI device (it is right there
* in the resources table) as well as through a separate MAX17047 device.
*
- * These helpers are used to work around this by checking if an i2c-client
+ * These helpers are used to work around this by checking if an I²C client
* for the max17047 has already been registered.
*/
static int cht_int33fe_check_for_max17047(struct device *dev, void *data)
@@ -235,9 +235,9 @@ cht_int33fe_register_max17047(struct device *dev, struct cht_int33fe_data *data)
i2c_for_each_dev(&max17047, cht_int33fe_check_for_max17047);
if (max17047) {
- /* Pre-existing i2c-client for the max17047, add device-props */
+ /* Pre-existing I²C client for the max17047, add device properties */
set_secondary_fwnode(&max17047->dev, fwnode);
- /* And re-probe to get the new device-props applied. */
+ /* And re-probe to get the new device properties applied */
ret = device_reprobe(&max17047->dev);
if (ret)
dev_warn(dev, "Reprobing max17047 error: %d\n", ret);
@@ -272,7 +272,7 @@ int cht_int33fe_typec_probe(struct cht_int33fe_data *data)
* must be registered before the fusb302 is instantiated, otherwise
* it will end up with a dummy-regulator.
* Note "cht_wc_usb_typec_vbus" comes from the regulator_init_data
- * which is defined in i2c-cht-wc.c from where the bq24292i i2c-client
+ * which is defined in i2c-cht-wc.c from where the bq24292i I²C client
* gets instantiated. We use regulator_get_optional here so that we
* don't end up getting a dummy-regulator ourselves.
*/
@@ -283,7 +283,7 @@ int cht_int33fe_typec_probe(struct cht_int33fe_data *data)
}
regulator_put(regulator);
- /* The FUSB302 uses the irq at index 1 and is the only irq user */
+ /* The FUSB302 uses the IRQ at index 1 and is the only IRQ user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
if (fusb302_irq != -EPROBE_DEFER)
@@ -295,7 +295,7 @@ int cht_int33fe_typec_probe(struct cht_int33fe_data *data)
if (ret)
return ret;
- /* Work around BIOS bug, see comment on cht_int33fe_check_for_max17047 */
+ /* Work around BIOS bug, see comment on cht_int33fe_check_for_max17047() */
ret = cht_int33fe_register_max17047(dev, data);
if (ret)
goto out_remove_nodes;
--
2.25.1
Hi,
On 4/8/20 6:09 PM, Andy Shevchenko wrote:
> When I started looking into the intel_cht_int33fe driver for an example of use
> software node API, I have noticed that it's hard to get and code a bit messy.
> Here is a clean up, main part of which is to introduce node groups and API to
> register and unregister them. This and some pre-existing APIs can be used in
> the driver.
>
> So, because of cross-subsystem nature of this series, I may recommend to create
> myself the immutable branch which can be pulled to Rafael's and Greg's trees
> respectively. I'm also open for other proposals how to proceed.
The series looks good to me and I've also tested it on one of
the devices using the intel_cht_int33fe driver and everything seems
to work fine, so for the whole series:
Reviewed-by: Hans de Goede <[email protected]>
Tested-by: Hans de Goede <[email protected]>
Regards,
Hans
>
> Andy Shevchenko (6):
> device property: export set_secondary_fwnode() to modules
> software node: Allow register and unregister software node groups
> platform/x86: intel_cht_int33fe: Convert software node array to group
> platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()
> platform/x86: intel_cht_int33fe: Switch to use
> acpi_dev_hid_uid_match()
> platform/x86: intel_cht_int33fe: Fix spelling issues
>
> drivers/base/core.c | 1 +
> drivers/base/swnode.c | 48 ++++++++
> .../platform/x86/intel_cht_int33fe_typec.c | 106 +++++++++---------
> include/linux/property.h | 3 +
> 4 files changed, 108 insertions(+), 50 deletions(-)
>
On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
> When I started looking into the intel_cht_int33fe driver for an example of use
> software node API, I have noticed that it's hard to get and code a bit messy.
> Here is a clean up, main part of which is to introduce node groups and API to
> register and unregister them. This and some pre-existing APIs can be used in
> the driver.
>
> So, because of cross-subsystem nature of this series, I may recommend to create
> myself the immutable branch which can be pulled to Rafael's and Greg's trees
> respectively. I'm also open for other proposals how to proceed.
>
> Andy Shevchenko (6):
> device property: export set_secondary_fwnode() to modules
> software node: Allow register and unregister software node groups
> platform/x86: intel_cht_int33fe: Convert software node array to group
> platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()
> platform/x86: intel_cht_int33fe: Switch to use
> acpi_dev_hid_uid_match()
> platform/x86: intel_cht_int33fe: Fix spelling issues
>
> drivers/base/core.c | 1 +
> drivers/base/swnode.c | 48 ++++++++
> .../platform/x86/intel_cht_int33fe_typec.c | 106 +++++++++---------
> include/linux/property.h | 3 +
> 4 files changed, 108 insertions(+), 50 deletions(-)
These are all OK by me. FWIW:
Reviewed-by: Heikki Krogerus <[email protected]>
thanks,
--
heikki
On Tue, Apr 14, 2020 at 02:08:42PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/8/20 6:09 PM, Andy Shevchenko wrote:
> > When I started looking into the intel_cht_int33fe driver for an example of use
> > software node API, I have noticed that it's hard to get and code a bit messy.
> > Here is a clean up, main part of which is to introduce node groups and API to
> > register and unregister them. This and some pre-existing APIs can be used in
> > the driver.
> >
> > So, because of cross-subsystem nature of this series, I may recommend to create
> > myself the immutable branch which can be pulled to Rafael's and Greg's trees
> > respectively. I'm also open for other proposals how to proceed.
>
> The series looks good to me and I've also tested it on one of
> the devices using the intel_cht_int33fe driver and everything seems
> to work fine, so for the whole series:
>
> Reviewed-by: Hans de Goede <[email protected]>
> Tested-by: Hans de Goede <[email protected]>
Thank you, Hans!
I'll wait for Greg and Rafael to conclude how to proceed with it and maybe for
Heikki's response as well.
> > Andy Shevchenko (6):
> > device property: export set_secondary_fwnode() to modules
> > software node: Allow register and unregister software node groups
> > platform/x86: intel_cht_int33fe: Convert software node array to group
> > platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()
> > platform/x86: intel_cht_int33fe: Switch to use
> > acpi_dev_hid_uid_match()
> > platform/x86: intel_cht_int33fe: Fix spelling issues
> >
> > drivers/base/core.c | 1 +
> > drivers/base/swnode.c | 48 ++++++++
> > .../platform/x86/intel_cht_int33fe_typec.c | 106 +++++++++---------
> > include/linux/property.h | 3 +
> > 4 files changed, 108 insertions(+), 50 deletions(-)
--
With Best Regards,
Andy Shevchenko
On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
> When I started looking into the intel_cht_int33fe driver for an example of use
> software node API, I have noticed that it's hard to get and code a bit messy.
> Here is a clean up, main part of which is to introduce node groups and API to
> register and unregister them. This and some pre-existing APIs can be used in
> the driver.
>
> So, because of cross-subsystem nature of this series, I may recommend to create
> myself the immutable branch which can be pulled to Rafael's and Greg's trees
> respectively. I'm also open for other proposals how to proceed.
Greg, Rafael,
any suggestion how to proceed with this series?
(It has been reviewed and tested).
> Andy Shevchenko (6):
> device property: export set_secondary_fwnode() to modules
> software node: Allow register and unregister software node groups
> platform/x86: intel_cht_int33fe: Convert software node array to group
> platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()
> platform/x86: intel_cht_int33fe: Switch to use
> acpi_dev_hid_uid_match()
> platform/x86: intel_cht_int33fe: Fix spelling issues
>
> drivers/base/core.c | 1 +
> drivers/base/swnode.c | 48 ++++++++
> .../platform/x86/intel_cht_int33fe_typec.c | 106 +++++++++---------
> include/linux/property.h | 3 +
> 4 files changed, 108 insertions(+), 50 deletions(-)
>
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
> > When I started looking into the intel_cht_int33fe driver for an example of use
> > software node API, I have noticed that it's hard to get and code a bit messy.
> > Here is a clean up, main part of which is to introduce node groups and API to
> > register and unregister them. This and some pre-existing APIs can be used in
> > the driver.
> >
> > So, because of cross-subsystem nature of this series, I may recommend to create
> > myself the immutable branch which can be pulled to Rafael's and Greg's trees
> > respectively. I'm also open for other proposals how to proceed.
>
> Greg, Rafael,
> any suggestion how to proceed with this series?
>
> (It has been reviewed and tested).
You can merge them through platform/x86 as far as I'm concerned, or
please let me know if you want me to pick them up.
Cheers!
On Thu, Apr 16, 2020 at 6:05 PM Rafael J. Wysocki <[email protected]> wrote:
>
> On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
> > > When I started looking into the intel_cht_int33fe driver for an example of use
> > > software node API, I have noticed that it's hard to get and code a bit messy.
> > > Here is a clean up, main part of which is to introduce node groups and API to
> > > register and unregister them. This and some pre-existing APIs can be used in
> > > the driver.
> > >
> > > So, because of cross-subsystem nature of this series, I may recommend to create
> > > myself the immutable branch which can be pulled to Rafael's and Greg's trees
> > > respectively. I'm also open for other proposals how to proceed.
> >
> > Greg, Rafael,
> > any suggestion how to proceed with this series?
> >
> > (It has been reviewed and tested).
>
> You can merge them through platform/x86 as far as I'm concerned, or
> please let me know if you want me to pick them up.
Works for me, but I would like to ask for formal Ack tag.
Thanks!
--
With Best Regards,
Andy Shevchenko
On Thursday, April 16, 2020 5:21:15 PM CEST Andy Shevchenko wrote:
> On Thu, Apr 16, 2020 at 6:05 PM Rafael J. Wysocki <[email protected]> wrote:
> >
> > On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> > <[email protected]> wrote:
> > >
> > > On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
> > > > When I started looking into the intel_cht_int33fe driver for an example of use
> > > > software node API, I have noticed that it's hard to get and code a bit messy.
> > > > Here is a clean up, main part of which is to introduce node groups and API to
> > > > register and unregister them. This and some pre-existing APIs can be used in
> > > > the driver.
> > > >
> > > > So, because of cross-subsystem nature of this series, I may recommend to create
> > > > myself the immutable branch which can be pulled to Rafael's and Greg's trees
> > > > respectively. I'm also open for other proposals how to proceed.
> > >
> > > Greg, Rafael,
> > > any suggestion how to proceed with this series?
> > >
> > > (It has been reviewed and tested).
> >
> > You can merge them through platform/x86 as far as I'm concerned, or
> > please let me know if you want me to pick them up.
>
> Works for me, but I would like to ask for formal Ack tag.
I'm guessing that you talk about the first two patches, right?
Please feel free to add my ACK to both, thanks!
On Sat, Apr 18, 2020 at 10:43 PM Rafael J. Wysocki <[email protected]> wrote:
> On Thursday, April 16, 2020 5:21:15 PM CEST Andy Shevchenko wrote:
> > On Thu, Apr 16, 2020 at 6:05 PM Rafael J. Wysocki <[email protected]> wrote:
> > > On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > > On Wed, Apr 08, 2020 at 07:09:00PM +0300, Andy Shevchenko wrote:
...
> > > > Greg, Rafael,
> > > > any suggestion how to proceed with this series?
> > > >
> > > > (It has been reviewed and tested).
> > >
> > > You can merge them through platform/x86 as far as I'm concerned, or
> > > please let me know if you want me to pick them up.
> >
> > Works for me, but I would like to ask for formal Ack tag.
>
> I'm guessing that you talk about the first two patches, right?
Correct!
> Please feel free to add my ACK to both, thanks!
Thanks!
--
With Best Regards,
Andy Shevchenko