linux-kernel - Re: [PATCH 1/3] usb: hub: add infrastructure to pass onboard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250303102542.gbzhvnygj5ve5qrf@pengutronix.de>
Date: Mon, 3 Mar 2025 11:25:42 +0100
From: Marco Felsch <m.felsch@...gutronix.de>
To: Junzhong Pan <panjunzhong@...look.com>
Cc: broonie@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
	festevam@...il.com, gregkh@...uxfoundation.org,
	kernel@...gutronix.de, krzk@...nel.org, lgirdwood@...il.com,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	lkp@...el.com, matthias@...hlcke.net, mka@...omium.org,
	oe-kbuild-all@...ts.linux.dev, robh@...nel.org
Subject: Re: [PATCH 1/3] usb: hub: add infrastructure to pass onboard_dev
 port features

Hi,

sorry for the late response...

On 25-01-10, Junzhong Pan wrote:
> Hi Marco,
> 
> Thank you for your reply!
> 
> On 2025/1/6 14:52, Marco Felsch Wrote:
> > On 24-12-31, Junzhong Pan wrote:
> > > 
> > > I recently encountered some kind of platforms using an existing onboard
> > > hub yet their HW don't utilize the USBPE port power control feature
> > > while the hub support it.
> > > Instead, we have another GPIO for controlling the vbus of those ports
> > > to cut the cost.
> > 
> > That's exactly our use-case too.
> > 
> > > Wonder any idea could use this driver considering the limitation of
> > > the usb compatible set the properties of onboard_dev_pdata hard coded?
> > 
> > Sorry but I don't get this.
> If the hub have 4 ports, but board only have one gpio to controll all those
> vbus at once, implemented as some kind of gang mode.
> 
> In this case, the onboard_dev driver may not respond to the
> USB_PORT_FEAT_POWER, but keep the supply always on except for the suspend
> states.
> 
> Do you have any idea how we handle this?

I can think of one crude workaround. Adding 4-regulators which use the
same shared gpio. This requires the gpio to be requested as shared if
that is possible.

Regards,
  Marco