On Tue, 2008-06-24 at 22:07 -0500, Larry Finger wrote: > I agree that ssb-sprom should be rewritten; however, before that is > done, we need to think carefully as to what variables should be > exposed for a user. For instance, should antenna gains be brought > out? > What about antenna enable variables? Is there any reason for a user > to > change these?
The reason would be to fix wrong values. I believe everything should be available. If there are any specific concerns about specific fields, there should be warnings. If there are chances to brick the device, there should be big warnings, or perhaps the entries should have a read-only flag. Anyway, ssb-sprom is not for casual users. > In addition, it might be useful to know about new revisions. We now > have an instance of revision 8, where the only locations that have > been identified are the usual ID stuff at the start and the MAC > address. Everything else is unknown. What about revs 5, 6 and 7? That's where having a table with entry descriptions would be helpful. Tables for unknown revisions could start with just a few entries and get populated with entries from other revisions. If there is anything unusual about the unknown fields (e.g. they are big endian or read-only), it could be represented as additional flags. If the firmware was described as a C structure covering the whole firmware, copying entries could shift everything. And the current approach would lead to unmaintainable growth of the code. > -- Regards, Pavel Roskin _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
