2. In PC's that were used for in-system programming the EEPROM the default VID/PID (VID/PID of HX2LP without EEPROM) will be bound to CyUSB.sys. Connecting the HX2LP based hub to this particular PC it'll be bound to CyUSB.sys and has to be rebound to usbhub.sys to get it working properly. A novice user will face slight inconvenience in doing this. But the percentage of this will be very very less.

Systems in which the hub is connected to embedded host tend to go with no EEPROM since they won't run into this issue.

Can you elaborate more on the use case you mentioned of an embedded system not using a EEPROM?

We have embedded device with CY7C65630. We have a SPI flash attached (which is blank). From looking at the behavior of the device and reading the documentation of the Cypress HUB, it looks like the hub will not enumerate devices attached to it until the host writes PID etc. and resets the hub. Our hardware eng. modified one board to be able to connect our board to a PC and we wrote a configuration to SPI flash and reset the board and then the PC could "see" the attached devices on the hub.

Now to do the same thing with our embedded processor, it looks like we would need to write some code to program the SPI flash and reset the hub before it would enumerate attached devices on the hub.

I see some posts like this one that appear to say that it will work without EEPROM (meaning enumerate attached devices to the hub) but the documentation says that this mode is not valid for a production envionment.

So my question is ... can this device be used in an embedded environment without the micro having to configure the hub?

What I've seen as general practice in these scenario is program 1 EEPROM through Blaster utility, then take a copy of the image and mass program by flashing this image using EEPROM programmer (this will be a restriction only if you plan on using unique serial number for each).