| Message ID | 20230303143350.815623-1-treapking@chromium.org |
|---|---|
| Headers | show |
| Series | Register Type-C mode-switch in DP bridge endpoints | expand |
On Fri, Mar 03, 2023 at 10:33:41PM +0800, Pin-yen Lin wrote: > From: Prashant Malani <pmalani@chromium.org> > > When searching the device graph for device matches, check the > remote-endpoint itself for a match. > > Some drivers register devices for individual endpoints. This allows > the matcher code to evaluate those for a match too, instead > of only looking at the remote parent devices. This is required when a > device supports two mode switches in its endpoints, so we can't simply > register the mode switch with the parent node. OK! Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Signed-off-by: Prashant Malani <pmalani@chromium.org> > Signed-off-by: Pin-yen Lin <treapking@chromium.org> > > --- > > Changes in v13: > - Update the kernel doc of fwnode_connection_find_match > > Changes in v12: > - Check the availability of the device node in fwnode_graph_devcon_matches > - Ensured valid access to "matches" in fwnode_graph_devcon_matches > - Updated the documentation in fwnode_connection_find_match(es) > - Dropped collected tags due to the new changes > > Changes in v11: > - Added missing fwnode_handle_put in drivers/base/property.c > > Changes in v10: > - Collected Reviewed-by and Tested-by tags > > Changes in v6: > - New in v6 > > drivers/base/property.c | 31 ++++++++++++++++++++++++++----- > 1 file changed, 26 insertions(+), 5 deletions(-) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 083a95791d3b..4426ac2b16ca 100644 > --- a/drivers/base/property.c > +++ b/drivers/base/property.c > @@ -1243,6 +1243,23 @@ static unsigned int fwnode_graph_devcon_matches(const struct fwnode_handle *fwno > continue; > } > > + ret = match(node, con_id, data); > + fwnode_handle_put(node); > + if (ret) { > + if (matches) > + matches[count] = ret; > + count++; > + > + if (matches && count >= matches_len) > + break; > + } > + > + /* > + * Some drivers may register devices for endpoints. Check > + * the remote-endpoints for matches in addition to the remote > + * port parent. > + */ > + node = fwnode_graph_get_remote_endpoint(ep); > ret = match(node, con_id, data); > fwnode_handle_put(node); > if (ret) { > @@ -1293,8 +1310,11 @@ static unsigned int fwnode_devcon_matches(const struct fwnode_handle *fwnode, > * @match: Function to check and convert the connection description > * > * Find a connection with unique identifier @con_id between @fwnode and another > - * device node. @match will be used to convert the connection description to > - * data the caller is expecting to be returned. > + * device node. For fwnode graph connections, the graph endpoints are also > + * checked. @match will be used to convert the connection description to data > + * the caller is expecting to be returned. > + * > + * Return: The pointer to the matched node, or NULL on error. > */ > void *fwnode_connection_find_match(const struct fwnode_handle *fwnode, > const char *con_id, void *data, > @@ -1325,9 +1345,10 @@ EXPORT_SYMBOL_GPL(fwnode_connection_find_match); > * @matches_len: Length of @matches > * > * Find up to @matches_len connections with unique identifier @con_id between > - * @fwnode and other device nodes. @match will be used to convert the > - * connection description to data the caller is expecting to be returned > - * through the @matches array. > + * @fwnode and other device nodes. For fwnode graph connections, the graph > + * endpoints are also checked. @match will be used to convert the connection > + * description to data the caller is expecting to be returned through the > + * @matches array. > * If @matches is NULL @matches_len is ignored and the total number of resolved > * matches is returned. > * > -- > 2.40.0.rc0.216.gc4246ad0f0-goog >
On Fri, Mar 03, 2023 at 10:33:45PM +0800, Pin-yen Lin wrote: > The output port endpoints can be connected to USB-C connectors. > Running drm_of_find_panel_or_bridge() with such endpoints leads to > a continuous return value of -EPROBE_DEFER, even though there is > no panel present. > > To avoid this, check for the existence of a "mode-switch" property in > the port endpoint, and skip panel registration completely if so. ... > + port_node = of_graph_get_port_by_id(np, 1); > + count = typec_mode_switch_node_count(&port_node->fwnode); Do you need to drop reference count here? (I don't know myself, so, please check this) If no, patch LGTM. > + if (count) > + return 0;
On Fri, Mar 03, 2023 at 10:33:47PM +0800, Pin-yen Lin wrote: > Register USB Type-C mode switches when the "mode-switch" property and > relevant ports are available in Device Tree. Configure the crosspoint > switch based on the entered alternate mode for a specific Type-C > connector. > > Crosspoint switch can also be used for switching the output signal for > different orientations of a single USB Type-C connector, but the > orientation switch is not implemented yet. A TODO is added for this. ... > + ctx->port_data = devm_kcalloc( > + dev, switch_desc->num_typec_switches, > + sizeof(struct anx7625_typec_port_data), GFP_KERNEL); I believe I have commented on this (indentation)... > + ...and this (blank line). > + if (!ctx->port_data) { > + ret = -ENOMEM; > + goto unregister_mux; > + } ... > + ctx->port_data[i].orientation = (dp_lanes[0] / 2 == 0) ? > + TYPEC_ORIENTATION_REVERSE : TYPEC_ORIENTATION_NORMAL; I believe that this is an error prone check, you should rather do the opposite, i.e. ' % 2 == 0'.
HI Andy, On Mon, Mar 6, 2023 at 7:52 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Mar 03, 2023 at 10:33:45PM +0800, Pin-yen Lin wrote: > > The output port endpoints can be connected to USB-C connectors. > > Running drm_of_find_panel_or_bridge() with such endpoints leads to > > a continuous return value of -EPROBE_DEFER, even though there is > > no panel present. > > > > To avoid this, check for the existence of a "mode-switch" property in > > the port endpoint, and skip panel registration completely if so. > > ... > > > + port_node = of_graph_get_port_by_id(np, 1); > > + count = typec_mode_switch_node_count(&port_node->fwnode); > > Do you need to drop reference count here? > (I don't know myself, so, please check this) > > If no, patch LGTM. The helper completes the for-loop of fwnode_for_each_child_node, which drops the reference count whenever the next node is get. So we don't need drop the reference count here. > > > + if (count) > > + return 0; > > -- > With Best Regards, > Andy Shevchenko > > Best regards, Pin-yen
Hi Andy, Thanks for the review. On Mon, Mar 6, 2023 at 7:55 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Mar 03, 2023 at 10:33:47PM +0800, Pin-yen Lin wrote: > > Register USB Type-C mode switches when the "mode-switch" property and > > relevant ports are available in Device Tree. Configure the crosspoint > > switch based on the entered alternate mode for a specific Type-C > > connector. > > > > Crosspoint switch can also be used for switching the output signal for > > different orientations of a single USB Type-C connector, but the > > orientation switch is not implemented yet. A TODO is added for this. > > ... > > > + ctx->port_data = devm_kcalloc( > > + dev, switch_desc->num_typec_switches, > > + sizeof(struct anx7625_typec_port_data), GFP_KERNEL); > > I believe I have commented on this (indentation)... > > > + > > ...and this (blank line). Sorry for missing this one. I'll fix this in v14. > > > + if (!ctx->port_data) { > > + ret = -ENOMEM; > > + goto unregister_mux; > > + } > > ... > > > + ctx->port_data[i].orientation = (dp_lanes[0] / 2 == 0) ? > > + TYPEC_ORIENTATION_REVERSE : TYPEC_ORIENTATION_NORMAL; > > I believe that this is an error prone check, you should rather do the opposite, > i.e. ' % 2 == 0'. > The orientation should be TYPEC_ORIENTATION_REVERSE when the data-lanes value is 0/1, so ` / 2` is what I meant here. Though, after second thought, I think it would be clearer if I use `dp_lanes[0] < 2`. I'll update this in v14 as well. > -- > With Best Regards, > Andy Shevchenko > > Best regards, Pin-yen