That would require a set of data inputs and outputs for each chip, which is a lot, and isn't possible with the current design. ie. 4 lines per chip and a lot more firmware overhead to handle it. The chips are designed to chain, splitting jobs, and there isn't any efficiency gain by running a job per chip.

That's right but also if you add the 5th chip it will break nonce ranges as if 6 are present which will still work but will leave 1/6th of the ranges unchecked. This doesn't cause problems and since any range is good as another, as long as each chip is checking unique ranges, it's still efficient. A job will finish slightly more often (4 split vs 6 split), so that's the only overhead timing loss.

I haven't verified the code yet but during device init it sends known good data to each chip with a specific nonce count such that a known delay will produce a result. It then counts the results that come back sequentially, and uses this to determine chip count. Due to the chaining connections (hardware) the chips must be installed in a given order, and optimally it's best to balance between banks. I'll be testing this chip count code when I get more chips on board.