Hi Tomas, > >> > > >> > >> Two new versions of 3945 uCode is now available for download from > >> > > >> > >> http://intellinuxwireless.org/?n=Downloads. Two versions are available > >> > > >> > >> as we have updated the API version of the uCode and included pending > >> > > >> > >> fixes in both API versions. > >> > > >> > >> > >> > > >> > >> Version 15.28.1.8 supports API v1 and can be used with most current 3945 > >> > > >> > >> drivers. Version 15.28.2.8 (API v2) is required when you start using the > >> > > >> > >> latest 3945 driver from wireless-testing at the time it includes the > >> > > >> > >> patch "iwl3945 : Fix a-band association for passive channels". > >> > > >> > > > >> > > >> > > Can you make the driver work with the old ucode? We even do that for > >> > > >> > > drivers where we don't control the ucode like b43... > >> > > >> > > >> > > >> > What for? > >> > > >> > >> > > >> Well, so that installing a new kernel doesn't suddenly break your > >> > > >> network connection and ability to download the firmware, for instance. > >> > > >> If you want more arguments you can go read all the "b43 sucks" threads > >> > > >> about it. > >> > > > > >> > > > Johnannes has a point, that is a lot nicer to users... > >> > > > >> > > Maybe, but it will complicate the code beyond good taste to just > >> > > satisfy the single moment when kernel is upgraded. I don't mean in > >> > > general I mean in this particular case when API changes. > >> > > Anyhow a good distro shell deal with this in packaging dependencies > >> > > and normal person will keep old kernel around when compiling new one. > >> > > Both ucodes can be present on the file system at the same time so I > >> > > hope the risk is low. > >> > > >> > it is the same argument as for everything else. We should be able to run > >> > a new kernel with old userspace. > >> > >> I do not believe our request is unreasonable. If a user runs a new > >> kernel the log will print a message that the firmware is incorrect ... > >> all the user needs to do is go to > >> http://intellinuxwireless.org/?n=Downloads and download the latest > >> firmware. This does not require any subtle changes that may affect other > >> aspects of the system ... just the firmware file that is only used by > >> the driver. > >> > >> We are focused on upstream development. If there is a need to support > >> older ucode then we face a similar challenge as was solved through the > >> compat-wireless project for the driver self. > > > > I haven't checked this particular case, but in some cases it is simple > > to keep backward compatible code around that would let us support the > > old firmware for a few releases. In other cases the driver and firmware > > interface might have evolved too much to do so. In these cases we might > > wanna keep the old drivers around so users can have a choice. > > If it wasn't so awkward in this case I wouldn't mind to support old firmware. > Second when we touch firmware especially for old HW it means that it > solves a bug so why ones would use old driver for something else then > to download the new firmware. if possible, we should try to support old ucode APIs with the latest drivers. In some situations that might be not possible, but we should at least try. > > We do have something like drivers/staging/ now. It might make sense to > > have introduce drivers/deprecated/ for old drivers that we just keep > > around for a few releases to ease a transition. Just thinking out loud. > > Sounds like good idea... need some configuration tricks tough unlike > staging here we have 2 drivers for the same hw That is just some Kconfig magic :) > > And I have been bitten by ucode API changes in the past. It is just not > > clear when actually compiling the new kernel. We could also have compile > > time checks that check the new firmware file is actually present at the > > compile time of the new kernel. The driver should have a MODULE_FIRMWARE > > tag and we could process it and match it to /lib/firmware. > > It has MODULE_FIRMWARE already I know, but we need to actually make better use of this information in a generic post compile step to check that the firmware is actually in place and warn if it is not. Then you can go ahead and download it before actually booting a kernel with a now broken wireless card. This is not even Intel or wireless specific. We should do this for all kinds of drivers. Regards Marcel -- 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
