For systems where the ID pin isn't available as gpio use the ATTACHED_STATE
register instead to control vbus.

From the datasheet:
"This is an additional method to communicate attach other
than the ID pin. These bits can be read by the application to
determine what was attached."

Use this method if id-gpios property is not set, but the connector node
has vbus-supply defined.

Check regulator state as peripheral and detach can disable vbus.

Signed-off-by: Jan Remmet <j.remmet@phytec.de>
---
Changes in v2:
- Added check if regulator is already disabled. As detach and
  peripheral mode cause an interrupt.
- Link to v1: https://lore.kernel.org/r/20260115-wip-jremmet-hd3ss3220_vbus-v1-1-b7d9adfbe346@phytec.de
---
 drivers/usb/typec/hd3ss3220.c | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/typec/hd3ss3220.c b/drivers/usb/typec/hd3ss3220.c
index 3876f4faead679e6c04062ab2bcf2ae928913a0a..3e39b800e6b5f4d0cbba957c0dd66c18f781ff38 100644
--- a/drivers/usb/typec/hd3ss3220.c
+++ b/drivers/usb/typec/hd3ss3220.c
@@ -204,6 +204,23 @@ static const struct typec_operations hd3ss3220_ops = {
 	.port_type_set = hd3ss3220_port_type_set,
 };
 
+static void hd3ss3220_regulator_control(struct hd3ss3220 *hd3ss3220, bool on)
+{
+	int ret;
+
+	if (regulator_is_enabled(hd3ss3220->vbus) == on)
+		return;
+
+	if (on)
+		ret = regulator_enable(hd3ss3220->vbus);
+	else
+		ret = regulator_disable(hd3ss3220->vbus);
+
+	if (ret)
+		dev_err(hd3ss3220->dev,
+			"vbus regulator %s failed: %d\n", on ? "disable" : "enable", ret);
+}
+
 static void hd3ss3220_set_role(struct hd3ss3220 *hd3ss3220)
 {
 	enum usb_role role_state = hd3ss3220_get_attached_state(hd3ss3220);
@@ -221,6 +238,9 @@ static void hd3ss3220_set_role(struct hd3ss3220 *hd3ss3220)
 		break;
 	}
 
+	if (hd3ss3220->vbus && !hd3ss3220->id_gpiod)
+		hd3ss3220_regulator_control(hd3ss3220, role_state == USB_ROLE_HOST);
+
 	hd3ss3220->role_state = role_state;
 }
 
@@ -330,18 +350,10 @@ static const struct regmap_config config = {
 static irqreturn_t hd3ss3220_id_isr(int irq, void *dev_id)
 {
 	struct hd3ss3220 *hd3ss3220 = dev_id;
-	int ret;
 	int id;
 
 	id = gpiod_get_value_cansleep(hd3ss3220->id_gpiod);
-	if (!id)
-		ret = regulator_enable(hd3ss3220->vbus);
-	else
-		ret = regulator_disable(hd3ss3220->vbus);
-
-	if (ret)
-		dev_err(hd3ss3220->dev,
-			"vbus regulator %s failed: %d\n", id ? "disable" : "enable", ret);
+	hd3ss3220_regulator_control(hd3ss3220, !id);
 
 	return IRQ_HANDLED;
 }

---
base-commit: 944aacb68baf7624ab8d277d0ebf07f025ca137c
change-id: 20260115-wip-jremmet-hd3ss3220_vbus-732f74894acc

Best regards,
-- 
Jan Remmet <j.remmet@phytec.de>

On Fri, Jan 23, 2026 at 03:52:37PM +0100, Jan Remmet wrote:
> For systems where the ID pin isn't available as gpio use the ATTACHED_STATE
> register instead to control vbus.
> 
> >From the datasheet:
> "This is an additional method to communicate attach other
> than the ID pin. These bits can be read by the application to
> determine what was attached."
> 
> Use this method if id-gpios property is not set, but the connector node
> has vbus-supply defined.
> 
> Check regulator state as peripheral and detach can disable vbus.
> 
> Signed-off-by: Jan Remmet <j.remmet@phytec.de>
> ---
> Changes in v2:
> - Added check if regulator is already disabled. As detach and
>   peripheral mode cause an interrupt.
> - Link to v1: https://lore.kernel.org/r/20260115-wip-jremmet-hd3ss3220_vbus-v1-1-b7d9adfbe346@phytec.de
> ---
>  drivers/usb/typec/hd3ss3220.c | 30 +++++++++++++++++++++---------
>  1 file changed, 21 insertions(+), 9 deletions(-)

Does not apply against my tree, what did you make it against?  Can you
redo this against linux-next and resend?

thanks,

greg k-h

Am 23.01.26 um 17:19 schrieb Greg Kroah-Hartman:
> Does not apply against my tree, what did you make it against?  Can you
> redo this against linux-next and resend?

This is strange. I created it against 944aacb68baf (something after 
v6.19-rc5). I can cleanly rebase it to next-20260123 without changes.
Do I miss something?

Jan
> 
> thanks,
> 
> greg k-h

On Mon, Jan 26, 2026 at 08:04:58AM +0000, Jan Remmet wrote:
> Am 23.01.26 um 17:19 schrieb Greg Kroah-Hartman:
> > Does not apply against my tree, what did you make it against?  Can you
> > redo this against linux-next and resend?
> 
> This is strange. I created it against 944aacb68baf (something after 
> v6.19-rc5). I can cleanly rebase it to next-20260123 without changes.
> Do I miss something?

Probably other changes to this file since then?  linux-next will include
the USB development tree that has the work of everyone else in it that
will go into the next release.

Try rebasing and see what happens :)

thanks,

greg k-h

Am 26.01.26 um 10:05 schrieb Greg Kroah-Hartman:
> On Mon, Jan 26, 2026 at 08:04:58AM +0000, Jan Remmet wrote:
>> Am 23.01.26 um 17:19 schrieb Greg Kroah-Hartman:
>>> Does not apply against my tree, what did you make it against?  Can you
>>> redo this against linux-next and resend?
>>
>> This is strange. I created it against 944aacb68baf (something after
>> v6.19-rc5). I can cleanly rebase it to next-20260123 without changes.
>> Do I miss something?
> 
> Probably other changes to this file since then?  linux-next will include
> the USB development tree that has the work of everyone else in it that
> will go into the next release.

I saw on usb-next my v1 is already applied. After removing it, it 
applies well. Sorry for the late change on this patch.

Jan
> 
> Try rebasing and see what happens :)
> 
> thanks,
> 
> greg k-h

On Mon, Jan 26, 2026 at 10:32:40AM +0000, Jan Remmet wrote:
> Am 26.01.26 um 10:05 schrieb Greg Kroah-Hartman:
> > On Mon, Jan 26, 2026 at 08:04:58AM +0000, Jan Remmet wrote:
> >> Am 23.01.26 um 17:19 schrieb Greg Kroah-Hartman:
> >>> Does not apply against my tree, what did you make it against?  Can you
> >>> redo this against linux-next and resend?
> >>
> >> This is strange. I created it against 944aacb68baf (something after
> >> v6.19-rc5). I can cleanly rebase it to next-20260123 without changes.
> >> Do I miss something?
> > 
> > Probably other changes to this file since then?  linux-next will include
> > the USB development tree that has the work of everyone else in it that
> > will go into the next release.
> 
> I saw on usb-next my v1 is already applied. After removing it, it 
> applies well. Sorry for the late change on this patch.

I can't remove a patch from the tree, if there is something different
here, please send a new "fix up" patch for that.

thanks,

greg k-h