[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<ME0P300MB055308B1FC5F1544F906B72DA61C2@ME0P300MB0553.AUSP300.PROD.OUTLOOK.COM>
Date: Fri, 10 Jan 2025 15:37:44 +0800
From: Junzhong Pan <panjunzhong@...look.com>
To: Marco Felsch <m.felsch@...gutronix.de>
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 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?
Best Regards,
Pan
Powered by blists - more mailing lists