On 20-12-21 11:25:51, Alan Stern wrote:
> 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?
>
Of course. I think the similar use case like below:
Program A (Port power control program)
while (1) {
- Wait "turn off" command;
- Claim requested port;
- Turn off requested port;
- Wait "turn on" command;
- Turn on requested port
- Release requested port;
};
Program B actually is a script:
{
while [ "$i" -lt 10000 ];
do
- Check Flash Drive is there (eg, cat /proc/partitions);
- Send "turn off" command;
- Wait 5 seconds, and check if Flash Drive has gone;
- Send "turn on" command;
- i=`expr $i + 1`;
done
terminate program A;
};
I need to find communication solution between program A and script B.
Or would you have any suggestions to design such kinds of test case?
--
Thanks,
Peter Chen
