This series adds basic USB Type-C support for 1st gen devices, covering
configurations that do not require VBUS power (e.g. devices using
externally powered docks).

VBUS support will be added in a follow-up series after this one is merged.
Supporting VBUS will likely require refactoring parts of the SMBX charger
support, which is why it is not included here.

Tested with an externally powered dock station:

 - Pixel 3 / 3 XL
 - SHIFT 6mq
 - OnePlus 6

Tested with an additional, not-yet-included VBUS patch for non-powered
devices:

 - Xiaomi Redmi Note 7
 - Xiaomi Mi Pad 4

Credits to everyone who has contributed to Type-C enablement before:

 Casey Connolly
 Zachary Dry — LLM generation and testing
 Max Furman — LLM generation and testing

Signed-off-by: David Heidelberg <david@ixit.cz>
---
Alexey Minnekhanov (1):
      arm64: dts: qcom: pm660: Add USB Type-C port controller node

David Heidelberg (11):
      usb: typec: tcpm: qcom: Release the connector fwnode reference
      dt-bindings: usb: qcom,pmic-typec: Update example with vbus-supply
      dt-bindings: usb: Add Qualcomm 1st-gen PMIC Type-C
      usb: typec: qcom: Make PMIC port probe selectable
      usb: typec: qcom: Make typec_port accept also different structure
      usb: typec: qcom: Add gen1 Type-C port support
      arm64: dts: qcom: pmi8998: Add USB Type-C port controller node
      arm64: dts: qcom: sdm670-google-common: Enable USB Type-C port controller
      arm64: dts: qcom: sdm845-google-common: Enable USB Type-C port controller
      arm64: dts: qcom: sdm845-oneplus-common: Enable USB Type-C port controller
      arm64: dts: qcom: sdm845-shift-axolotl: Enable USB Type-C port controller

 .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml    |   4 +-
 .../bindings/usb/qcom,pmic-typec-gen1.yaml         | 130 +++++
 .../devicetree/bindings/usb/qcom,pmic-typec.yaml   |   3 +-
 arch/arm64/boot/dts/qcom/pm660.dtsi                |  27 +
 arch/arm64/boot/dts/qcom/pmi8998.dtsi              |  27 +
 arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi |  51 +-
 arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi |  59 +-
 .../arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi |  48 +-
 arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts  |  62 ++-
 drivers/usb/typec/tcpm/qcom/Makefile               |   1 +
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c      |  20 +-
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.h      |   2 +-
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c |   2 +
 .../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.c    | 605 +++++++++++++++++++++
 .../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.h    |  15 +
 15 files changed, 1045 insertions(+), 11 deletions(-)
---
base-commit: 7079a12d7506b07fb53b54a664bfad5fa9b16d70
change-id: 20260922-typec-6c48ef7ac8b0

Best regards,
--  
David Heidelberg <david@ixit.cz>

On Sat, Sep 26, 2026 at 02:40:19PM +0200, David Heidelberg via B4 Relay wrote:
> This series adds basic USB Type-C support for 1st gen devices, covering
> configurations that do not require VBUS power (e.g. devices using
> externally powered docks).
> 
> VBUS support will be added in a follow-up series after this one is merged.
> Supporting VBUS will likely require refactoring parts of the SMBX charger
> support, which is why it is not included here.
> 
> Tested with an externally powered dock station:
> 
>  - Pixel 3 / 3 XL
>  - SHIFT 6mq
>  - OnePlus 6
> 
> Tested with an additional, not-yet-included VBUS patch for non-powered
> devices:
> 
>  - Xiaomi Redmi Note 7
>  - Xiaomi Mi Pad 4

THis is very interesting, as it will also unblock DisplayPort support on
devices from those generations.


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?

> 
> Credits to everyone who has contributed to Type-C enablement before:
> 
>  Casey Connolly
>  Zachary Dry — LLM generation and testing
>  Max Furman — LLM generation and testing
> 
> Signed-off-by: David Heidelberg <david@ixit.cz>

-- 
With best wishes
Dmitry

On 27/09/2026 15:05, Dmitry Baryshkov wrote:
> On Sat, Sep 26, 2026 at 02:40:19PM +0200, David Heidelberg via B4 Relay wrote:
>> This series adds basic USB Type-C support for 1st gen devices, covering
>> configurations that do not require VBUS power (e.g. devices using
>> externally powered docks).
>>
>> VBUS support will be added in a follow-up series after this one is merged.
>> Supporting VBUS will likely require refactoring parts of the SMBX charger
>> support, which is why it is not included here.
>>
>> Tested with an externally powered dock station:
>>
>>   - Pixel 3 / 3 XL
>>   - SHIFT 6mq
>>   - OnePlus 6
>>
>> Tested with an additional, not-yet-included VBUS patch for non-powered
>> devices:
>>
>>   - Xiaomi Redmi Note 7
>>   - Xiaomi Mi Pad 4
> 
> THis is very interesting, as it will also unblock DisplayPort support on
> devices from those generations.

Yes, DP works with some minor adjustment there and there (going to be follow-up)

> 
> 
> 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.

David

> 
>>
>> Credits to everyone who has contributed to Type-C enablement before:
>>
>>   Casey Connolly
>>   Zachary Dry — LLM generation and testing
>>   Max Furman — LLM generation and testing
>>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
> 

On Sun, Sep 27, 2026 at 05:16:28PM +0200, David Heidelberg wrote:
> On 27/09/2026 15:05, Dmitry Baryshkov wrote:
> > On Sat, Sep 26, 2026 at 02:40:19PM +0200, David Heidelberg via B4 Relay wrote:
> > > This series adds basic USB Type-C support for 1st gen devices, covering
> > > configurations that do not require VBUS power (e.g. devices using
> > > externally powered docks).
> > > 
> > > VBUS support will be added in a follow-up series after this one is merged.
> > > Supporting VBUS will likely require refactoring parts of the SMBX charger
> > > support, which is why it is not included here.
> > > 
> > > Tested with an externally powered dock station:
> > > 
> > >   - Pixel 3 / 3 XL
> > >   - SHIFT 6mq
> > >   - OnePlus 6
> > > 
> > > Tested with an additional, not-yet-included VBUS patch for non-powered
> > > devices:
> > > 
> > >   - Xiaomi Redmi Note 7
> > >   - Xiaomi Mi Pad 4
> > 
> > THis is very interesting, as it will also unblock DisplayPort support on
> > devices from those generations.
> 
> Yes, DP works with some minor adjustment there and there (going to be follow-up)
> 
> > 
> > 
> > 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?

-- 
With best wishes
Dmitry

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

---
bod

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.

But, then it's up to you and David.

-- 
With best wishes
Dmitry

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.
>