> You say you had "emulated" hardware - what this means, exactly? Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page http://w

> You say you had "emulated" hardware - what this means, exactly? Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page http://wiki.qemu.org/Main_Page > Which kinds of drivers you have developed this way? As an example, this approach helped me develop a pin-controller driver[1]. I first added a new bare-bones SoC and machine to QEMU[2] to give me enough of a environment to start adding other models, such as the SoC's System Control Unit[3], which in-turn contains the registers the pin-controller driver pokes at. Using QEMU I could control the initial values in the registers and exercise the pin controller driver's implementation. > I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place. Not entirely - if you are writing the driver you can always pretend it succeeds! Ideally you want to get some gratification as soon as possible - if that means making some assumptions and nasty hacks, that's fine (as long as it won't smoke something!) Then start iterating to iron them out. At least, that's the kind of approach that works for me. [1] https://lkml.org/lkml/2016/7/20/69 https://lkml.org/lkml/2016/7/20/69 [2] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03667.html https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg... [3] https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07042.html https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg070...