Hacker News Reader

Comment by foxhill | Hacker News Reader

> What would be the benefit of that?

well, aside from principle simplicity, you wouldn't need to have a USB stack to have bluetooth connectivity - a protocol plagued with "mysterious" connectivity issues - any reduction in that complexity is a benefit. it might even result in a modest increase in energy efficiency.

> There's zero drivers needed since both the USB controller and the Bluetooth USB device is standarized.

the bluetooth stack is standardized, true, but as far as i understand, this has as much to do with USB as a mouse or a keyboard (indeed, as mentioned in the post, the only required stitch-up work was to between the bluetooth HCI interface and a pcie transport)

> If you now decide to remove the USB controller, all you're doing is suddenly making an incompatible interface that now requires drivers for questionable benefits.

i don't think that'd be the case.

View on HN

> you wouldn't need to have a USB stack to have bluetooth connectivity - a protocol plagued with "mysterious" connectivity issues - any reduction in that complexity is a benefit. it might even result in a modest increase in energy efficiency.

There's very little to this -- USB is a well known standard and power saving in USB is also well understood and exercised. PCIe power saving was not even a thing until relatively recently, and anything you'd developed for this new "HCI-over-raw-PCIe" thing would have to be done almost from scratch. It's ironic, but USB-over-PCIe may actually be the simpler "logical" protocol than raw PCIe, and may even provide further physical power saving considering how dead simple USB is as an interface. Or used to be. Cough.

> USB is a well known standard and power saving in USB is also well understood and exercised. PCIe power saving was not even a thing until relatively recently

well i mean it's all PCIe at the end of the day - all the USB stacks run on top of PCIe lanes - principally anything USB is pure overhead.

> PCIe power saving was not even a thing until relatively recently, and anything you'd developed for this new "HCI-over-raw-PCIe" thing would have to be done almost from scratch.

as far as i can tell PCIe power saving is still not a thing (at least of any significance). in any case, the energy usage of the transport layer and what messages you're sending over it should be largely orthogonal - i don't know exactly what you think you'd need to implement here. i mean, we're not being hypothetical here: apple have literally done this in their new macs, and the blog post specifies what they had to do to make it work in asahi: send the bluetooth HCI messages over the PCIe transport directly!

> [...] and may even provide further physical power saving considering how dead simple USB is as an interface

again, it's all already on PCIe no matter which way you cut it..

> again, it's all already on PCIe no matter which way you cut it..

This is why I said the "it's ironic" part. First, realize that under no circumstances a USB link would be "higher power" than a PCIe link just because logically there is a USB controller which connects via PCIe "no matter which way you cut it, precisely because in a way it matters "which way you cut [the interfaces]". An USB link can be as low as 2 wires. Make the math...

> apple have literally done this in their new macs, and the blog post specifies what they had to do to make it work in asahi: send the bluetooth HCI messages over the PCIe transport directly!

And how do we even know if this is the correct, low power behavior? Have they implemented runtime power management for this device? D3cold rings a bell ?

For better or worse, power management _is_ a well understood problem with USB devices & controllers; you can be pretty sure the Linux USB controller driver is as low-power as it gets; you have much fewer assurances if you go directly to the PCIe. I'm quite sure that the "mysterious connectivity issues" you attribute to USB are in part due to runtime power management logic.

Reply on news.ycombinator.com