Re: [PATCH v2] arm64: dts: qcom: msm8916-samsung-serranove: Add RT5033 PMIC with charger

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

 



Hi Krzysztof,

Cc: Rob, Chanwoo & MyungJoo

On 11.07.23 08:13, Krzysztof Kozlowski wrote:
...
This appeared in today's next next-20230711 and causes new warnings

msm8916-samsung-serranove.dtb: extcon@14: 'connector' does not match any
of the regexes: 'pinctrl-[0-9]+'
https://krzk.eu/#/builders/90/builds/40/steps/17/logs/stdio

The commit mentions rt5033, but that is not the schema being here
tested, so clearly this is wrong or bindings were not updated.

Please fix (and test your future patches).

The implementation you see in this patch follows the guidance of yours and Rob’s. I already expressed my discontent about it before.

To solve the message, the dt-bindings of extcon device sm5502-muic [1] would need to be changed to allow a "connector" sub-node. That’s not the right approach.

I still have the impression that the current implementation is based on misunderstandings. I do think Rob’s comment that excon phandle being deprecated [2] is valid for the USB subsystem. Your suggestion to check "ports graph", "orientation" and "usb-role-switch" applies to USB subsystem as well [3]. Rob took the time to add more explanation [4] but it’s still about handling connectors in the more strict sense, which is circling around UBS subsystem.

These discussions led to a strangely mixed-up result. I was pushed to implement the USB subsystem connector approach upon an excton subsystem device. As the standard USB connector approach didn’t fit, we switched to a vendor-specific connector phandle [5]. In fact it’s kind of a workaround for the extcon phandle.

The extcon device sm5504 is a real piece of hardware. It’s not handled by USB subsystem but by extcon subsystem. The excton subsystem has a method implemented to get the device by phandle [6].

I therefore propose to use the phandle of the extcon subsystem. I mean extcon subsystem, not USB subsystem. In case you disagree, I kindly ask you to take more time to answer in more detail and especially case-related. And specifically to Krzysztof I ask for more politeness in your way of communicating. I understand you’re answering hundreds of requests a day but the communication we had in the past weeks is really frustrating.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml?h=v6.5-rc1 [2] https://lore.kernel.org/linux-pm/cover.1677620677.git.jahau@xxxxxxxxxxxxxx/T/#m1f57a36d534e677f84158e6886c1340e036ab5c6 [3] https://lore.kernel.org/linux-pm/cover.1682636929.git.jahau@xxxxxxxxxxxxxx/T/#m7672ad05590e4123ba5622bc59a9b4dcc0f70e3a [4] https://lore.kernel.org/linux-pm/cover.1682636929.git.jahau@xxxxxxxxxxxxxx/T/#m65db0709f0ad3feac6c289f65be5a351cacd2835 [5] https://lore.kernel.org/linux-pm/20230506155435.3005-1-jahau@xxxxxxxxxxxxxx/T/#m2aa652c41bad93d60042d831c6397e7838d3cbfc [6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/extcon/extcon.c?h=v6.5-rc1#n1417

Kind regards,
Jakob




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux