Even in that case, the driver communicates with the device firmware to change the LED.
This is obvious, because LED is connected to MCU. But the main sense here is which code controls the LED state. When LED state is controlled by driver code from PC side, MCU firmware don't control the LED, it just get state from the driver and put it to GPIO.
No, really. The
"But the main sense here is which code controls the LED state" is wrong approach in the context of this thread.
It is a significant distinction, if we consider the entire model here. (So, please, let's not start discussing what "control" might actually mean to different people.)
You see, to allow a host device to control the LED, the firmware must offer a way for the host to control the LED state. The host cannot "take" control over the LED without explicit co-operation from the firmware. The firmware cannot just hand over the LED state to the host, and instead must implement the interface the host can use to set the LED state. For every LED state change the host wants, the firmware must actually perform the change. See?
If we then limit to USB, we can clearly check the standards to see that there are no such interfaces for ordinary USB device
activity LEDs; definitely not for USB Mass Storage (which includes both memory sticks and media converters). There are for keyboard LEDs, but even those are mostly handled by the keyboard itself, with host only in very specific circumstances, like boot, telling the keyboard to set them to a specific state.
For Ethernet (over USB), see Communications Device Class (CDC, PDF v1.2) Ethernet Control Model (ECM) protocol (currently in ECM120.pdf in the previous ZIP archive). If I recall correctly, it does not have any activity LED controls at all (so those would have to be driver-specific extensions), and the LEDs are fully controlled by the device firmware.
As I remember, for ethernet PHY you can control LED function with configuration and control registers which is available through MDIO bus.
Not for USB devices, which is what this thread is about. Please do not expand the topic to
all ethernet devices or non-USB IC's. (I, too, probably should not have even mentioned PS/2 either, and kept to USB only. Apologies.)
The OP is already on a bad track, so it is best to avoid adding to their confusion. In particular, I'm worried they might now be searching for USB MDIO, arriving at TI
USB-2-MDIO, and wondering how they might apply that to solve their problem. They cannot; it is irrelevant to USB, as USB-2-MDIO is just an application one can use with certain microcontrollers to program TI Ethernet PHYs that will be connected to some microcontroller, without having to implement that programming on the microcontroller the PHY will be used with.
I don't mean you're
wrong per se, mind you. The
Teensy 4.1 development boards I have, do have a
TI DP83825i 10/100 Ethernet PHY, which does implement the standard LED controls you mentioned (see 7.6.25 on page 62 on the TI DP83825i datasheet). But all that is via the MDIO bus, connecting the PHY to a microcontroller, and has nothing to do with USB. Strictly speaking, though, even here the PHY firmware is in control of the LED state, and only exposes an interface –– the 16-bit LEDCR register at offset 0x18 that a host can read and write, via the MDIO bus –– to change the LED behaviour and state.
I understand your idea of focusing on which code decides on the policy of how and when a LED is lit, but it is not appropriate in the context of this thread. Here, the discussion is about detecting
activity and showing activity (or idleness) using a LED. In practice, this always happens at the firmware level on the device. Some devices do expose an interface for the host to control the LED state, but it is limited to specific devices, and very uncommon over USB. Trying to detect activity by examining the USB 2.0 D+ and D- voltages is a crude hack that has a lot of gotchas, including low-speed and full-speed (1 Mbit/s and 12 Mbit/s) having different voltage levels to high-speed (480 Mbit/s). My entire point in this thread has been to
use the information the device firmware gives you, instead of trying to do it at some other level of complexity; and it is also the reason for my pushback here, to try and push OP to the right track. Definitely no offense or snarkiness or anything like that meant; and in another context, I'd be happy to discuss various systems programming aspects of LED activity controls as implemented in many Linux-based appliances like routers and NASes –– one of my hobbies is to add nontechnical-end-user friendly displays and indicators to such.