Is the I2C controller properly defined in your DTS?
"Loading" the driver makes it available to the kernel, if it finds a matching "piece of hardware". No matching hardware, no /dev/i2c (Unlike PCs, you need to "tell" the kernel of an embedded device about most every bit of hardware)
there is a propper area for the i2c. I checked with the datasheet of the MT7628.
That looks ok. The adresses match. So i think the driver should be ok.
I'm wondering if you can now see your i2c devices with i2cdetect 0
I've tried to do something similar very recently and gave up, now back to GPIO driver.
It is common practice for the chip-level DTSI to define the range of (known, usable) capabilities of the chip and then have the DTS enable what is actually usable for that board. Especially for things like I2C, the connections to the SoC pins may not be available.
make menuconfigselects things, but doesn't change them. The DTS and what it includes are defined on a board-by-board basis, and set the limits of what might be meaningful to add to the firmware. As there are around a thousand boards supported, it would be a maintenance nightmare to have the config process reflect all the hardware variants in dependencies, not to mention making the dependency display completely unreadable.
Assuming that you can get I2C slaves recognized and the I2C connection is "easy", submitting a patch setting the I2C node to "okay" for your specific board would be the next step.
Thank you, Jona, for inspiration. I've got my slaves working with the current snapshot and non-patched driver. I had wiring (pin numbering) issue as well.
Edit:
I'm now back to i2c via GPIO as it works for me better than native i2c (ds3231 rtc, bme280 sensor)