This series introduces a level of indirection between the controller's view of
a typec_mux/switch and the implementation and then expands that to support
multiple drivers.
This is needed in order to support devices such as the Qualcomm Snapdragon 888
HDK, which does muxing and orientation handling in the QMP (USB+DP) PHY and SBU
muxing in the external FSA4480 chip.
Additionally integration of typec mux and switch in the QMP PHY is included in
the series, as is the new FSA4480 driver. This is done to deal with the
renaming of the driver-side typec_mux -> typec_mux_dev.
Bjorn Andersson (8):
dt-bindings: phy: qcom,qmp-usb3-dp: Add altmode/switch properties
phy: qcom-qmp: Register typec mux and orientation switch
device property: Helper to match multiple connections
device property: Use multi-connection matchers for single case
typec: mux: Introduce indirection
typec: mux: Allow multiple mux_devs per mux
dt-bindings: usb: Add binding for fcs,fsa4480
usb: typec: mux: Add On Semi fsa4480 driver
.../bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 14 +
.../devicetree/bindings/usb/fcs,fsa4480.yaml | 72 +++++
drivers/base/property.c | 83 ++++--
drivers/phy/qualcomm/phy-qcom-qmp.c | 176 ++++++++++--
drivers/usb/typec/bus.c | 2 +-
drivers/usb/typec/mux.c | 257 +++++++++++++-----
drivers/usb/typec/mux.h | 12 +-
drivers/usb/typec/mux/Kconfig | 9 +
drivers/usb/typec/mux/Makefile | 1 +
drivers/usb/typec/mux/fsa4480.c | 220 +++++++++++++++
drivers/usb/typec/mux/intel_pmc_mux.c | 8 +-
drivers/usb/typec/mux/pi3usb30532.c | 8 +-
include/linux/property.h | 5 +
include/linux/usb/typec_mux.h | 22 +-
14 files changed, 762 insertions(+), 127 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
create mode 100644 drivers/usb/typec/mux/fsa4480.c
--
2.33.1
The QMP block deals with orientation switching and altmode switching
between USB and DisplayPort. Add the necessary properties to the binding
to allow it to be connected to a TypeC controller and trigger these
operations.
Signed-off-by: Bjorn Andersson <redacted>
---
.../bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
@@ -77,6 +77,20 @@ properties:description:Phandle to a regulator supply to any specific refclk pll block.+port:+$ref:/schemas/graph.yaml#/properties/port+description:+A port node to link the QMP to a TypeC controller for the purpose of+handling altmode muxing and orientation switching.++mode-switch:+description:Flag the port as possible handle of altmode switching+type:boolean++orientation-switch:+description:Flag the port as possible handler of orientation switching+type:boolean+#Required nodes:patternProperties:"^usb3-phy@[0-9a-f]+$":
The QMP PHY handles muxing of USB vs DisplayPort, as well as orientation
switching of the SuperSpeed lanes. So register typec handlers for the
two types.
The TypeC mux allows switching between four lanes of DisplayPort and a
mixed USB+DP combination. This makes it possible to reach resolutions
that requires 4 lanes.
The TypeC switch allows switching the SuperSpeed pins and have been
tested with both 2 and 4 lane DisplayPort.
It's possible that in the USB mode the DP_MODE should be disabled, but
this is left untouched.
Signed-off-by: Bjorn Andersson <redacted>
---
My suggestion is that if/once this patch is deemed acceptable the PHY
maintainers could create a immutable branch/tag which can be merged into the
PHY tree as well as the USB tree.
drivers/phy/qualcomm/phy-qcom-qmp.c | 176 +++++++++++++++++++++++++---
1 file changed, 158 insertions(+), 18 deletions(-)
@@ -5891,7 +6010,15 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev)returnret;}-num=of_get_available_child_count(dev->of_node);+ret=qcom_qmp_phy_typec_register(qmp,cfg);+if(ret)+returnret;++num=0;+for_each_available_child_of_node(dev->of_node,child){+if(!of_node_name_eq(child,"port"))+num++;+}/* do we have a rogue child node ? */if(num>expected_phys)return-EINVAL;
The newly introduced helpers for searching for matches in the case of
multiple connections can be resused by the single-connection case, so do
this to save some duplication.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 53 ++++-------------------------------------
1 file changed, 5 insertions(+), 48 deletions(-)
The Fairchild/ON Semiconductor FSA4480 Analog Audio switch is used in
USB Type-C configurations for muxing analog audio onto the USB
connector, and as such used to control the SBU signals for altmodes such
as DisplayPort.
Add a binding for this hardware block.
Signed-off-by: Bjorn Andersson <redacted>
---
.../devicetree/bindings/usb/fcs,fsa4480.yaml | 72 +++++++++++++++++++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
@@ -0,0 +1,72 @@+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause+%YAML1.2+---+$id:"http://devicetree.org/schemas/usb/fcs,fsa4480.yaml#"+$schema:"http://devicetree.org/meta-schemas/core.yaml#"++title:ON Semiconductor Analog Audio Switch++maintainers:+-Bjorn Andersson <bjorn.andersson@linaro.org>++properties:+compatible:+enum:+-fcs,fsa4480++reg:+maxItems:1++interrupts:+maxItems:1++vcc-supply:+description:power supply (2.7V-5.5V)++mode-switch:+description:Flag the port as possible handle of altmode switching+type:boolean++orientation-switch:+description:Flag the port as possible handler of orientation switching+type:boolean++port:+$ref:/schemas/graph.yaml#/properties/port+description:+A port node to link the FSA4480 to a TypeC controller for the purpose of+handling altmode muxing and orientation switching.++required:+-compatible+-reg+-port++additionalProperties:false++examples:+-|+#include <dt-bindings/interrupt-controller/irq.h>+i2c13 {+#address-cells = <1>;+#size-cells = <0>;++fsa4480@42 {+compatible = "fcs,fsa4480";+reg = <0x42>;++interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>;++vcc-supply = <&vreg_bob>;++mode-switch;+orientation-switch;++port {+fsa4480_ept:endpoint {+remote-endpoint = <&typec_controller>;+};+};+};+};+...
The ON Semiconductor FSA4480 is a USB Type-C port multimedia switch with
support for analog audio headsets. It allows sharing a common USB Type-C
port to pass USB2.0 signal, analog audio, sideband use wires and analog
microphone signal.
Due to lacking upstream audio support for testing, the audio muxing is
left untouched, but implementation of muxing the SBU lines is provided
as a pair of TypeC mux and switch devices. This provides the necessary
support for enabling the DisplayPort altmode on devices with this
circuit.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/usb/typec/mux/Kconfig | 9 ++
drivers/usb/typec/mux/Makefile | 1 +
drivers/usb/typec/mux/fsa4480.c | 220 ++++++++++++++++++++++++++++++++
3 files changed, 230 insertions(+)
create mode 100644 drivers/usb/typec/mux/fsa4480.c
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
In the Qualcomm platforms the USB/DP PHY handles muxing and orientation
switching of the SuperSpeed lines, but the SBU lines needs to be
connected and switched by external (to the SoC) hardware.
It's therefor necessary to be able to have the TypeC controller operate
multiple TypeC muxes and switches. Use the newly introduced indirection
object to handle this, to avoid having to taint the TypeC controllers
with knowledge about the downstream hardware configuration.
The max number of devs per indirection is set to 3, based on the number
of ports defined in the usb-c-connector binding.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/usb/typec/mux.c | 124 +++++++++++++++++++++++++++++++---------
1 file changed, 98 insertions(+), 26 deletions(-)
Rather than directly exposing the implementation's representation of the
typec muxes to the controller/clients, introduce an indirection object.
This enables the introduction of turning this relationship into a
one-to-many in the following patch.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 8 +-
drivers/usb/typec/bus.c | 2 +-
drivers/usb/typec/mux.c | 189 ++++++++++++++++----------
drivers/usb/typec/mux.h | 12 +-
drivers/usb/typec/mux/intel_pmc_mux.c | 8 +-
drivers/usb/typec/mux/pi3usb30532.c | 8 +-
include/linux/usb/typec_mux.h | 22 +--
7 files changed, 150 insertions(+), 99 deletions(-)
From: Hans de Goede <hidden> Date: 2021-12-28 12:20:33
Hi Bjorn,
On 12/28/21 06:21, Bjorn Andersson wrote:
This series introduces a level of indirection between the controller's view of
a typec_mux/switch and the implementation and then expands that to support
multiple drivers.
This is needed in order to support devices such as the Qualcomm Snapdragon 888
HDK, which does muxing and orientation handling in the QMP (USB+DP) PHY and SBU
muxing in the external FSA4480 chip.
Additionally integration of typec mux and switch in the QMP PHY is included in
the series, as is the new FSA4480 driver. This is done to deal with the
renaming of the driver-side typec_mux -> typec_mux_dev.
Bjorn Andersson (8):
dt-bindings: phy: qcom,qmp-usb3-dp: Add altmode/switch properties
phy: qcom-qmp: Register typec mux and orientation switch
device property: Helper to match multiple connections
device property: Use multi-connection matchers for single case
typec: mux: Introduce indirection
typec: mux: Allow multiple mux_devs per mux
dt-bindings: usb: Add binding for fcs,fsa4480
usb: typec: mux: Add On Semi fsa4480 driver
Thank you for your series, I will leave commenting on the
dt-bindings and typec-mux changes to others.
But what I can do is test this on an x86 device using
a pi3usb30532 mux for USB super-speed and DP-alt-mode
muxing / orientation switching.
I'm going to wait a bit with doing that till this has had
some reviews and possibly also some newer versions because
of those reviews. If you haven't received a Tested-by from me
when this looks like it is ready for merging please ping me.
Regards,
Hans
The QMP PHY handles muxing of USB vs DisplayPort, as well as orientation
switching of the SuperSpeed lanes. So register typec handlers for the
two types.
The TypeC mux allows switching between four lanes of DisplayPort and a
mixed USB+DP combination. This makes it possible to reach resolutions
that requires 4 lanes.
The TypeC switch allows switching the SuperSpeed pins and have been
tested with both 2 and 4 lane DisplayPort.
It's possible that in the USB mode the DP_MODE should be disabled, but
this is left untouched.
Signed-off-by: Bjorn Andersson <redacted>
Reviewed-by: Dmitry Baryshkov <redacted>
quoted hunk
---
My suggestion is that if/once this patch is deemed acceptable the PHY
maintainers could create a immutable branch/tag which can be merged into the
PHY tree as well as the USB tree.
drivers/phy/qualcomm/phy-qcom-qmp.c | 176 +++++++++++++++++++++++++---
1 file changed, 158 insertions(+), 18 deletions(-)
@@ -5891,7 +6010,15 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev)returnret;}-num=of_get_available_child_count(dev->of_node);+ret=qcom_qmp_phy_typec_register(qmp,cfg);+if(ret)+returnret;++num=0;+for_each_available_child_of_node(dev->of_node,child){+if(!of_node_name_eq(child,"port"))+num++;+}/* do we have a rogue child node ? */if(num>expected_phys)return-EINVAL;
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
This API doesn't let it's user know if there are more matches found in
the device tree or not. I'd suggest to add 'count' mode that would
return the amount of found matches if (matches == NULL) && (matches_len
== 0).
@@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id, return NULL; }+static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches,+ unsigned int matches_len)+{+ struct fwnode_handle *node;+ unsigned int count = 0;+ void *ret;+ int i;++ for (i = 0; ; i++) {+ if (count >= matches_len)+ return count;++ node = fwnode_find_reference(fwnode, con_id, i);+ if (IS_ERR(node))+ break;++ ret = match(node, NULL, data);+ fwnode_handle_put(node);++ if (ret)+ matches[count++] = ret;+ }++ return count;+}+
Same comment applies.
quoted hunk
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.+ *+ * Return: Number of matches resolved, of negative errno.+ */+int fwnode_connection_find_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches, unsigned int matches_len)+{+ unsigned int count;++ if (!fwnode || !match || !matches)+ return -EINVAL;++ count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,+ matches, matches_len);++ return count + fwnode_devcon_matches(fwnode, con_id, data, match,+ matches + count,+ matches_len - count);+}+EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
phy-qcom-qmp.c:(.text+0x37e): undefined reference to `typec_mux_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x37e): undefined reference to `typec_mux_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x384): undefined reference to `typec_switch_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x384): undefined reference to `typec_switch_unregister'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_probe':
quoted
phy-qcom-qmp.c:(.text+0x14bc): undefined reference to `typec_switch_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14bc): undefined reference to `typec_switch_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14e2): undefined reference to `typec_mux_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14e2): undefined reference to `typec_mux_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14f6): undefined reference to `typec_switch_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14f6): undefined reference to `typec_switch_unregister'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_typec_switch_set':
quoted
phy-qcom-qmp.c:(.text+0x18f0): undefined reference to `typec_switch_get_drvdata'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x18f0): undefined reference to `typec_switch_get_drvdata'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_typec_mux_set':
quoted
phy-qcom-qmp.c:(.text+0x1962): undefined reference to `typec_mux_get_drvdata'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x1962): undefined reference to `typec_mux_get_drvdata'
In the Qualcomm platforms the USB/DP PHY handles muxing and orientation
switching of the SuperSpeed lines, but the SBU lines needs to be
connected and switched by external (to the SoC) hardware.
It's therefor necessary to be able to have the TypeC controller operate
multiple TypeC muxes and switches. Use the newly introduced indirection
object to handle this, to avoid having to taint the TypeC controllers
with knowledge about the downstream hardware configuration.
The max number of devs per indirection is set to 3, based on the number
of ports defined in the usb-c-connector binding.
If we had the 'count' ability, we wouldn't have to put limits here.
The limit 3 is a bit artificial if you consider the redriver chips.
phy-qcom-qmp.c:(.text+0x37e): undefined reference to `typec_mux_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x37e): undefined reference to `typec_mux_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x384): undefined reference to `typec_switch_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x384): undefined reference to `typec_switch_unregister'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_probe':
quoted
quoted
phy-qcom-qmp.c:(.text+0x14bc): undefined reference to `typec_switch_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14bc): undefined reference to `typec_switch_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14e2): undefined reference to `typec_mux_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14e2): undefined reference to `typec_mux_register'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14f6): undefined reference to `typec_switch_unregister'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x14f6): undefined reference to `typec_switch_unregister'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_typec_switch_set':
quoted
quoted
phy-qcom-qmp.c:(.text+0x18f0): undefined reference to `typec_switch_get_drvdata'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x18f0): undefined reference to `typec_switch_get_drvdata'
arceb-elf-ld: drivers/phy/qualcomm/phy-qcom-qmp.o: in function `qcom_qmp_phy_typec_mux_set':
quoted
quoted
phy-qcom-qmp.c:(.text+0x1962): undefined reference to `typec_mux_get_drvdata'
arceb-elf-ld: phy-qcom-qmp.c:(.text+0x1962): undefined reference to `typec_mux_get_drvdata'
I missed the fact that CONFIG_TYPEC is tristate. As such the QMP driver
now need to be made "depend on TYPEC || TYPEC=n".
I will update accordingly in v2.
Regards,
Bjorn
On Tue 28 Dec 08:04 PST 2021, Dmitry Baryshkov wrote:
On 28/12/2021 08:21, Bjorn Andersson wrote:
quoted
In the Qualcomm platforms the USB/DP PHY handles muxing and orientation
switching of the SuperSpeed lines, but the SBU lines needs to be
connected and switched by external (to the SoC) hardware.
It's therefor necessary to be able to have the TypeC controller operate
multiple TypeC muxes and switches. Use the newly introduced indirection
object to handle this, to avoid having to taint the TypeC controllers
with knowledge about the downstream hardware configuration.
The max number of devs per indirection is set to 3, based on the number
of ports defined in the usb-c-connector binding.
If we had the 'count' ability, we wouldn't have to put limits here.
The limit 3 is a bit artificial if you consider the redriver chips.
I don't know if it's worth making it more dynamic at this point in time.
I definitely don't think it's worth taking two passes here, because
typec_switch_match will allocate objects that needs to be freed after
the "count" pass. I.e. taking two passes is expensive (and ugly).
Also in it's current state we're wasting 16 bytes per USB connector at
worst and in the case of us having QMP muxing SuperSpeed signals and an
external redriver we have 2.
Given that we're just dealing with pointers the waste isn't that big,
but we could put say 8 (16?) entries on the stack and then dynamically
allocate the typec_switch and typec_mux arrays based on the actual
number of items returned.
Regards,
Bjorn
On Tue 28 Dec 05:09 PST 2021, Dmitry Baryshkov wrote:
On 28/12/2021 08:21, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
This API doesn't let it's user know if there are more matches found in the
device tree or not. I'd suggest to add 'count' mode that would return the
amount of found matches if (matches == NULL) && (matches_len == 0).
Unfortunately in this code path we don't know how to "free" the objects
returned by match(), e.g. see how typec_switch_match() returns wrapper
of a refcounted device.
So we must return all the match results to the caller to it can free
things up based on its knowledge of what matches[] actually contains..
Regards,
Bjorn
@@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id, return NULL; }+static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches,+ unsigned int matches_len)+{+ struct fwnode_handle *node;+ unsigned int count = 0;+ void *ret;+ int i;++ for (i = 0; ; i++) {+ if (count >= matches_len)+ return count;++ node = fwnode_find_reference(fwnode, con_id, i);+ if (IS_ERR(node))+ break;++ ret = match(node, NULL, data);+ fwnode_handle_put(node);++ if (ret)+ matches[count++] = ret;+ }++ return count;+}+
Same comment applies.
quoted
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.+ *+ * Return: Number of matches resolved, of negative errno.+ */+int fwnode_connection_find_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches, unsigned int matches_len)+{+ unsigned int count;++ if (!fwnode || !match || !matches)+ return -EINVAL;++ count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,+ matches, matches_len);++ return count + fwnode_devcon_matches(fwnode, con_id, data, match,+ matches + count,+ matches_len - count);+}+EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
On Tue 28 Dec 04:20 PST 2021, Hans de Goede wrote:
Hi Bjorn,
On 12/28/21 06:21, Bjorn Andersson wrote:
quoted
This series introduces a level of indirection between the controller's view of
a typec_mux/switch and the implementation and then expands that to support
multiple drivers.
This is needed in order to support devices such as the Qualcomm Snapdragon 888
HDK, which does muxing and orientation handling in the QMP (USB+DP) PHY and SBU
muxing in the external FSA4480 chip.
Additionally integration of typec mux and switch in the QMP PHY is included in
the series, as is the new FSA4480 driver. This is done to deal with the
renaming of the driver-side typec_mux -> typec_mux_dev.
Bjorn Andersson (8):
dt-bindings: phy: qcom,qmp-usb3-dp: Add altmode/switch properties
phy: qcom-qmp: Register typec mux and orientation switch
device property: Helper to match multiple connections
device property: Use multi-connection matchers for single case
typec: mux: Introduce indirection
typec: mux: Allow multiple mux_devs per mux
dt-bindings: usb: Add binding for fcs,fsa4480
usb: typec: mux: Add On Semi fsa4480 driver
Thank you for your series, I will leave commenting on the
dt-bindings and typec-mux changes to others.
But what I can do is test this on an x86 device using
a pi3usb30532 mux for USB super-speed and DP-alt-mode
muxing / orientation switching.
Thanks Hans, that would be much appreciated. I realize that I failed to
mention that I don't have this hardware, so I've not been able to test
it myself.
I'm going to wait a bit with doing that till this has had
some reviews and possibly also some newer versions because
of those reviews. If you haven't received a Tested-by from me
when this looks like it is ready for merging please ping me.
On Tue, 28 Dec 2021 at 20:03, Bjorn Andersson
[off-list ref] wrote:
On Tue 28 Dec 05:09 PST 2021, Dmitry Baryshkov wrote:
quoted
On 28/12/2021 08:21, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
This API doesn't let it's user know if there are more matches found in the
device tree or not. I'd suggest to add 'count' mode that would return the
amount of found matches if (matches == NULL) && (matches_len == 0).
Unfortunately in this code path we don't know how to "free" the objects
returned by match(), e.g. see how typec_switch_match() returns wrapper
of a refcounted device.
So we must return all the match results to the caller to it can free
things up based on its knowledge of what matches[] actually contains..
Ugh. Then we should probably return -E2BIG, -ENOSPC or any other such error.
Another option might be to split match into match & map functions,
first one returning bool and second one returning actual corresponding
object..
@@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id, return NULL; }+static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches,+ unsigned int matches_len)+{+ struct fwnode_handle *node;+ unsigned int count = 0;+ void *ret;+ int i;++ for (i = 0; ; i++) {+ if (count >= matches_len)+ return count;++ node = fwnode_find_reference(fwnode, con_id, i);+ if (IS_ERR(node))+ break;++ ret = match(node, NULL, data);+ fwnode_handle_put(node);++ if (ret)+ matches[count++] = ret;+ }++ return count;+}+
Same comment applies.
quoted
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.+ *+ * Return: Number of matches resolved, of negative errno.+ */+int fwnode_connection_find_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches, unsigned int matches_len)+{+ unsigned int count;++ if (!fwnode || !match || !matches)+ return -EINVAL;++ count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,+ matches, matches_len);++ return count + fwnode_devcon_matches(fwnode, con_id, data, match,+ matches + count,+ matches_len - count);+}+EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
On Tue 28 Dec 10:24 PST 2021, Dmitry Baryshkov wrote:
On Tue, 28 Dec 2021 at 20:03, Bjorn Andersson
[off-list ref] wrote:
quoted
On Tue 28 Dec 05:09 PST 2021, Dmitry Baryshkov wrote:
quoted
On 28/12/2021 08:21, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
This API doesn't let it's user know if there are more matches found in the
device tree or not. I'd suggest to add 'count' mode that would return the
amount of found matches if (matches == NULL) && (matches_len == 0).
Unfortunately in this code path we don't know how to "free" the objects
returned by match(), e.g. see how typec_switch_match() returns wrapper
of a refcounted device.
So we must return all the match results to the caller to it can free
things up based on its knowledge of what matches[] actually contains..
Ugh. Then we should probably return -E2BIG, -ENOSPC or any other such error.
Another option might be to split match into match & map functions,
first one returning bool and second one returning actual corresponding
object..
If I get an errno back from a function like this I generally expect this
kind of API to have done the cleanup for me, which can't be done. So I
fear that it would be more error prone than the current proposal - which
potentially might (silently) fail to detect that you have 4+ orientation
switches attached to your USB port.
My imagination doesn't isn't able to come up with a large enough
of_graph where the client would need to provide an matches array that's
larger than what would fit on the stack. Perhaps someone can provide a
real use case where it would be necessary to support arbitrary sizes of
matches[]?
Regards,
Bjorn
@@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id, return NULL; }+static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches,+ unsigned int matches_len)+{+ struct fwnode_handle *node;+ unsigned int count = 0;+ void *ret;+ int i;++ for (i = 0; ; i++) {+ if (count >= matches_len)+ return count;++ node = fwnode_find_reference(fwnode, con_id, i);+ if (IS_ERR(node))+ break;++ ret = match(node, NULL, data);+ fwnode_handle_put(node);++ if (ret)+ matches[count++] = ret;+ }++ return count;+}+
Same comment applies.
quoted
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.+ *+ * Return: Number of matches resolved, of negative errno.+ */+int fwnode_connection_find_matches(struct fwnode_handle *fwnode,+ const char *con_id, void *data,+ devcon_match_fn_t match,+ void **matches, unsigned int matches_len)+{+ unsigned int count;++ if (!fwnode || !match || !matches)+ return -EINVAL;++ count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,+ matches, matches_len);++ return count + fwnode_devcon_matches(fwnode, con_id, data, match,+ matches + count,+ matches_len - count);+}+EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
The QMP PHY handles muxing of USB vs DisplayPort, as well as orientation
switching of the SuperSpeed lanes. So register typec handlers for the
two types.
The TypeC mux allows switching between four lanes of DisplayPort and a
mixed USB+DP combination. This makes it possible to reach resolutions
that requires 4 lanes.
The TypeC switch allows switching the SuperSpeed pins and have been
tested with both 2 and 4 lane DisplayPort.
It's possible that in the USB mode the DP_MODE should be disabled, but
this is left untouched.
Signed-off-by: Bjorn Andersson <redacted>
---
My suggestion is that if/once this patch is deemed acceptable the PHY
maintainers could create a immutable branch/tag which can be merged into the
PHY tree as well as the USB tree.
drivers/phy/qualcomm/phy-qcom-qmp.c | 176 +++++++++++++++++++++++++---
1 file changed, 158 insertions(+), 18 deletions(-)
@@ -5891,7 +6010,15 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) return ret; }- num = of_get_available_child_count(dev->of_node);+ ret = qcom_qmp_phy_typec_register(qmp, cfg);+ if (ret)+ return ret;++ num = 0;+ for_each_available_child_of_node(dev->of_node, child) {+ if (!of_node_name_eq(child, "port"))+ num++;+ } /* do we have a rogue child node ? */ if (num > expected_phys) return -EINVAL;
@@ -5918,6 +6045,9 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) serdes = usb_serdes; }+ if (of_node_name_eq(child, "port"))+ continue;+ /* Create per-lane phy */ ret = qcom_qmp_phy_create(dev, child, id, serdes, cfg); if (ret) {
On Tue 28 Dec 05:09 PST 2021, Dmitry Baryshkov wrote:
quoted
On 28/12/2021 08:21, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
This API doesn't let it's user know if there are more matches found in the
device tree or not. I'd suggest to add 'count' mode that would return the
amount of found matches if (matches == NULL) && (matches_len == 0).
But the API does call each match
Unfortunately in this code path we don't know how to "free" the objects
returned by match(), e.g. see how typec_switch_match() returns wrapper
of a refcounted device.
So we must return all the match results to the caller to it can free
things up based on its knowledge of what matches[] actually contains..
ACPI walk has similar APIs, I can think of acpi_walk_namespace() which I
have used in past and does similar walk in namespace but for devices and
calls the match()
--
~Vinod
From: Heikki Krogerus <heikki.krogerus@linux.intel.com> Date: 2021-12-30 09:26:42
+Andy, Dan and Sakari
On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
quoted hunk
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
From: Sakari Ailus <sakari.ailus@linux.intel.com> Date: 2021-12-31 09:10:01
Hi Björn,
(And thanks to Heikki for cc'ing me!)
On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
+Andy, Dan and Sakari
On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
+
+ for (i = 0; ; i++) {
+ if (count >= matches_len)
+ return count;
+
+ node = fwnode_find_reference(fwnode, con_id, i);
+ if (IS_ERR(node))
+ break;
+
+ ret = match(node, NULL, data);
+ fwnode_handle_put(node);
+
+ if (ret)
+ matches[count++] = ret;
+ }
+
+ return count;
+}
+
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.
If the caller allocates the matches array, how does it know how large it
should be? Is there a need to provide a way to count the matches before
writing them to an array? Most similar functions do that by just setting the
array (matches) to NULL.
Hi Björn,
(And thanks to Heikki for cc'ing me!)
On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
quoted
+Andy, Dan and Sakari
On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
+
+ for (i = 0; ; i++) {
+ if (count >= matches_len)
+ return count;
+
+ node = fwnode_find_reference(fwnode, con_id, i);
+ if (IS_ERR(node))
+ break;
+
+ ret = match(node, NULL, data);
+ fwnode_handle_put(node);
+
+ if (ret)
+ matches[count++] = ret;
+ }
+
+ return count;
+}
+
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.
If the caller allocates the matches array, how does it know how large it
should be? Is there a need to provide a way to count the matches before
writing them to an array? Most similar functions do that by just setting the
array (matches) to NULL.
This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.
I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.
But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.
As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.
I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.
But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.
While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.
As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?
Regards,
Bjorn
From: Sakari Ailus <sakari.ailus@linux.intel.com> Date: 2022-01-07 14:34:26
On Wed, Jan 05, 2022 at 12:43:28PM -0800, Bjorn Andersson wrote:
On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:
quoted
Hi Björn,
(And thanks to Heikki for cc'ing me!)
On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
quoted
+Andy, Dan and Sakari
On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
+
+ for (i = 0; ; i++) {
+ if (count >= matches_len)
+ return count;
+
+ node = fwnode_find_reference(fwnode, con_id, i);
+ if (IS_ERR(node))
+ break;
+
+ ret = match(node, NULL, data);
+ fwnode_handle_put(node);
+
+ if (ret)
+ matches[count++] = ret;
+ }
+
+ return count;
+}
+
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.
If the caller allocates the matches array, how does it know how large it
should be? Is there a need to provide a way to count the matches before
writing them to an array? Most similar functions do that by just setting the
array (matches) to NULL.
This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.
I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.
But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.
As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.
I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.
krealloc() may also fail...
But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.
While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.
As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?
Another option would be to use a fixed-size array for the purpose. Assuming
this will remain a small number, a single global macro could be used to set
the maximum number that could be also easily increased if needed.
On the other hand, if this number remains specific to the caller as it
would seem, then I guess a caller-set value (as implemented now) remains a
fine option, too.
--
Kind regards,
Sakari Ailus
On Wed, Jan 05, 2022 at 12:43:28PM -0800, Bjorn Andersson wrote:
quoted
On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:
quoted
Hi Björn,
(And thanks to Heikki for cc'ing me!)
On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
quoted
+Andy, Dan and Sakari
On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
quoted
In some cases multiple connections with the same connection id
needs to be resolved from a fwnode graph.
One such example is when separate hardware is used for performing muxing and/or
orientation switching of the SuperSpeed and SBU lines in a USB-C
connector. In this case the connector needs to belong to a graph with
multiple matching remote endpoints, and the TypeC controller needs to be
able to resolve them both.
Add a new API that allows this kind of lookup.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
include/linux/property.h | 5 +++
2 files changed, 99 insertions(+)
+
+ for (i = 0; ; i++) {
+ if (count >= matches_len)
+ return count;
+
+ node = fwnode_find_reference(fwnode, con_id, i);
+ if (IS_ERR(node))
+ break;
+
+ ret = match(node, NULL, data);
+ fwnode_handle_put(node);
+
+ if (ret)
+ matches[count++] = ret;
+ }
+
+ return count;
+}
+
/**
* fwnode_connection_find_match - Find connection from a device node
* @fwnode: Device node with the connection
@@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode, return fwnode_devcon_match(fwnode, con_id, data, match); } EXPORT_SYMBOL_GPL(fwnode_connection_find_match);++/**+ * fwnode_connection_find_matches - Find connections from a device node+ * @fwnode: Device node with the connection+ * @con_id: Identifier for the connection+ * @data: Data for the match function+ * @match: Function to check and convert the connection description+ * @matches: Array of pointers to fill with matches+ * @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.
If the caller allocates the matches array, how does it know how large it
should be? Is there a need to provide a way to count the matches before
writing them to an array? Most similar functions do that by just setting the
array (matches) to NULL.
This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.
I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.
But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.
As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.
I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.
krealloc() may also fail...
Exactly.
quoted
But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.
While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.
As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?
Another option would be to use a fixed-size array for the purpose. Assuming
this will remain a small number, a single global macro could be used to set
the maximum number that could be also easily increased if needed.
On the other hand, if this number remains specific to the caller as it
would seem, then I guess a caller-set value (as implemented now) remains a
fine option, too.
Sounds good.
I will try to capture these arguments in the commit message as I post
the next version.
Thanks,
Bjorn
The QMP PHY handles muxing of USB vs DisplayPort, as well as orientation
switching of the SuperSpeed lanes. So register typec handlers for the
two types.
The TypeC mux allows switching between four lanes of DisplayPort and a
mixed USB+DP combination. This makes it possible to reach resolutions
that requires 4 lanes.
The TypeC switch allows switching the SuperSpeed pins and have been
tested with both 2 and 4 lane DisplayPort.
It's possible that in the USB mode the DP_MODE should be disabled, but
this is left untouched.
Signed-off-by: Bjorn Andersson <redacted>
---
My suggestion is that if/once this patch is deemed acceptable the PHY
maintainers could create a immutable branch/tag which can be merged into the
PHY tree as well as the USB tree.
drivers/phy/qualcomm/phy-qcom-qmp.c | 176 +++++++++++++++++++++++++---
1 file changed, 158 insertions(+), 18 deletions(-)
pls align to preceding open brace (here and other places)
Sure thing.
quoted
+{
+ struct qcom_qmp *qmp = typec_switch_get_drvdata(sw);
+ void __iomem *dp_com = qmp->dp_com;
+
+ qmp->orientation = orientation;
+
+ if (orientation == TYPEC_ORIENTATION_REVERSE)
+ qphy_setbits(dp_com, QPHY_V3_DP_COM_TYPEC_CTRL, 0x01);
+ else
+ qphy_clrbits(dp_com, QPHY_V3_DP_COM_TYPEC_CTRL, 0x01);
+
+ return 0;
+}
+
+static int qcom_qmp_phy_typec_mux_set(struct typec_mux *mux,
+ struct typec_mux_state *state)
+{
+ struct qcom_qmp *qmp = typec_mux_get_drvdata(mux);
+ void __iomem *dp_com = qmp->dp_com;
+ bool dp_mode;
+ bool usb_mode;
+
+ switch (state->mode) {
+ case TYPEC_STATE_SAFE:
+ case TYPEC_STATE_USB:
+ /*
+ * TODO: Figure out if we should clear DP_MODE when we enter a
+ * USB-only state.
+ */
+ dp_mode = true;
should this be false for these states?
I think it should, but figured that I better change the behavior in a
separate follow-up commit. Might also be that SAFE should be
false/false - or in some other way turning off the output.
Hence the TODO.
quoted
+ usb_mode = true;
+ break;
+ case TYPEC_DP_STATE_A:
+ case TYPEC_DP_STATE_C:
+ case TYPEC_DP_STATE_E:
+ dp_mode = true;
+ usb_mode = false;
+ break;
+ case TYPEC_DP_STATE_B:
+ case TYPEC_DP_STATE_D:
+ case TYPEC_DP_STATE_F:
+ dp_mode = true;
+ usb_mode = true;
+ break;
+ }
looks like dp_mode is true always. And only for DP state A C E, usb_mode
is false...
A, C and E are 4-lanes DP, while B, D, F are 2-lane DP and 2-lane USB.
@@ -5891,7 +6010,15 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) return ret; }- num = of_get_available_child_count(dev->of_node);+ ret = qcom_qmp_phy_typec_register(qmp, cfg);+ if (ret)+ return ret;++ num = 0;+ for_each_available_child_of_node(dev->of_node, child) {+ if (!of_node_name_eq(child, "port"))+ num++;+ } /* do we have a rogue child node ? */ if (num > expected_phys) return -EINVAL;
@@ -5918,6 +6045,9 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) serdes = usb_serdes; }+ if (of_node_name_eq(child, "port"))+ continue;+ /* Create per-lane phy */ ret = qcom_qmp_phy_create(dev, child, id, serdes, cfg); if (ret) {