The protocol is exactly the same as for the bi*fury devices (and also the same for the One String Miner), so cgminer already supports them.
The code assumes 2 job queues so I assume you worked within that framework despite the extra chips?
Not sure where the 2 job queues come from, but the firmware internally uses a single queue with room for 4 jobs. That's the same on bi-fury and hex-fury. The only difference is that the hex-fury jobs are processed faster because there are more chips, but this should be transparent for the driver.
I wrote the driver for BXF aka Bi*fury at the time and while it sends enough work based on the request for more work, it stores data in its API assuming 2 chips exist because that's all the original devices had. As I said earlier, it probably only affects the data that's shown in the API. A string of invalid chip number messages in verbose mode and lack of debug support for the extra chips is likely the only consequence, but I don't know how many people ever looked at the API output of these devices which I originally added to aid debugging of which chip was doing what:
[STATS3] =>
(
[STATS] => 3
[ID] => BXF0
[Elapsed] => 79099
[Calls] => 0
[Wait] => 0.000000
[Max] => 0.000000
[Min] => 99999999.000000
[Version] => 1.2
[Revision] => 1
[Chips] => 2
[NonceRate] => 0.663417
[NoMatchingWork] => 0
[Temperature] => 48.400000
[Max DeciTemp] => 525
[Clock] => 54
[Core0 hwerror] => 598
[Core1 hwerror] => 142
[Core0 jobs] => 8458
[Core1 jobs] => 8227
[Core0 submits] => 5239
[Core1 submits] => 5581
[USB Pipe] => 0
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 46161 0
)
EDIT: Shouldn't be hard for me to generically change it to as many chips are reported in chips, but I believe some earlier samples/firmware didn't report that so I'll add a workaround.