On Fri, Jul 06, 2012 at 04:18:40PM -0400, John W. Linville wrote: > Sorry, I kinda lost track of this. I guess I was expecting a repost, > including Bob Copeland's patches and something to address the endian > issues mentioned by Kevin Groenevel. Was anyone planning to address > those concerns? Also, I'm not sure that bit about needing custom > SDD files was fully addressed? Unfortunately, the SDD needs to be supplied by the module vendor, as it's specific to the design. Even more troubling is that there's a register value we have to program that also depends on the design, and there's no way to know that generically. I've solved this by resorting to platform data. Anyway. Onto my main point. ST-E hasn't publically done any work on this driver since around April 2012, and they haven't given me an answer on whether or not it's been abandoned. In light of recent announcements relating to ST-E's future, I'm not hopeful that it'll see any more official support. That said, I've done a ton of work on this driver for my employer. It has far fewer bugs than what ST-E has previously released; including fixing up major endian problems (I brought it up on a uClinux m68k target for another client). It's also vastly more stable, now has SPI support, and has also managed to pass WFA testing. That's not to say it's bug-free, but it at least can be counted on to not HACF randomly. I've been maintaining it on top of compat-wireless, and I'm wanting to give it another upstream push, and be listed as the maintainer. What's the best way for me to do that? The patch series they posted originally (one file per patch) seems rather silly, but at the same time, doing it all at once is a rather substantial chunk to digest/review. > On top of that, there were some style quirks that I was hoping > someone could address. There were "if 0" blocks in the code, which > is rather questionable. Was anyone planning to remove them? Also, > the block comment formats seemed a little random. In particular, the > single-line "/* ********* */" thing looks a bit funny. Perhaps that > isn't the worst thing ever but if you are going to respin anyway than > I'd prefer if you just deleted them. The code I have has a lot of changes there, but I imagine there are more remaining. I'll have to go back and audit things, as I've since given up on keeping my code close to ST-E's "upstream" > There was also talk of a mac80211 patch needed to fix a bug observed > with the driver as posted? Has that mac80211 fix been posted and > merged? If not, when will we see it? IIRC it's because mac80211 doesn't provide a way of pre-allocating MIC space at the tail end of the frame -- the hardware performs the work but still needs the space in the payload. The code I'm maintaining has workarounds for this; not the most efficient solution but I'd rather see the code merged as-is, and then we can incrementally improve things (perhaps by enhancing mac80211 as needed) > So anyway, it seems like a repost of the current version (i.e. with > Bob's fixes, etc) is in order? I'll have to go back and see if any of those fixes are still relevant. Anyway, let me know how I should proceed from here.. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur.
Attachment:
pgpuyRVXaHTNd.pgp
Description: PGP signature
