Messages in this thread | | | Subject | Re: tp_smapi conflict with IDE, hdaps | From | Alan Cox <> | Date | Tue, 13 Dec 2005 16:16:15 +0000 |
| |
On Maw, 2005-12-13 at 18:04 +0200, Shem Multinymous wrote: > > What else does that code do, what else might it confuse, what rules and > > locking are hidden in the windows driver that are unknown. Want to risk > > everyones data for that ? > > We already take that risk to some degree, since the SMAPI BIOS is also > invoked by the ACPI DSDT and by external events.
But the ACPI DSDT is OS independant in theory and in practice to a fair extent. It can't make assumptions about windows drivers.
> > HDAPS doesn't need it btw. > > It's not implemented yet, but I gather it's necessary for preventing > the disk from spinning back up as the laptop slides off the table. > Maybe I missed some subsequent discussion?
HDAPS wants to be able to talk with the IDE/libata layer to request it to hold off requests, thats very different to "gee I wonder what the bios did"
> You write "command" values into IO ports 0x1610 and 0x161F and, in > some cases, read some results from ports 0x1610-0x161F. Throughout > that, you inspect various bits (whose meaning we don't understand) in > the status port 0x1604. The details of the commands, scheduling and > status bits differ between the drivers. I don't think a full-blown > ownership and expansion infrastructure is necessary, or even possible > without better understanding.
Ok
> Thanks for the pointers. I guess the minimal approach is probably > ideal here; are there any such dumb drivers lying around?
Its probably easier to write than go find one
I mean you need
tp_hw_init() { if (not a thinkpad) return -ENODEV request_region(...) return 0 }
tp_hw_exit() { release_region(...) }
EXPORT_SYMBOL_GPL(tp_hw_lock); EXPORT_SYMBOL_GPL(tp_hw_unlock);
tp_hw_lock() { down(&tp_sem); }
tp_hw_unlock() { up(&tp_sem); }
/* And perhaps if the port varies by machine */
EXPORT_SYMBOL_GPL(tp_hw_addr);
tp_hw_addr() { return 0x1600; }
It can really be that simple
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |