Re: [PATCH v3 8/8] dt-bindings: Add rt5033 mfd, regulator and charger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob,

On 05.05.23 22:13, Rob Herring wrote:
On Wed, May 03, 2023 at 09:33:49PM +0200, Jakob Hauser wrote:
Hi Krzysztof, Hi all,

On 02.05.23 12:59, Krzysztof Kozlowski wrote:
...
Apologies for this, just very busy times. :)


Thanks for letting me know. Take the time you need.

Writing towards the list:

I think there is a misunderstanding here.

The connector node provides information about the installed USB hardware.
E.g. property "usb-role-switch" means "Indicates that the device is capable
of assigning the USB data role (USB host or USB device) for a given USB
connector [...]" [5]. To my understanding, in relation with a port node this
actually says that this port has this capability. This is not relevant to
the rt5033-charger driver.

The rt5033-charger driver needs to pair with the extcon chip because it
needs the information about *external* connectors being attached [6].

Extcon devices like SM5502 or SM5504 are real hardware. I'm not adding new
properties. The way of getting an excton device from the devicetree by
phandle is part of the extcon subsystem:
  - function to get the excton device by phandle: [7]
  - line that's looking for the property "extcon": [8]

extcon as a binding is inadequate for handling the increasing
complexities of connectors. Whether we need another property to link
things to connector nodes, perhaps.

Thanks for clarifying.

The connector node is the wrong approach, as far as I can tell on my current
state of knowledge. It doesn't provide the information needed by the
rt5033-charger driver.

What information is that?

You need information from the DT or run-time information from the
'extcon chip driver'? In the latter case, I'd expect the charger driver
to get its connector node (either TBD phandle or search the DT if
there's only 1 possible connector), and from that get the driver
controlling the connector.

Yes, the latter case: run-time information from the 'extcon chip driver'.

Hm, so I need to add a connector node below the extcon node, search for that connector and go one level up to get the extcon. In the specific case that's an unnecessary detour, I'm not too happy about it :/ Though I understand that in a broader perspective the connector thing can be more stringent.

I'll prepare something like this for v4 then...

Kind regard,
Jakob



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux