Things may sometimes seem deceptively simple. Please allow me to explain.
One of the problems is that using software to cut the power from a plugged-in USB device is actually not possible on regular USB ports. The available power-related knobs in /sys actually only tell the plugged-in USB devices to go into suspended state, and it's up to the particular USB device to do (or ignore) the requested suspend operation. In other words, no power cuts are actually performed by the host.
Maybe it's possible to cut power on USB ports that are present on some SBCs, which I'm not sure about at the moment, but the lack of that feature on regular (i.e. found on PC motherboards) USB ports turns the whole thing into being impossible to automate. We must not rely on testing using only the USB ports on a few select SBCs.
Moreover, it's not just about cutting the power. The four USB 2.0 strips inside the USB Type-A plug are intentionally not of the same lenght; the two strips that carry power are longer than the strips that carry data, so the device has some time to wake up before the data lines are connected upon plugging a USB device into a USB receptacle. In the scenario of cutting and re-establishing power to a USB device, there would be no such delay, which would take the whole setup out of the USB specification and make the whole automated setup rather pointless.
It's even worse with USB 3.0; sometimes, USB 3.0 devices are seen as "ghost" USB 2.0 devices upon unplugging them from a USB 3.0 host receptacle. All that due to the different positions and lengths of the USB 2.0 and 3.0 pins inside the connectors.
Edit: By the way, flash memory is inherently of a COW nature. However, the only way we could guarantee data consistency in presence of sudden power cuts is to use raw flash, with no built-in wear leveling, and do everyhing in the device firmware. If the flash does anything on its own, using some sort of a built-in microcontroller, all bets are off and no data consistency can be guaranteed.
Edit #2: I stand corrected. It is actually possible to use software to cut power on regular USB ports, with certain rules and restrictions as described in detail here, but the note on having no delay between connecting power and data lines still remains.
One of the problems is that using software to cut the power from a plugged-in USB device is actually not possible on regular USB ports. The available power-related knobs in /sys actually only tell the plugged-in USB devices to go into suspended state, and it's up to the particular USB device to do (or ignore) the requested suspend operation. In other words, no power cuts are actually performed by the host.
Maybe it's possible to cut power on USB ports that are present on some SBCs, which I'm not sure about at the moment, but the lack of that feature on regular (i.e. found on PC motherboards) USB ports turns the whole thing into being impossible to automate. We must not rely on testing using only the USB ports on a few select SBCs.
Moreover, it's not just about cutting the power. The four USB 2.0 strips inside the USB Type-A plug are intentionally not of the same lenght; the two strips that carry power are longer than the strips that carry data, so the device has some time to wake up before the data lines are connected upon plugging a USB device into a USB receptacle. In the scenario of cutting and re-establishing power to a USB device, there would be no such delay, which would take the whole setup out of the USB specification and make the whole automated setup rather pointless.
It's even worse with USB 3.0; sometimes, USB 3.0 devices are seen as "ghost" USB 2.0 devices upon unplugging them from a USB 3.0 host receptacle. All that due to the different positions and lengths of the USB 2.0 and 3.0 pins inside the connectors.
Edit: By the way, flash memory is inherently of a COW nature. However, the only way we could guarantee data consistency in presence of sudden power cuts is to use raw flash, with no built-in wear leveling, and do everyhing in the device firmware. If the flash does anything on its own, using some sort of a built-in microcontroller, all bets are off and no data consistency can be guaranteed.
Edit #2: I stand corrected. It is actually possible to use software to cut power on regular USB ports, with certain rules and restrictions as described in detail here, but the note on having no delay between connecting power and data lines still remains.
