[U-Boot] [PATCH] musb: sunxi: Use base address from device tree
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org --- drivers/usb/musb-new/sunxi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index 7ee44ea91900..ae6a54118cd1 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
#ifdef CONFIG_USB_MUSB_HOST host->host = musb_init_controller(&musb_plat, NULL, - (void *)SUNXI_USB0_BASE); + dev_read_addr_ptr(dev)); if (!host->host) return -EIO;
@@ -326,7 +326,7 @@ static int musb_usb_probe(struct udevice *dev) if (!ret) printf("Allwinner mUSB OTG (Host)\n"); #else - ret = musb_register(&musb_plat, NULL, (void *)SUNXI_USB0_BASE); + ret = musb_register(&musb_plat, NULL, dev_read_addr_ptr(dev)); if (!ret) printf("Allwinner mUSB OTG (Peripheral)\n"); #endif
On Tue, Dec 12, 2017 at 03:24:21PM +0800, Chen-Yu Tsai wrote:
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org
Acked-by: Maxime Ripard maxime.ripard@free-electrons.com
We should probably do the same for the phy.
Maxime
On 12/12/2017 08:24 AM, Chen-Yu Tsai wrote:
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/usb/musb-new/sunxi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index 7ee44ea91900..ae6a54118cd1 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
#ifdef CONFIG_USB_MUSB_HOST host->host = musb_init_controller(&musb_plat, NULL,
(void *)SUNXI_USB0_BASE);
dev_read_addr_ptr(dev));
What happens if dev_read_addr_ptr() returns some non-standard value?
if (!host->host) return -EIO;
@@ -326,7 +326,7 @@ static int musb_usb_probe(struct udevice *dev) if (!ret) printf("Allwinner mUSB OTG (Host)\n"); #else
- ret = musb_register(&musb_plat, NULL, (void *)SUNXI_USB0_BASE);
- ret = musb_register(&musb_plat, NULL, dev_read_addr_ptr(dev)); if (!ret) printf("Allwinner mUSB OTG (Peripheral)\n");
#endif
On Tue, Dec 12, 2017 at 11:56 PM, Marek Vasut marex@denx.de wrote:
On 12/12/2017 08:24 AM, Chen-Yu Tsai wrote:
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/usb/musb-new/sunxi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index 7ee44ea91900..ae6a54118cd1 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
#ifdef CONFIG_USB_MUSB_HOST host->host = musb_init_controller(&musb_plat, NULL,
(void *)SUNXI_USB0_BASE);
dev_read_addr_ptr(dev));What happens if dev_read_addr_ptr() returns some non-standard value?
You mean like an error value? That would likely be a signal that the device tree is broken, like a missing property or invalid value, or a corrupt device tree. In all cases I think blowing up should be an expected result for a device tree driven driver?
ChenYu
if (!host->host) return -EIO;@@ -326,7 +326,7 @@ static int musb_usb_probe(struct udevice *dev) if (!ret) printf("Allwinner mUSB OTG (Host)\n"); #else
ret = musb_register(&musb_plat, NULL, (void *)SUNXI_USB0_BASE);
ret = musb_register(&musb_plat, NULL, dev_read_addr_ptr(dev)); if (!ret) printf("Allwinner mUSB OTG (Peripheral)\n");#endif
-- Best regards, Marek Vasut
On 12/19/2017 05:04 PM, Chen-Yu Tsai wrote:
On Tue, Dec 12, 2017 at 11:56 PM, Marek Vasut marex@denx.de wrote:
On 12/12/2017 08:24 AM, Chen-Yu Tsai wrote:
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/usb/musb-new/sunxi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index 7ee44ea91900..ae6a54118cd1 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -318,7 +318,7 @@ static int musb_usb_probe(struct udevice *dev)
#ifdef CONFIG_USB_MUSB_HOST host->host = musb_init_controller(&musb_plat, NULL,
(void *)SUNXI_USB0_BASE);
dev_read_addr_ptr(dev));What happens if dev_read_addr_ptr() returns some non-standard value?
You mean like an error value? That would likely be a signal that the device tree is broken, like a missing property or invalid value, or a corrupt device tree. In all cases I think blowing up should be an expected result for a device tree driven driver?
What about handling the errors instead ? :)
On 12 December 2017 at 00:24, Chen-Yu Tsai wens@csie.org wrote:
Now that the musb sunxi glue driver is completely device model / device tree driven, we should use the base address from the device tree, instead of hard-coding it in the source code.
Fixes: 3a61b080acee ("musb: sunxi: switch to the device model") Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/usb/musb-new/sunxi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
participants (4)
-
Chen-Yu Tsai -
Marek Vasut -
Maxime Ripard -
Simon Glass