[PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Andy Shevchenko]

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

[PATCH v1 1/6] device property: export set_secondary_fwnode() to modules

[Andy Shevchenko]

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 <andriy.shevchenko@linux.intel.com>
---
 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

[PATCH v1 2/6] software node: Allow register and unregister software node groups

[Andy Shevchenko]

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 <andriy.shevchenko@linux.intel.com>
---
 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

[PATCH v1 3/6] platform/x86: intel_cht_int33fe: Convert software node array to group

[Andy Shevchenko]

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 <andriy.shevchenko@linux.intel.com>
---
 .../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

[PATCH v1 4/6] platform/x86: intel_cht_int33fe: Convert to use set_secondary_fwnode()

[Andy Shevchenko]

In one place we open coded set_secondary_fwnode().
Let's replace it with a helper.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 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

[PATCH v1 5/6] platform/x86: intel_cht_int33fe: Switch to use acpi_dev_hid_uid_match()

[Andy Shevchenko]

Since we have a generic helper, drop custom implementation in the driver.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 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

[PATCH v1 6/6] platform/x86: intel_cht_int33fe: Fix spelling issues

[Andy Shevchenko]

Fix spelling issues over the comments in the code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../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

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Hans de Goede]

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 <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>

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(-)
> 

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Andy Shevchenko]

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 <hdegoede@redhat.com>
> Tested-by: Hans de Goede <hdegoede@redhat.com>

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

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Heikki Krogerus]

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 <heikki.krogerus@linux.intel.com>

thanks,

-- 
heikki

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[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

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Rafael J. Wysocki]

On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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!

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 6:05 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> 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

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Rafael J. Wysocki]

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 <rafael@kernel.org> wrote:
> >
> > On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> 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!

Re: [PATCH v1 0/6] platform/x86: intel_cht_int33fe: clean up series

[Andy Shevchenko]

On Sat, Apr 18, 2020 at 10:43 PM Rafael J. Wysocki <rjw@rjwysocki.net> 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 <rafael@kernel.org> wrote:
> > > On Thu, Apr 16, 2020 at 4:17 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> 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