[HN Gopher] Hardware hotplug events on Linux, the gory details
       ___________________________________________________________________
        
       Hardware hotplug events on Linux, the gory details
        
       Author : todsacerdoti
       Score  : 93 points
       Date   : 2026-03-02 09:26 UTC (3 days ago)
        
 (HTM) web link (arcanenibble.github.io)
 (TXT) w3m dump (arcanenibble.github.io)
        
       | krasikra wrote:
       | Excellent deep dive. The uevent/netlink path is one of those
       | things every Linux developer should understand but few actually
       | trace through.
       | 
       | One thing worth adding: on embedded systems (ARM SBCs, Jetson
       | boards), hotplug behavior can be surprisingly different from x86.
       | Some device tree overlays don't fire proper uevents, and you end
       | up polling sysfs as a fallback. The kernel's device model assumes
       | a level of firmware cooperation that embedded vendors don't
       | always provide.
       | 
       | The kobject lifecycle diagram alone makes this worth bookmarking.
        
       | robinsonb5 wrote:
       | I can't help feeling that the old XKCD cartoon [1] about life
       | satisfaction being proportional to the time since last opening
       | xorg.conf could equally apply to udev.
       | 
       | For instance, I tinker with FPGA boards, and one board in
       | particular presents both a JTAG and serial port over USB. Nothing
       | unusual there, but while most such boards show up as
       | /dev/ttyUSBn, but this one shows up as /dev/ttyACM0. I eventually
       | figured out how to make the JTAG part accessible to the tools I
       | was using, without having to be root, via a udev rule. The serial
       | side was defeating me though - it turned out some kind of modem
       | manager service was messing with the port, and needed to be
       | disabled. OK, job done?
       | 
       | Nope.
       | 
       | A few days ago I updated the tools, and now access as a regular
       | user wasn't working any more! It turns out the new version of one
       | particular tool uses libusb, while the old version used rawhid
       | (that last detail is no doubt why I had such trouble getting it
       | to work in the first place) - and as such they require different
       | entries in the udev rule. I'm getting too old for those kinds of
       | side quest, especially now a certain search engine is much less
       | use in solving them.
       | 
       | (Not naming the tools because I'm not ranting against them - just
       | venting about the frustration caused by the excessive and
       | seemingly opaque complexity. Having got that off my chest, I'll
       | go read the article, in the hope that the complexity becomes a
       | little less opaque!)
       | 
       | [1] https://xkcd.com/963/
        
       | philips wrote:
       | Sort of relatedly: I bought an inexpensive DDR pad recently that
       | worked on coldplug but not hotplug.
       | 
       | It turns out the firmware on the pad isn't quite ready to be
       | polled for USB descriptors right when it is plugged in so you
       | have to put in a little udev hack to suspend it then let it
       | reconnect. At which point it comes back correctly.
       | 
       | (The manufacturer included a little debugging flyer telling you
       | to plug the device in slowly to work around this issue haha)
       | 
       | For those interested: https://github.com/batocera-
       | linux/batocera.linux/issues/1547...
        
       ___________________________________________________________________
       (page generated 2026-03-05 23:00 UTC)