On Wed, 2008-10-22 at 15:59 -0700, Marcel Holtmann wrote: > in some cases it might be possible with a set of quirks or special > functions that can be switched at runtime. Check the whole bunch of USB > drivers that have special handling depending on what hardware it finds. > We could do the same. In some cases this effort might be too much, but > if possible we should at least try. I don't think we can easily apply the hardware quirk solution here. This is because hardware can be identified by id that does not change and the hardware self does not really change (unless it has firmware that changes ...). In this firmware case we do not have "an id" (we have one file that is loaded by firmware loader so we cannot know what we get just by "looking at it" unless we enforce a version number in the filename as we currently do in our driver) and the firmware can change, potentially frequently, with the consequence of many "quirks" that need to be maintained. > It all depends on how much the ucode API changes and sometimes we really > wanna cleanup the driver and remove the old code, but in that case we > have to tell the users via modules_install that this kernel will break > or we have to keep the old driver around. Breaking it from one kernel > version to the next one without the user noticing only after reboot is > just not good enough. I agree with you and Johannes in this regard and look forward to the modules_install solution. I do hope this will be acceptable to everybody. Reinette -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
