Hi Hans,

On Fri, Dec 3, 2021 at 2:14 AM Hans de Goede [off-list ref] wrote:

Hi Prashant,

On 12/2/21 20:29, Prashant Malani wrote:

quoted

Hi Hans,

Sorry for posting on an old thread, but I was wondering if there was
still a plan to submit this? This is something we'd like to use on
Chrome OS too.

It sounded like the primary discussion was whether to have an "altmodes"
property encaspulating the various alt modes, but not sure what the
final consensus on that was (sounded to me like your current
implementation was fine for now, and ACPI use cases would be handled
later?).

Support for this has already landed, but so far has only been tested
on a x86/ACPI device, where the firmware-nodes parsed by the new
typec_port_register_altmodes() helper are setup through software-nodes,
see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b458a4c5d7302947556e12c83cfe4da769665d0
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=55d8b34772e0728a224198ba605eed8cfc570aa0
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d28466e5f4f8

In theory this should be usable for devicetree as is. But that would
require documenting the current in kernel swnode bindings as
official devicetree bindings and getting that through the devicetree
bindings review process.

That's good to hear :)

I have deliberately not done this because the devicetree maintainers
have asked for properties / swnode "bindings" used only inside
the kernel (1) to NOT be documented as official devicetree bindings,
they (the dt bindings maintainers) want to first see at least one
real devicetree users before adding things like this to the
official devicetree bindings docs.

Note if the way typec_port_register_altmodes() parses the fwnode
properties needs to change as result of the devicetree bindings review
process, please let me know, because then the swnode-s created in
drivers/platform/x86/intel/int33fe/intel_cht_int33fe_typec.c
need to change to match so as to not regress things on those devices.

Heikki, can we reconcile this with the format you had in mind for ACPI
devices which specify this in ASL files?
If not, would you rather:
1. We handle the actual ACPI format differently in
typec_port_register_altmodes() itself ? If so, is it documented
in some place that we can reference?
<or>
2. Parse whatever ACPI format there is in the port drivers probe
function, and then inject software nodes like in the int33fe driver
[1]
<or>
3. Is there scope for updating the ACPI altmode descriptor format to
match what is being parsed by typec_port_register_altmodes()

Thanks,

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/intel/int33fe/intel_cht_int33fe_typec.c#n221