On Wednesday 06 September 2006 20:03, Shaohua Li wrote: > On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote: > > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: > > > From one of the ACPI guys: > > > > > > > Get hid > > > > Look for driver > > > > If you find a match, load it > > > > If no match, get CID > > > > Look for driver > > > > If you find a match, load it > > > > If you did not find an hid or cid match, punt > > > > I think this is what my patch is doing. > > > > when looking for a driver: (acpi_bus_find_driver) > > I check against the HID > > return if found > > Then I check against the CID > > return if found > > else > > punt > > > > Any objections to pushing this into -mm and dropping the motherboard > > change? > I'd prefer not take this way. The ACPI driver model is already mess > enough, let's don't make it worse. We are converting the ACPI driver > model to Linux driver model, this will make the attempt difficult. I see that driver_bind() and driver_probe_device() don't mesh well with the idea that multiple drivers might be able to claim a device, because there doesn't seem to be a way to prioritize one driver over another. Is that the problem you're referring to? If we decide that "try HID first, then try CID" is the right thing, I think we should figure out how to make that work. Maybe that means extending the driver model somehow. > We can let the motherboard driver not bind to your device (say we didn't > register the motherboard driver, but just reserve the resource of the > deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the > mem region of the device too). My point was that ACPI tells us what resources the device uses, and we should reserve all of them so we accurately model the system. Reserving resources without registering the driver sounds like a hack to work around broken behavior elsewhere, so I don't think it's a good idea. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
