On Tue, Nov 07, 2017 at 08:49:46AM -0800, Linus Torvalds wrote: > On Tue, Nov 7, 2017 at 2:24 AM, Fengguang Wu <fengguang.wu@xxxxxxxxx> wrote: > > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. > Yeah, very doubtful. Nobody has touched that spi-butterfly driver in > about two years. Indeed. I'm not super convinced anyone who actually has the hardware has touched the driver since David Brownell was maintaining SPI, all the changes since then seem pretty mechanical. > > [ 13.141240] sysfs: cannot create duplicate filename '/devices/pnp0/00:04/spi_master/spi42' > > [ 13.142495] ------------[ cut here ]------------ > I'm not sure why that driver even gets initialized under qemu. I'm > assuming it just tries to attach to any parport. Yes, if there's any mechanism for constraining what it attaches to it's in the parport subsysetm. This simply provides an attach method which the parport subsystem looks like it calls on any parport in the system. I'm a little confused about how it ends up getting registered multiple times but that looks like it should be something in paport (I noticed some stuff about allowing multiple devices on one port). > Mark, should it have a stricter check perhaps? Or should this driver > perhaps simply not be loaded by the zeroday robot? Loading parallel port client drivers (or other semi-enumerable drivers) seems like a recipe for trouble. In this case there's never been any code there that attempts to work out if there's actually a butterfy device on the parport, just a REVISIT comment in the code which isn't much help. Looking at the docs for the driver it's intended to control an AVR32 microcontroller reference board running some custom program (with instructions on how to make the cable!) so I don't hold out much hope. I'm tempted to just remove the driver though I fear it might have some actual users for industrial processes still.
Attachment:
signature.asc
Description: PGP signature
