Re: [PATCH RFC 00/12] Qualcomm Type-C support for 1st generation
From: David Heidelberg
Date: Tue Oct 27 2026 - 16:10:39 EST
On 19/10/2026 01:53, Dmitry Baryshkov wrote:
On Mon, Sep 28, 2026 at 04:54:08PM +0100, Bryan O'Donoghue wrote:
On 27/09/2026 17:33, Dmitry Baryshkov wrote:
Bryan, as you are a maintainer of the PMIC-TCPM? Would the use ofOne major comment. As we see, on SMB2 PMICs parts of the Type-CAs this gets decided from the QCOM side, I'm fine with whatever suits the
functionality are provided by the charger / FG device. I guess that on
SMB5 PMICs we will get the same problem once somebody tries to implement
additional charger features. Would it make sense to rework the PMIC TCPM
driver to be a composite driver, taking several components via the
existing Linux interface?
hardware best.
components be fine?
I mean maybe. Would it not make more sense to land the TCPM functionality
and then look into adding charging moving then ?
i.e. finish off adding this piece first
The problem is that we already have SMB2 charger, which accesses the
same region. In theory it is possible to say that USB-C driver conflicts
with the charger "for now". In practice, I think, it might be better to
sort that out from the beginning. You didn't have this issue when
working on PM8150B support since we never needed charger for that PMIC
series.
I looked into the smbx vs Type-C overlaps.
I see that charger DCIN (0x1400) is mostly mirrors (both address and values) the register set of USBIN (0x1300), thus I assume charger accessing these registers is correct.
Type-C driver accesses 0x1300 but mostly different registers (with some exception of initialization and smbx.c 'FIXME: This will be handled by the type-c driver').
So that leads me to the conclusion that smbx should continue to access 0x1300 range, while Type-C must access the range. Only things which needs to be moved from smbx to type-c is the type-c initialization.
Do I get it correctly?
Thanks
David
But, then it's up to you and David.