Firmware
So, I had the hardware, I had the datasheet... whipping up the firmware shouldn't be that hard, should it? Just implement some kind of menu structure and send i2c-commands to the card dependant of the option chosen. That's what I thought, but there were some hurdles on the way.
First of all: the i2c-implementation in the switch chip isn't entirely i2c-compatible. For one, it needed an extra clock-cycle before and after every transfer. That wasn't too hard to solve: just start a fake i2c-transfer and abort it. Secondly, however, it violated protocol on the read-operations: you start them by telling the device using the I2C-standard R/W-bit that you're going to read from it but then go and actually write the address to it first. That wouldn't be such a problem with a software i2c-stack... but I had decided on using the hardware i2c-implementation for a change, and after about an hour of debugging I found out that it refused to write anything to the device on a read-operation. Eventually, I whipped up a software-based i2c-driver and things went much smoother.
The second problem I ran into was more difficult to solve: When I first read out all registers of the device, none of the values I found there made any sence when compared to the datasheet. Naturally, I suspected my code but it seemed to work flawlessly. Then I took a look at the typenumbers: the chip in my switch was a RTL8366SB, while the datasheet I had was for the suffix-less RTL8366. Seemingly, this chip has multiple incarnations, most of them varying slightly in featureset and register locations. Naturally, no datasheet of my version of the chip was to be found.
After some research, though, I was lucky enough to find a piece of code implementing a Linux-driver for a chip with the same register set. That, combined with the still somewhat valid data in the datasheet gave me enough info to at least implement a user interface for the vlan portion of the switch.