Re: [PATCH RFC 00/12] Qualcomm Type-C support for 1st generation

[David Heidelberg <david@ixit.cz>]

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:
>>>>> One major comment. As we see, on SMB2 PMICs parts of the Type-C
>>>>> 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?
>>>> As this gets decided from the QCOM side, I'm fine with whatever suits the
>>>> hardware best.
>>> Bryan, as you are a maintainer of the PMIC-TCPM? Would the use of
>>> 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.
>