All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v3 13/13] platform/x86: intel_cht_int33fe: Replacing the old connections with references
Date: Tue, 16 Apr 2019 23:35:36 +0200	[thread overview]
Message-ID: <a91a1d75-f224-9c9d-873a-f80467d2fb0c@redhat.com> (raw)
In-Reply-To: <20190412134122.82903-14-heikki.krogerus@linux.intel.com>

Hi,

On 12-04-19 15:41, Heikki Krogerus wrote:
> Now that the software nodes support references, and the
> device connection API support parsing fwnode references,
> replacing the old connection descriptions with software node
> references. Relying on device names when matching the
> connection would not have been possible to link the USB
> Type-C connector and the DisplayPort connector together, but
> with real references it's not problem.
> 
> The DisplayPort ACPI node is dag up, and the drivers own
> software node for the DisplayPort is set as the secondary
> node for it. The USB Type-C connector refers the software
> node, but it is now tied to the ACPI node, and therefore any
> device entry (struct drm_connector in practice) that the
> node combo is assigned to.
> 
> The USB role switch device does not have ACPI node, so we
> have to wait for the device to appear. Then we can simply
> assign our software node for the to the device.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

So as promised I've been testing this series and this commit
breaks type-c functionality on devices using this driver.

The problem is that typec_switch_get() and  typec_mux_get()
after this both return the same pointer, which is pointing
to the switch, so typec_mux_get() is returning the wrong
pointer.

This is not surprising since the references for both are
both pointing to the fwnode attached to the piusb30532 devices:

	args[0].fwnode = data->node[INT33FE_NODE_PI3USB30532];

So the class_find_device here:

static void *typec_switch_match(struct device_connection *con, int ep,
                                 void *data)
{
         struct device *dev;

         if (con->fwnode) {
                 if (con->id && !fwnode_property_present(con->fwnode, con->id))
                         return NULL;

                 dev = class_find_device(&typec_mux_class, NULL, con->fwnode,
                                         fwnode_match);
         } else {
                 dev = class_find_device(&typec_mux_class, NULL,
                                         con->endpoint[ep], name_match);
         }

         return dev ? to_typec_switch(dev) : ERR_PTR(-EPROBE_DEFER);
}

Simply returns the first typec_mux_class device registered.

I see 2 possible solutions to this problem:

1) Use separate typec_mux_class and typec_orientation_switch_class-es

2) Merge struct typec_switch and struct typec_mux into a single struct,
so that all typec_mux_class devices have the same memory layout, add
a subclass enum to this new merged struct and use that to identify
which of the typec_mux_class devices with the same fwnode pointer we
want.

Any other suggestions?

Regards,

Hans





> ---
>   drivers/platform/x86/intel_cht_int33fe.c | 93 +++++++++++++++++++-----
>   1 file changed, 76 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> index 7711667a3454..e6a1ea7f33af 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -39,15 +39,22 @@ enum {
>   	INT33FE_NODE_MAX,
>   };
>   
> +enum {
> +	INT33FE_REF_ORIENTATION,
> +	INT33FE_REF_MODE_MUX,
> +	INT33FE_REF_DISPLAYPORT,
> +	INT33FE_REF_ROLE_SWITCH,
> +	INT33FE_REF_MAX,
> +};
> +
>   struct cht_int33fe_data {
>   	struct i2c_client *max17047;
>   	struct i2c_client *fusb302;
>   	struct i2c_client *pi3usb30532;
> -	/* Contain a list-head must be per device */
> -	struct device_connection connections[4];
>   
>   	struct fwnode_handle *dp;
>   	struct fwnode_handle *node[INT33FE_NODE_MAX];
> +	struct software_node_reference *ref[INT33FE_REF_MAX];
>   };
>   
>   /*
> @@ -280,6 +287,65 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
>   	return ret;
>   }
>   
> +static void cht_int33fe_remove_references(struct cht_int33fe_data *data)
> +{
> +	int i;
> +
> +	for (i = 0; i < INT33FE_REF_MAX; i++)
> +		fwnode_remove_software_node_reference(data->ref[i]);
> +}
> +
> +static int cht_int33fe_add_references(struct cht_int33fe_data *data)
> +{
> +	struct fwnode_reference_args args[2] = { };
> +	struct software_node_reference *ref;
> +	struct fwnode_handle *con;
> +
> +	con = data->node[INT33FE_NODE_USB_CONNECTOR];
> +
> +	/* USB Type-C muxes */
> +	args[0].fwnode = data->node[INT33FE_NODE_PI3USB30532];
> +	args[1].fwnode = NULL;
> +
> +	ref = fwnode_create_software_node_reference(con, "orientation-switch",
> +						    args);
> +	if (IS_ERR(ref))
> +		return PTR_ERR(ref);
> +	data->ref[INT33FE_REF_ORIENTATION] = ref;
> +
> +	ref = fwnode_create_software_node_reference(con, "mode-switch", args);
> +	if (IS_ERR(ref)) {
> +		cht_int33fe_remove_references(data);
> +		return PTR_ERR(ref);
> +	}
> +	data->ref[INT33FE_REF_MODE_MUX] = ref;
> +
> +	/* USB role switch */
> +	args[0].fwnode = data->node[INT33FE_NODE_ROLE_SWITCH];
> +	args[1].fwnode = NULL;
> +
> +	ref = fwnode_create_software_node_reference(con, "usb-role-switch",
> +						    args);
> +	if (IS_ERR(ref)) {
> +		cht_int33fe_remove_references(data);
> +		return PTR_ERR(ref);
> +	}
> +	data->ref[INT33FE_REF_ROLE_SWITCH] = ref;
> +
> +	/* DisplayPort */
> +	args[0].fwnode = data->node[INT33FE_NODE_DISPLAYPORT];
> +	args[1].fwnode = NULL;
> +
> +	ref = fwnode_create_software_node_reference(con, "displayport", args);
> +	if (IS_ERR(ref)) {
> +		cht_int33fe_remove_references(data);
> +		return PTR_ERR(ref);
> +	}
> +	data->ref[INT33FE_REF_DISPLAYPORT] = ref;
> +
> +	return 0;
> +}
> +
>   static int cht_int33fe_probe(struct platform_device *pdev)
>   {
>   	struct device *dev = &pdev->dev;
> @@ -348,22 +414,14 @@ static int cht_int33fe_probe(struct platform_device *pdev)
>   	if (ret)
>   		return ret;
>   
> -	/* Work around BIOS bug, see comment on cht_int33fe_check_for_max17047 */
> -	ret = cht_int33fe_register_max17047(dev, data);
> +	ret = cht_int33fe_add_references(data);
>   	if (ret)
>   		goto out_remove_nodes;
>   
> -	data->connections[0].endpoint[0] = "port0";
> -	data->connections[0].endpoint[1] = "i2c-pi3usb30532-switch";
> -	data->connections[0].id = "orientation-switch";
> -	data->connections[1].endpoint[0] = "port0";
> -	data->connections[1].endpoint[1] = "i2c-pi3usb30532-mux";
> -	data->connections[1].id = "mode-switch";
> -	data->connections[2].endpoint[0] = "i2c-fusb302";
> -	data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
> -	data->connections[2].id = "usb-role-switch";
> -
> -	device_connections_add(data->connections);
> +	/* Work around BIOS bug, see comment on cht_int33fe_check_for_max17047 */
> +	ret = cht_int33fe_register_max17047(dev, data);
> +	if (ret)
> +		goto out_remove_references;
>   
>   	memset(&board_info, 0, sizeof(board_info));
>   	strlcpy(board_info.type, "typec_fusb302", I2C_NAME_SIZE);
> @@ -398,7 +456,8 @@ static int cht_int33fe_probe(struct platform_device *pdev)
>   out_unregister_max17047:
>   	i2c_unregister_device(data->max17047);
>   
> -	device_connections_remove(data->connections);
> +out_remove_references:
> +	cht_int33fe_remove_references(data);
>   
>   out_remove_nodes:
>   	cht_int33fe_remove_nodes(data);
> @@ -414,7 +473,7 @@ static int cht_int33fe_remove(struct platform_device *pdev)
>   	i2c_unregister_device(data->fusb302);
>   	i2c_unregister_device(data->max17047);
>   
> -	device_connections_remove(data->connections);
> +	cht_int33fe_remove_references(data);
>   	cht_int33fe_remove_nodes(data);
>   
>   	return 0;
> 

  reply	other threads:[~2019-04-16 21:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 13:41 [PATCH v3 00/13] Software fwnode references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 01/13] software node: Allow node creation without properties Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 02/13] software node: Simplify software_node_release() function Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 03/13] software node: Add support for references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 04/13] software node: Implement .get_reference_args fwnode operation Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 05/13] driver core: Add helper device_find_child_by_name() Heikki Krogerus
2019-04-25 19:46   ` Greg Kroah-Hartman
2019-04-12 13:41 ` [PATCH v3 06/13] ACPI / property: Don't limit named child node matching to data nodes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 07/13] device connection: Find connections also by checking the references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 08/13] usb: typec: Registering real device entries for the muxes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 09/13] platform/x86: intel_cht_int33fe: Register max17047 in its own function Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 10/13] platform/x86: intel_cht_int33fe: Provide software nodes for the devices Heikki Krogerus
2019-04-12 15:29   ` Andy Shevchenko
2019-04-12 13:41 ` [PATCH v3 11/13] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector Heikki Krogerus
2019-04-17  9:52   ` Hans de Goede
2019-05-08 11:30     ` Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 12/13] platform/x86: intel_cht_int33fe: Link with external dependencies using fwnodes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 13/13] platform/x86: intel_cht_int33fe: Replacing the old connections with references Heikki Krogerus
2019-04-16 21:35   ` Hans de Goede [this message]
2019-04-17  6:39     ` Heikki Krogerus
2019-04-17  9:19       ` Hans de Goede
2019-04-17  9:32         ` Heikki Krogerus
2019-04-17  9:52           ` Hans de Goede
2019-04-17 11:04             ` Heikki Krogerus
2019-04-17 11:15               ` Hans de Goede
2019-04-17 10:15           ` Hans de Goede
2019-04-17 10:44             ` Heikki Krogerus
2019-04-17 16:03               ` Hans de Goede
2019-04-17 16:03                 ` Hans de Goede
2019-05-08 11:28                 ` Heikki Krogerus
2019-04-17 21:14         ` Hans de Goede
2019-04-17 21:14           ` Hans de Goede
2019-05-08 11:40           ` Heikki Krogerus
2019-04-17  7:54 ` [PATCH v3 00/13] Software fwnode references Rafael J. Wysocki
2019-04-17  8:13   ` Heikki Krogerus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a91a1d75-f224-9c9d-873a-f80467d2fb0c@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.