On Mon, Dec 21, 2020 at 05:37:29AM +0000, Peter Chen wrote:
> On 20-12-16 10:51:44, Alan Stern wrote:
> > On Wed, Dec 16, 2020 at 02:56:20AM +0000, Peter Chen wrote:
> > > On 20-12-15 10:55:41, Alan Stern wrote:
> > > > You've got the general idea.
> > > >
> > > > Normally ports are owned by the hub driver. If one of them loses power
> > > > for some reason (for example, the user turns it off), the hub driver
> > > > will turn the power back on. This is because the hub driver wants
> > > > ports to be powered at all times unless they are in runtime suspend.
> > > >
> > > > The way to prevent the hub driver from managing the port power is to
> > > > claim the port for the user, by issuing the USBDEVFS_CLAIM_PORT ioctl.
> > > > Also, when that is done, the kernel wno't try to manage a device
> > > > attached to the port -- that is, the kernel won't automatically install
> > > > a configuration for a new device and it won't try to probe drivers for
> > > > the device's interfaces if the user installs a config.
> > > >
> > >
> > > Alan, we have several use cases for power switchable HUB, one of the use
> > > cases is USB port is managed by kernel (eg, needs mass storage
> > > class), but needs to toggle port power, is it reasonable we add a sysfs
> > > entry to support it?
> >
> > Can you give more information about your use cases? After all, if the
> > port power is turned off then the port can't possibly handle
> > mass-storage devices -- or anything else.
>
> Sorry, Alan. Due to holiday season, the U.S team doesn't reply me the
> use case. I think the basic use cases are emulate the hot-plug test for
> USB devices, the USB devices could be Flash Drive on market or DUT (Device
> Under test) for the same controller works at device mode. Assume one
> typical test case:
>
> Plug in Flash Drive at port 1-1.1 during the boots up:
>
> while (1) {
> - Check Flash Drive is there (eg, cat /proc/partitions)
> - Turn port 1 at 1-1 off
> - Check Flash Drive is gone
> - Turn port 1 at 1-1 on
> }
Okay. This can be done as follows:
while (1) {
- Check Flash Drive is there (eg, cat /proc/partitions)
- Claim port 1 on 1-1
- Turn port 1 at 1-1 off
- Check Flash Drive is gone
- Release port 1 on 1-1
- Turn port 1 at 1-1 on
- Delay for 10 seconds (time for device probing)
}
> > On the other hand, if the port is managed by the kernel then the kernel
> > (not the user) should be responsible for deciding whether or not to
> > turn off the port's power.
> >
> > If there's some real reason for turning the port power off for an
> > extended period of time, the user can claim the port and turn off the
> > power. Then later on, the user can release the port and turn the power
> > back on.
> >
>
> Yes, I think this is one of the use cases. We want power power control
> at one application (A), but different with our test application(B), it means
> if the user claims the port, and power off using A, then the A will end.
> After the B finished running, A runs again for power on, but at this time,
> the port owner has changed.
Yes, that won't work. If you want to keep the port power turned off
then you have to keep the usbfs device file open -- which means your
program A must not end and then restart.
(Acutally, I'm not certain about that. If you claim a port, turn off
its power, and then release the port, I don't remember whether the hub
driver will then turn the power back on right away. It might not.
But in any case, it isn't good programming to release a port without
turning its power back on.)
Can A be rewritten so that it doesn't end when B is running?
ALan Stern
