The major mistake in your schematics is that the nRESET signal (pin 24) doesn't follow the delay specifications. The deassertion of this signal must be delayed until all supply voltages reach valid level:
In your schematics the nRESET is tied directly to power rail, which obviously violates specifications. If the LAN7500 IC can't receive "valid reset", it will be internally screwed and won 't work.
To handle this signal properly it is highly recommended to use a "voltage supervisor" IC like MAX809. This method will provide guaranteed reset under various power-on and brown-out conditions. In most simplistic/cheap case you can use a RC-delay on this pin, but this will be a gamble in unstable power-on situations.
ADDITION: Another typical problem with embedded hubs and embedded devices is the sequencing of VBUS_DET on LAN9500 side. To connect to hub, the LAN9500 must pull up D+ high when it sees VBUS_DET, and not before that. You should obtain scope traces of what is going on D+/D- wires between the hub and LAN. Theoretically the connect event should NOT occur before the hub is ready to operate (be enumerated and such). If the connect event (D+ pull HIGH) occurs before that, the hub status reporting might be screwed. To test if this is the problem, toggle momentarily the VBUS_DET to ground and see if the hub/host would start to recognize the connect event and starts doing something (USB_RESET etc. etc).
To make the connection correctly and get proper sequencing reardless of power ramp rates, it is advisable to connect the VBUS_DET to the power control pin on hub side, PWRON1, with proper polarity. The PWRON1 pin will be logically inactive until the hub is fully enumerated and operational, which will ensure that LAN9500 will start the connect process after all is ready.
