On 11/19/2009 12:30 PM, Michael Buesch wrote: > On Thursday 19 November 2009 12:16:46 Oncaphillis wrote: >> On 11/19/2009 12:09 PM, Michael Buesch wrote: >>> On Thursday 19 November 2009 12:07:30 Oncaphillis wrote: >>> >>>> So I'm at a loss here, but if someone comes up with a bright >>>> idea to test or needs more informations I'm willing to test >>>> the resulting code on my machine. >>>> >>> Erm, no. Can you please answer the questions that you didn't answer, yet? >>> Especially the request for the original vendor driver. >>> >>> >> oh sorry. I did that, but the mail only went to larry -- stupid me -- the >> device didn't come with a CD/DVD and I killed Windows XP right away. > > Ok, very nice. -.- > > There are two major problems with not having an sprom: > > - We don't have the calibration data for the radio amplifiers. > That could possibly be solved by providing a sane default set of data > for a device type. > - We don't have a MAC address for the card. This one is _very_ hard to > solve properly. Several solutions come to mind, which are not > really clean solutions: > 1) We generate a random MAC. This would change on every reboot and break > udev. > The problem with this is obvious. > 2) We generate the MAC by hashing some device-specific PCI config space > values. > I don't know if there are any device specific serial numbers or > something > similiar in PCI config space (or somewhere else). > So the problem with this is that I don't know _what_ to hash. > 3) We use the firmware loader to get an sprom image and have a userspace > script > take care of the generation of the image. > The problem is the major inconvenience. >
Hi, Did any of the patches for a device without a sprom make it into the 2.6.33-rc2 ? Thank you. O. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
