On Mon, 11 Aug 2008 15:36:41 -0700 Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote: > > From: Kristen Accardi <kristen.c.accardi@xxxxxxxxx> > Subject: [PATCH] libata: Add a module parameter to skip probing of specific ports > > Port probing by libata can easily take 10% or more of the kernel boot > time (2%+ of total). For cases where one knows there is nothing > connected to certain ports (for example on netbooks) this is a waste > of boot time. > > This patch adds a module parameter that allows the admin to specify > to skip ports (specified by a bitmask) and recoup this boot time. > This capability is potentially also useful to get systems to boot > for cases where port-probing on a certain ports causes crashes. > > A follow-on patch will add the capability to use DMI identification > to automate this for certain known systems. What happens if I plug in an additional libata using device ? What defines the probe order here particularly as people are pushing for parallel probing of multiple devices. This doesn't appear to make any rational sense as the mask isn't tied to the actual bus device identifier to keep it on the same port. It might kidn of work for an EEEPC (until you see what people retrofit into the corners of them) but it isn't a valid general solution. Also the EEE problem seems to be a controller specific screwup - they didn't apparently manage the enablebits on the ATA controller correctly, so it belongs in that driver. That also lets you tie it to the right system, pci id, bus id so it'll always hit the right device. (Plus double check the enables code in case you are papering over the real bug) Second problem is you've changed the API. Several drivers do things on the port 0 register they know they will receive and will simply crash and burn if you change this. NAK this patch for now: right theory, wrong implementation. Please post a version which uses DMI in the relevant driver and checks the PCI DEVFN matches. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
