The message seems to be harmless and to be the result of the device going into a suspend. The only issue I see is that the device in question is my root device and it seems that sometimes it doesn't come out of suspend resulting in my RPi having to be power-cycled (very very rarely, after a few weeks.)
I see the message on an RPi B with a Samsung EVO 840 SSD connected via an ASMedia AS2105 SATA to USB adapter. The adapter is pretty common, indeed my StarTech SATA docking bay uses the identical adapter and runs without the reset message on a B+. On the B, however, the reset message comes out at a rate of up to once every 4 seconds; not fast enough to slow the speed noticeably in my case, but annoying noise in the kernel log. The adapter is USB 3/Super-speed capable and it does work at super-speed on a USB3 system (I time it at around 100MByte/second with a 3Gb/s SATA drive.) The AS2105 is nominally a 4 port hub, though in both of the cases only one port is active.
Both these systems are running 3.18.3, both have power to the drive independently of the RPi, both are overclocked etc, both have adequate power to the RPi.
The message comes from drivers/usb/core/hub.c, line 4312 in 3.18.3, the function is hub_port_init, apparently (from the comments) from usb_reset_and_verify_device. I see two places where this can be called:
finish_port_resume: this is what I think is happening.
usb_reset_device: I think this would mean that something had deliberately decided to reset the device, I would expect a separate kernel message since resetting a hub which holds the root device seems like a pretty weird thing to do.
Without the full call stack of course I can't tell where the reset originates, but it seems likely that the disk is being suspended automatically when the system falls idle. lpm_enable is being set to '0', however it seems to me that the SSD disk itself might just do a suspend on its own. As an experiment I tried dwc_otg.lpm_enable=1 (turn on Linux power management) however it errors out in the boot - it looks like the relevant DWC_OTG code isn't compiled in.
I couldn't see anything else that would control USB suspend.