Hi,
Patches are independent, please pick up as you wish.
However all of them are needed to solve the issue, so I am sending
everything together for easier testng.
Problem
=======
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.
Solution
========
Perform real hardware reset (including regulator off/on) when probing.
Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.
Best regards,
Krzysztof
Krzysztof Kozlowski (3):
usb: misc: usb3503: Fix HUB mode after bootloader initialization
ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
device detection
regulator: max77686: Configure enable time to properly handle
regulator enable
Documentation/devicetree/bindings/usb/usb3503.txt | 1 +
arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 +
drivers/regulator/max77686-regulator.c | 5 ++
drivers/usb/misc/usb3503.c | 81 +++++++++++++++++++++++
4 files changed, 89 insertions(+)
--
1.9.1
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB after after
successful probing was not visible in the system ("lsusb"). Connected
devices were not visible neither.
In such case the USB3503 has to be fully reset before configuring to HUB
mode. Reset by GPIO (called RESET_N pin) and by RESET field in STCD
register are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.
The USB3503 can work with different regulator configurations, however
toggling of only one is relevant in mentioned case: the VDD 3.3V.
The patch adds:
1. New binding for optional regulator (VDD33),
2. Code for toggling the regulator on/off before doing reset by GPIO,
3. Initial reset during probing before configuring HUB mode.
Patch is very loosely based on Tobias Jakobi's similar work for usb3503.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
Tested on Odroid U3 so far. Please kindly test on X2 or other
configurations and bootloaders.
---
Documentation/devicetree/bindings/usb/usb3503.txt | 1 +
drivers/usb/misc/usb3503.c | 81 +++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
index c1a0a9191d26..36516ade9467 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -24,6 +24,7 @@ Optional properties:
pins (optional, if not provided, driver will not set rate of the
REFCLK signal and assume that a value from the primary reference
clock frequencies table is used)
+- vdd33-supply: Optional supply for VDD 3.3 V power source.
Examples:
usb3503@08 {
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index b45cb77c0744..8905e8b2439d 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -28,6 +28,7 @@
#include <linux/platform_device.h>
#include <linux/platform_data/usb3503.h>
#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
#define USB3503_VIDL 0x00
#define USB3503_VIDM 0x01
@@ -59,6 +60,7 @@ struct usb3503 {
struct regmap *regmap;
struct device *dev;
struct clk *clk;
+ struct regulator *vdd_reg;
u8 port_off_mask;
int gpio_intn;
int gpio_reset;
@@ -66,8 +68,31 @@ struct usb3503 {
bool secondary_ref_clk;
};
+static int usb3503_regulator(struct usb3503 *hub, int state)
+{
+ int ret;
+
+ if (!hub->vdd_reg)
+ return 0;
+
+ if (state)
+ ret = regulator_enable(hub->vdd_reg);
+ else
+ ret = regulator_disable(hub->vdd_reg);
+
+ return ret;
+}
+
static int usb3503_reset(struct usb3503 *hub, int state)
{
+ int err;
+
+ err = usb3503_regulator(hub, state);
+ if (err) {
+ dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
+ (state ? "enable" : "disable"), err);
+ }
+
if (!state && gpio_is_valid(hub->gpio_connect))
gpio_set_value_cansleep(hub->gpio_connect, 0);
@@ -260,6 +285,15 @@ static int usb3503_probe(struct usb3503 *hub)
return -EPROBE_DEFER;
of_property_read_u32(np, "initial-mode", &mode);
hub->mode = mode;
+
+ hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
+ if (IS_ERR(hub->vdd_reg)) {
+ if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ hub->vdd_reg = NULL;
+ } else {
+ dev_dbg(dev, "Using VDD33 regulator for full reset\n");
+ }
}
if (hub->port_off_mask && !hub->regmap)
@@ -299,6 +333,21 @@ static int usb3503_probe(struct usb3503 *hub)
return err;
}
}
+ err = usb3503_regulator(hub, true);
+ if (err) {
+ dev_err(dev, "unable to enable VDD33 regulator (%d)\n", err);
+ return err;
+ }
+
+ /*
+ * Perform real full reset before configuring.
+ * On some boards (e.g. on Odroid U3 board with LAN9730/SMSC95xx)
+ * after enabling the USB by bootloader it has to be fully reset
+ * here to be visible.
+ */
+ usb3503_reset(hub, 0);
+ /* Settle down before powering on again */
+ usleep_range(4000, 10000);
usb3503_switch_mode(hub, hub->mode);
@@ -330,6 +379,21 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
return usb3503_probe(hub);
}
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+ struct usb3503 *hub;
+
+ hub = i2c_get_clientdata(i2c);
+ if (hub) {
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ usb3503_regulator(hub, false);
+ }
+
+ return 0;
+}
+
static int usb3503_platform_probe(struct platform_device *pdev)
{
struct usb3503 *hub;
@@ -342,6 +406,21 @@ static int usb3503_platform_probe(struct platform_device *pdev)
return usb3503_probe(hub);
}
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+ struct usb3503 *hub;
+
+ hub = platform_get_drvdata(pdev);
+ if (hub) {
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ usb3503_regulator(hub, false);
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int usb3503_i2c_suspend(struct device *dev)
{
@@ -395,6 +474,7 @@ static struct i2c_driver usb3503_i2c_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
+ .remove = usb3503_i2c_remove,
.id_table = usb3503_id,
};
@@ -404,6 +484,7 @@ static struct platform_driver usb3503_platform_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_platform_probe,
+ .remove = usb3503_platform_remove,
};
static int __init usb3503_init(void)
--
1.9.1
The enable time for buck regulators was not configured but actually is
essential: consumers, like usb3503, doing hard reset (regulator off/on)
should wait for the regulator to settle.
Configure the enable time according to datasheet.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/regulator/max77686-regulator.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/regulator/max77686-regulator.c b/drivers/regulator/max77686-regulator.c
index d1ab6a4da88f..ac4fa581e0a5 100644
--- a/drivers/regulator/max77686-regulator.c
+++ b/drivers/regulator/max77686-regulator.c
@@ -41,6 +41,8 @@
#define MAX77686_LDO_LOW_UVSTEP 25000
#define MAX77686_BUCK_MINUV 750000
#define MAX77686_BUCK_UVSTEP 50000
+#define MAX77686_BUCK_ENABLE_TIME 40 /* us */
+#define MAX77686_DVS_ENABLE_TIME 22 /* us */
#define MAX77686_RAMP_DELAY 100000 /* uV/us */
#define MAX77686_DVS_RAMP_DELAY 27500 /* uV/us */
#define MAX77686_DVS_MINUV 600000
@@ -422,6 +424,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_BUCK_MINUV, \
.uV_step = MAX77686_BUCK_UVSTEP, \
.ramp_delay = MAX77686_RAMP_DELAY, \
+ .enable_time = MAX77686_BUCK_ENABLE_TIME, \
.n_voltages = MAX77686_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK5OUT + (num - 5) * 2, \
.vsel_mask = MAX77686_VSEL_MASK, \
@@ -439,6 +442,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_BUCK_MINUV, \
.uV_step = MAX77686_BUCK_UVSTEP, \
.ramp_delay = MAX77686_RAMP_DELAY, \
+ .enable_time = MAX77686_BUCK_ENABLE_TIME, \
.n_voltages = MAX77686_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK1OUT, \
.vsel_mask = MAX77686_VSEL_MASK, \
@@ -456,6 +460,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_DVS_MINUV, \
.uV_step = MAX77686_DVS_UVSTEP, \
.ramp_delay = MAX77686_DVS_RAMP_DELAY, \
+ .enable_time = MAX77686_DVS_ENABLE_TIME, \
.n_voltages = MAX77686_DVS_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK2DVS1 + (num - 2) * 10, \
.vsel_mask = MAX77686_DVS_VSEL_MASK, \
--
1.9.1
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB after
successful probing was not visible in the system ("lsusb"). Connected
devices were not visible neither.
The USB3503 takes optional regulator so provide one - buck8 on Odroid
U3.
Additionally switch the control of buck8 to GPIO mode. It is faster than
I2C/register mode and it is the easiest way to disable it (regulator
state is a logical OR state of GPIO and register value).
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index d73aa6c58fe3..5308a955ede4 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -74,6 +74,7 @@
regulator-name = "BUCK8_P3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ maxim,ena-gpios = <&gpa1 1 GPIO_ACTIVE_HIGH>;
};
/* VDDQ for MSHC (eMMC card) */
@@ -98,6 +99,7 @@
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
refclk-frequency = <24000000>;
+ vdd33-supply = <&buck8_reg>;
};
&ehci {
--
1.9.1
On Fri, Apr 29, 2016 at 12:59:49PM +0200, Krzysztof Kozlowski wrote:
> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
> @@ -24,6 +24,7 @@ Optional properties:
> pins (optional, if not provided, driver will not set rate of the
> REFCLK signal and assume that a value from the primary reference
> clock frequencies table is used)
> +- vdd33-supply: Optional supply for VDD 3.3 V power source.
Supplies are only optional if they may be physically absent. In this
case it's possible that on device regulators may be used instead, a
pattern more like that used for arizona-ldo1 where we represent those
regulators might be better as it's more clearly describing the
situation. I'm just wondering if the supply lookup stuff there should
be factored out as this is not an uncommon pattern..
It should at least be clearly stated what's going on, ignoring failure
to get supplies is generally a bug and people will tend to blindly cut
and paste things (witness all the breakage in graphics drivers with
this).
> static int usb3503_reset(struct usb3503 *hub, int state)
> {
> + int err;
> +
> + err = usb3503_regulator(hub, state);
> + if (err) {
> + dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
> + (state ? "enable" : "disable"), err);
> + }
Are we sure that the callers all balance enables and disables and we
don't ever end up going through reset more than once on the way down?
> + hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
> + if (IS_ERR(hub->vdd_reg)) {
> + if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
This should explicitly check for -ENODEV and return the error if it gets
anything else, that will mean that if the supply is needed but lookup
fails somehow due to a non-deferral error we'll handle it properly.
> + err = usb3503_regulator(hub, true);
The naming on this function is very obscure (and there's also a couple
of other supplies). I'd suggest just folding this into the reset
function, or at least renaming so the reader can tell what these calls
do.
The patch
regulator: max77686: Configure enable time to properly handle regulator enable
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a9597305d97f6cf7c9e89dc1461e834c446d91fd Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <[email protected]>
Date: Fri, 29 Apr 2016 12:59:51 +0200
Subject: [PATCH] regulator: max77686: Configure enable time to properly handle
regulator enable
The enable time for buck regulators was not configured but actually is
essential: consumers, like usb3503, doing hard reset (regulator off/on)
should wait for the regulator to settle.
Configure the enable time according to datasheet.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
---
drivers/regulator/max77686-regulator.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/regulator/max77686-regulator.c b/drivers/regulator/max77686-regulator.c
index d1ab6a4da88f..ac4fa581e0a5 100644
--- a/drivers/regulator/max77686-regulator.c
+++ b/drivers/regulator/max77686-regulator.c
@@ -41,6 +41,8 @@
#define MAX77686_LDO_LOW_UVSTEP 25000
#define MAX77686_BUCK_MINUV 750000
#define MAX77686_BUCK_UVSTEP 50000
+#define MAX77686_BUCK_ENABLE_TIME 40 /* us */
+#define MAX77686_DVS_ENABLE_TIME 22 /* us */
#define MAX77686_RAMP_DELAY 100000 /* uV/us */
#define MAX77686_DVS_RAMP_DELAY 27500 /* uV/us */
#define MAX77686_DVS_MINUV 600000
@@ -422,6 +424,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_BUCK_MINUV, \
.uV_step = MAX77686_BUCK_UVSTEP, \
.ramp_delay = MAX77686_RAMP_DELAY, \
+ .enable_time = MAX77686_BUCK_ENABLE_TIME, \
.n_voltages = MAX77686_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK5OUT + (num - 5) * 2, \
.vsel_mask = MAX77686_VSEL_MASK, \
@@ -439,6 +442,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_BUCK_MINUV, \
.uV_step = MAX77686_BUCK_UVSTEP, \
.ramp_delay = MAX77686_RAMP_DELAY, \
+ .enable_time = MAX77686_BUCK_ENABLE_TIME, \
.n_voltages = MAX77686_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK1OUT, \
.vsel_mask = MAX77686_VSEL_MASK, \
@@ -456,6 +460,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.min_uV = MAX77686_DVS_MINUV, \
.uV_step = MAX77686_DVS_UVSTEP, \
.ramp_delay = MAX77686_DVS_RAMP_DELAY, \
+ .enable_time = MAX77686_DVS_ENABLE_TIME, \
.n_voltages = MAX77686_DVS_VSEL_MASK + 1, \
.vsel_reg = MAX77686_REG_BUCK2DVS1 + (num - 2) * 10, \
.vsel_mask = MAX77686_DVS_VSEL_MASK, \
--
2.8.0.rc3
On 04/29/2016 01:30 PM, Mark Brown wrote:
> On Fri, Apr 29, 2016 at 12:59:49PM +0200, Krzysztof Kozlowski wrote:
>
>> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
>> @@ -24,6 +24,7 @@ Optional properties:
>> pins (optional, if not provided, driver will not set rate of the
>> REFCLK signal and assume that a value from the primary reference
>> clock frequencies table is used)
>> +- vdd33-supply: Optional supply for VDD 3.3 V power source.
>
> Supplies are only optional if they may be physically absent. In this
> case it's possible that on device regulators may be used instead, a
> pattern more like that used for arizona-ldo1 where we represent those
> regulators might be better as it's more clearly describing the
> situation. I'm just wondering if the supply lookup stuff there should
> be factored out as this is not an uncommon pattern..
>
> It should at least be clearly stated what's going on, ignoring failure
> to get supplies is generally a bug and people will tend to blindly cut
> and paste things (witness all the breakage in graphics drivers with
> this).
The device has four power input lines (called VBAT, VDD33, VDD_CORE and
VDD_12). Datasheet describes 4 valid configurations... but impression of
the Odroid U3 board schematics is that they used another (custom?)
configuration.
I did not add rest of regulators on purpose:
1. I don't have other configurations to test.
2. It is rather old device, so I don't expect active development.
The VDD33 is really optional. The device can work in different
configuration, e.g. only on VBAT. How the reset logic would work then? I
don't know... I would suspect that it could be exactly the same (just
replace VDD33 with VBAT) but I am not sure.
>> static int usb3503_reset(struct usb3503 *hub, int state)
>> {
>> + int err;
>> +
>> + err = usb3503_regulator(hub, state);
>> + if (err) {
>> + dev_err(hub->dev, "unable to %s VDD33 regulator to (%d)\n",
>> + (state ? "enable" : "disable"), err);
>> + }
>
> Are we sure that the callers all balance enables and disables and we
> don't ever end up going through reset more than once on the way down?
I double checked the code and there might be in-balance if DT or
platform data sets initial mode to suspend. Otherwise it should be balanced.
I'll re-think the patch and fix this.
>
>> + hub->vdd_reg = devm_regulator_get_optional(dev, "vdd33");
>> + if (IS_ERR(hub->vdd_reg)) {
>> + if (PTR_ERR(hub->vdd_reg) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>
> This should explicitly check for -ENODEV and return the error if it gets
> anything else, that will mean that if the supply is needed but lookup
> fails somehow due to a non-deferral error we'll handle it properly.
I must admit I wasn't sure about handling the ENODEV and some other
examples (drivers) were handling this just like that.
Thanks for pointing this out.
>
>> + err = usb3503_regulator(hub, true);
>
> The naming on this function is very obscure (and there's also a couple
> of other supplies). I'd suggest just folding this into the reset
> function, or at least renaming so the reader can tell what these calls
> do.
Okay.
Thanks for feedback!
Best regards,
Krzysztof
On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
> On 04/29/2016 01:30 PM, Mark Brown wrote:
> > Supplies are only optional if they may be physically absent. In this
> > case it's possible that on device regulators may be used instead, a
> > pattern more like that used for arizona-ldo1 where we represent those
> > regulators might be better as it's more clearly describing the
> > situation. I'm just wondering if the supply lookup stuff there should
> > be factored out as this is not an uncommon pattern..
> > It should at least be clearly stated what's going on, ignoring failure
> > to get supplies is generally a bug and people will tend to blindly cut
> > and paste things (witness all the breakage in graphics drivers with
> > this).
> The VDD33 is really optional. The device can work in different
> configuration, e.g. only on VBAT. How the reset logic would work then? I
> don't know... I would suspect that it could be exactly the same (just
> replace VDD33 with VBAT) but I am not sure.
What the Arizona example I mentioned does is look for the property
specifying an external supply in DT and if there isn't one assumes that
it must be using the internal regulator. That's a bit icky but it does
the right thing and is much simpler from a user point of view.
Hi Krzysztof,
On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> Hi,
>
> Patches are independent, please pick up as you wish.
>
> However all of them are needed to solve the issue, so I am sending
> everything together for easier testng.
>
>
> Problem
> =======
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> by suspend to RAM. The actual TFTP boot does not have to happen. Just
> "usb start" from U-Boot is sufficient.
>
>
> Solution
> ========
> Perform real hardware reset (including regulator off/on) when probing.
>
>
> Tested on Odroid U3 so far. Please kindly test on X2 and other
> configurations and bootloaders.
Against which kernel git repo is this patch?
I did apply this patch series first:
http://www.spinics.net/lists/arm-kernel/msg500764.html
followed by this patch series.
I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:
...
[drm] Exynos DRM: using 12c10000.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0: frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 13930000.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 12480000.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 12580000.ehci: EHCI Host Controller
exynos-ehci 12580000.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 12580000.ehci: irq 51, io mem 0x12580000
exynos-ehci 12580000.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 12580000.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 12480000.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-12580000.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected
No oops, no nothing. It's just sitting there.
Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6? I've been running
4.5.0-rc3 before this, but I can't apply these patches there because there
is no drivers/regulator/max77686-regulator.c in 4.5.
Regards,
Hans
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (3):
> usb: misc: usb3503: Fix HUB mode after bootloader initialization
> ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
> device detection
> regulator: max77686: Configure enable time to properly handle
> regulator enable
>
> Documentation/devicetree/bindings/usb/usb3503.txt | 1 +
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 2 +
> drivers/regulator/max77686-regulator.c | 5 ++
> drivers/usb/misc/usb3503.c | 81 +++++++++++++++++++++++
> 4 files changed, 89 insertions(+)
>