Probably I know the reason of this - I have taken chuwi vi8 with
gsl1680, after modprobe i2c-dev, i2cdetect -r 3  - detects gsl1680 on
0x40 PERMANENTLY! In Android touch is on i2c-4, but on the same
address.

The differing bus assignment by be caused by slightly different loading order
or DeviceTree or platform driver configurations.

AFAIK - i2c devices could switch bus number but not their port on bus,
this means that if you have chipone icn85xx it should answer on 0x48
on one of the i2c bus.
Am I right?

Yes, the device address is normally hardcoded into the device itself.
So, unless there is an internal register or a chip pin to change, it will
always be the same.
And since I2C addressing is standardised, the physical and logical addresses
are identical.

As mentioned above, the logical I2C bus number may change depending on certain
factors. The physical bus pins are still the same though.

In case of Chuwi Vi10 with Chipone icn8528 situation with i2cdetect is
very very strange.
On kernels 4.4.2 and 4.0.1 - modprobe i2c-dev and then i2cdetect -r X
(1,2,3,4) does NOT!!!!!!!! Detect NOTHING permanently on 0x48 on any
bus!
This make me confused completely! To wake up something it should be
visible on i2c bus but it is NOT!

It's possible that the device simply doesn't answer until the wakeup pin has
turned it on. In the case of the Silead chips, I think they are already turned
on at system boot and stay on until they are shut down via PM commands.

So you definitely need to configure the GPIO pin, send the wakeup sequence,
and then you should be able to communicate with the chip.