Well, I'm trying to clean up some things first, and I need to test DR and suspend resume. (A lot of the clean up is making this driver work, and work well, on x86. There were some ugly code paths in the DMA flow in hme. I'm cleaning all that code up.)
Anyway, I'll probably post a web and binaries up in the next week or so. Integration into Nevada itself is unclear, because of the "official" QA test burden.
May 11, 2007 at 9:46 PM
The conversion of hme to gldv3 looks like it is a success. The driver "Just Worked" from the first time I loaded it. Yay.
Still to be tested are the main areas of risk: VLANs, SUSPEND/RESUME, and DDI detach. Stay tuned for more on that front.
I'm going to have to preserve qfe as a seperate driver, I think, because renaming/renumbering devices is just going to cause too much grief in the field. But, what I'm going to do is make hme.c and qfe.c very small (say ~50 lines each), and have them use a common misc module to provide the entire functionality.
I have now received several qfe boards as well, so I'll be testing on x86 soon, as well.
Watch this space for the code review to be posted.
"hme gldv3 status report"
2 Comments -
When can we expect to see integration into Nevada? I would love to try out this code on my ultra 2.
May 10, 2007 at 12:39 PM
Well, I'm trying to clean up some things first, and I need to test DR and suspend resume. (A lot of the clean up is making this driver work, and work well, on x86. There were some ugly code paths in the DMA flow in hme. I'm cleaning all that code up.)
Anyway, I'll probably post a web and binaries up in the next week or so. Integration into Nevada itself is unclear, because of the "official" QA test burden.
May 11, 2007 at 9:46 PM