Am Montag 07 Januar 2008 schrieb Michael Buesch: > > Still, if you can add the support for it as a feature that doesn't affect > > the people's working configurations, no one will complain. > > Impossible, sorry. > We are going to add support for new firmware, which will be needed for > N-PHY, or we don't. > And I think it's clear which way we are going.
N-PHY support is surely wanted, noone doubts that. > What's the problem with all of this? Other drivers change firmware to > incompatible versions on a regular basis. Look at ipw2200. There was a time > when they changed the firmware basically on every kernel release. > That wasn't a problem. Why would it be a problem here? The problem is _not_ to actually need a newer firmware for a newer kernel. That can be managed easily and was simple for the change bcm43xx -> b43. However, being able to use different kernel version painlessly is a major feature. Modprobe cannot use different configs for different kernel versions, so the fwpostfix option doesn't help in userspace. The only work-around would be to change /lib/udev/firmware.agent to also use the kernel version when looping over possible firmware directories. Clumsy at best, especially since the driver knows best about the difference. I already suggested to make the ABI part of the directory name (maybe even kill fwpostfix for it, anyone actually using that one for real?). That's a one-minute change in the driver (one #define and one other one-liner in main.c) and an additional table field in fwcutter. You have to update the latter anyway to let it know about the new firmware files, anyway. With that, you can require a different firmware ABI on kernel version change and possible noone will complain. And you don't have to support multiple ABIs at the same time. HS _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
