The ifdef'ed Linux kernel code uses the 1 based port number, whereas U-Boot
puts a 0 based port number into the register. The reason the 0 based port
number apparently works can probably be taken from the USB 2.0 spec:

8.4.2.2 Start-Split Transaction Token
... The host must correctly set the port field for single and multiple TT
hub implementations. A single TT hub implementation *may ignore* the port
field.

Actually, as far as I understand, a multi TT hub defaults to single TT
(bAlternateSetting: 0) until switched via SetInterface, so even "port 42"
would work.

The change was verified by hardcoding the port number to a wrong value,
SPLIT transactions kept working (although using a DWC2 instead of MUSB).
Tested hubs are the RPi onboard SMC9514 and an external "05e3:0608
Genesys Logic, Inc. USB-2.0 4-Port HUB". The former is a multi TT hub,
the latter single TT only.

Addendum: Tested on sunxi/MUSB by Hans de Goede

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>

Start split and complete split tokens need the hub address and the
downstream port of the first HS hub (device view).

The core of the function was duplicated in both host/ehci_hcd and
musb-new/usb-compat.h.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>

flush_dcache_range may access data after priv->aligned_buffer end if
len > DWC2_DATA_BUF_SIZE.
memcpy may access data after buffer end if done > 0

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>

This driver is meant to be used with any OHCI-compatible host
controller in case if there's no need for platform-specific
glue such as setup of controller or PHY's power mode via
GPIOs etc.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>

With the old order of initialization the hcor pointer has been setup to
the same address as Exynos EHCI base address (0x12110000 instead of
0x12110010).
Such behaviour was caused by reading value of 0 instead of 0x10 from EHCI
HCCPBASE register without doing proper clock initialization before.

To fix this problem hcor initialization has been moved after USB PHY setup.
Now ehci_readl(&ctx->hcd->cr_capbase) returns correct value.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>

The driver is actually for the Designware DWC2 controller.
This patch renames the global s3c_udc.h header to dwc2_udc.h.

The rename is done automatically:
	$ sed -i "s/s3c_udc\.h/dwc2_udc.h/g" \
		`git grep "s3c_udc\.h" | cut -d : -f 1`

Signed-off-by: Marek Vasut <marex@denx.de>

The driver is actually for the Designware DWC2 controller.
This patch is the second and final to rename global symbol,
the s3c_udc_probe() function.

The rename is done automatically:
	$ sed -i "s/s3c_udc_probe/dwc2_udc_probe/g" \
		`git grep s3c_udc_probe | cut -d : -f 1`

Signed-off-by: Marek Vasut <marex@denx.de>

The driver is actually for the Designware DWC2 controller.
This patch is the first to rename global symbol, the struct
s3c_plat_otg_data.

The rename is done automatically:
	$ sed -i "s/s3c_plat_otg_data/dwc2_plat_otg_data/g" \
		`git grep s3c_plat_otg_data | cut -d : -f 1`

Signed-off-by: Marek Vasut <marex@denx.de>

The s3c-otg IP block is in fact a DWC2 OTG one, so finally rename the
config option to make it less misleading. No functional change, just
a mechanical change done using the following script:

  git grep USB_GADGET_S3C_UDC_OTG | cut -d : -f 1 | sort -u | \
  while read line ; do
    sed -i "s/USB_GADGET_S3C_UDC_OTG/USB_GADGET_DWC2_OTG/g" $line ;
  done

Signed-off-by: Marek Vasut <marex@denx.de>

The driver is actually for the Designware DWC2 controller.
Tweak the comments in the driver to reflect this fact.

Signed-off-by: Marek Vasut <marex@denx.de>