Re: USB regression in 10.1

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 25 Jan 2025 12:27:32 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <vn2lbk$8il$1%serpens.de@localhost>

  | The device doesn't suddenly go into online state, this is triggered
  | by (some forms of) accessing it. You must force it to online state,
  | before you can scan it and create wedge devices.

That must be easy, and I know that without knowing anything about the
protocols involved.   These devices are mostly used on wintrash systems,
and wintrash users simply expect "plug it in and it works" (occasionally
perhaps a driver might be needed, but that's only ever the very first time).

So, however well we currently handle things, the "plug it in and it works"
must be possible, for all of these kinds of devices - any for which it
wasn't true wouldn't be available, as no-one (maybe NetBSD users excepted,
but there aren't enough of us to count) would buy the thing otherwise.

  | So the only method is to try to start it, and repeat continously
  | until success.

If that is what wintrash does, but I kind of doubt it, that doesn't
sound like an operational model that makes a lot of sense.   We know
we can recognise the device when it is connected to the USB bus, ready
to be used or not (that part works fine now) - at that point it is
possible to send it commands, I'd suspect that one of those is going to
be a "report when ready" kind of thing, or perhaps "make ready", that
would be easy to implement at both ends.

  | N.B. as this behaviour is rare for simple USB disks, a PQUIRK_START
  | for one or more WD Elements models might be all we need here.

I'm not sure what you think is rare, essentially all of my external
USB (rotating rust) drives work like this.   They're not ready to do
I/O until they're up to speed, which takes time after power on.  That
is time easily measurable on a human scale, just looking at a clock,
not milliseconds or similar.

Until recently (in the period before that - which doesn't necessarily
mean back to the beginning of USB support in NetBSD - I haven't been
using this kind of device nearly that long) when the drive came up to
speed, that is, became ready, the kernel would find the wedges (just
the same as when the device was already ready when the system boots,
which they might be if the bios has been out looking around in them for
boot partitions, if already plugged in at the time).

Whatever PQUIRK_START causes to happen might be sufficient for that, I
have no idea.   I expect that will fail for things like card readers with
no card inserted, and optical drives with no media inserted, but either
that will cause the right thing to happen once media is properly installed,
or there is something else that we could do to make it - as once again,
if it didn't "just work" (as in make the drive appear in the windows
whatever it is that shows such things - and in windows cases, which we
definitely don't want, automatic mounting and running of startup scripts)
then those users would consider the device broken, and return it.

kre