Re: [PATCH v4 2/2] power: supply: qcom_smbx: add SMB5 support

[David Heidelberg]

On 28/10/2026 08:42, Robin Snyders wrote:
> On 27/10/2026 18:19, David Heidelberg wrote:
> > On 20/08/2026 12:03, Robin Snyders via B4 Relay wrote:
> > > +enum smb_generation {
> > > +	SMB2,
> > > +	SMB5,
> > > +};
> > > +
> > > +#define SMB_REG_OFFSET(smb) ((smb)->gen == SMB2 ? 0x600 : 0x100)
> > > +
> >
> > More and more as I look at it, this shouldn't be here, but within the device-tree as
> > charger@1000 {
> >      reg = <0x1000>, <0x1600>;  # SMB2, or
> >      reg = <0x1000>, <0x1100>;  # SMB5
> > };
> >
> > But see also:
> > https://lore.kernel.org/all/eodzuccugtdn42basgpczett4yatyirog4nxwe5rhg5xf46ibp@jzcjmje4aqc3/
> >
> > I'll try to do some basic separation so we know what bits belongs into which blog, keep you in CC.
>
> Hi David,
>
> Thanks for looking at this.

Hi Robin

btw. since I'm working on the type-c + vbus (which originally clankers put into 
smbx), I noticed that there is existing vbus driver which can be used.

This implies removing OTG (0x1100 block) from the smbx driver.

Thus series needs more testing (charge/otg/DP, etc.), I have it at

https://codeberg.org/sdm845/linux/commits/branch/b4/pmi8998-vbus

see the commit touching smbx, as you can omit changing this part, which going to 
be removed in favor 'qcom_usb_vbus-regulator.c' (there was small conflict with 
SMB5 due to defines renaming).

I'll keep the rest of proposed changes to be commented by maintainers/qcom folks :)

Thank you
David

> Agreed. Describing the second register block explicitly in the charger's
> reg property (0x1600 on SMB2, 0x1100 on SMB5) is cleaner than deriving
> its base address from the hardware generation.
>
> For v5, I plan to extend qcom,pmi8998-charger.yaml with a second reg
> entry and use that base for both the power-path status and the
> effective ICL status accesses, keeping their generation-specific
> register offsets.
>
> I'd retain a driver fallback for existing PMI8998/PM660 DTBs that only
> have one reg entry. The binding could still require both entries for new
> SMB5 descriptions. If you or Sebastian prefer a different compatibility
> approach, I'm happy to adjust.
>
> Given Dmitry's concern about shared charger/Type-C register ownership on
> SMB2 in the gen1 Type-C RFC, I'd like to coordinate v5 with your block
> split so that we don't introduce conflicting register descriptions.
> Please keep me in Cc.
>
> For reference, I also audited the current v4 SMB5 accesses on PM8150B.
> They are confined to the charger core (0x10xx), the DCDC status
> registers (reads of 0x1108 and 0x110b), the USB input/BC1.2 registers
> (0x1340-0x1380) and the watchdog/AICL registers (0x1651-0x1661).
>
> In particular, USBIN_TYPE_C_CFG at 0x1358 is part of the USB-input
> peripheral, not the dedicated Type-C port register at 0x1544. The
> current SMB5 accesses do not overlap with the dedicated Type-C port
> (0x1500) or PD PHY (0x1700) register accesses. The DCDC peripheral is
> also used by the VBUS regulator, so this is a register-level
> observation rather than a claim of exclusive peripheral ownership.
>
> I'll update the public register-ownership note to reflect the exact v4
> access paths.
>
> Thanks,
> Robin