Fix the Build error for fsl_mxc_udc.c

drivers/usb/gadget/fsl_udc_core.c +8 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {

Hi,

Quoted 22 lines · Peter Chen

drivers/usb/gadget/fsl_udc_core.c +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

drivers/usb/gadget/fsl_udc_core.c static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

drivers/usb/gadget/fsl_udc_core.c +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

drivers/usb/gadget/fsl_udc_core.c +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

drivers/usb/gadget/fsl_udc_core.c static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

drivers/usb/gadget/fsl_udc_core.c +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Why use a string compare, if the kernel infrastructure already does this for you?

Quoted 35 lines · Marc Kleine-Budde

Quoted 33 lines · Felipe Balbi

Hi,

Quoted 17 lines · Peter Chen

drivers/usb/gadget/fsl_udc_core.c +8 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {

drivers/usb/gadget/fsl_udc_core.c static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 10 lines

drivers/usb/gadget/fsl_udc_core.c +10 -0

+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,
+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 39 lines · Felipe Balbi

Quoted 37 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

drivers/usb/gadget/fsl_udc_core.c +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

drivers/usb/gadget/fsl_udc_core.c static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

drivers/usb/gadget/fsl_udc_core.c +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Why use a string compare, if the kernel infrastructure already does this for you?

Quoted 1 line

what do you mean ? What kernel infrastructure is doing waht for me ?

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

Quoted 42 lines · Marc Kleine-Budde

Quoted 40 lines · Felipe Balbi

Quoted 35 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

drivers/usb/gadget/fsl_udc_core.c +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

drivers/usb/gadget/fsl_udc_core.c static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

drivers/usb/gadget/fsl_udc_core.c +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 4 lines

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

but current driver data is just duplicating name with an integer, it's pretty useless driver data.

Quoted 43 lines · Felipe Balbi

Quoted 42 lines · Marc Kleine-Budde

Quoted 40 lines · Felipe Balbi

Quoted 35 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

(quoted diff) +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

Review static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

(quoted diff) +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 7 lines

Quoted 4 lines

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

but current driver data is just duplicating name with an integer, it's pretty useless driver data.

I don't think so - another argument:
Less code. As struct platform_device_id is a static array the space is allocated anyway. So it doesn't make any difference if driver_data is NULL or not. Later you just need to make an integer comparison instead of a call to a strcmp(), if you have a switch/case and IMX*_UDC is an enum, the compiler will warn you if you've missed an IMX variant.

Hi,

Quoted 52 lines · Marc Kleine-Budde

Quoted 43 lines · Felipe Balbi

Quoted 42 lines · Marc Kleine-Budde

Quoted 40 lines · Felipe Balbi

Quoted 35 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

(quoted diff) +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

Review static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

(quoted diff) +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 7 lines

Quoted 4 lines

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

but current driver data is just duplicating name with an integer, it's pretty useless driver data.

Quoted 6 lines

I don't think so - another argument:
Less code. As struct platform_device_id is a static array the space is allocated anyway. So it doesn't make any difference if driver_data is NULL or not. Later you just need to make an integer comparison instead of a call to a strcmp(), if you have a switch/case and IMX*_UDC is an enum, the compiler will warn you if you've missed an IMX variant.

fair enough, but then don't create a different enum value for each imx instance if they're mostly the same. Differentiate only what's actually different.

Quoted 62 lines · Felipe Balbi

Hi,

Quoted 52 lines · Marc Kleine-Budde

Quoted 43 lines · Felipe Balbi

Quoted 42 lines · Marc Kleine-Budde

Quoted 40 lines · Felipe Balbi

Quoted 35 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

(quoted diff) +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

Review static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

(quoted diff) +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 7 lines

Quoted 4 lines

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

but current driver data is just duplicating name with an integer, it's pretty useless driver data.

Quoted 6 lines

I don't think so - another argument:
Less code. As struct platform_device_id is a static array the space is allocated anyway. So it doesn't make any difference if driver_data is NULL or not. Later you just need to make an integer comparison instead of a call to a strcmp(), if you have a switch/case and IMX*_UDC is an enum, the compiler will warn you if you've missed an IMX variant.

Quoted 3 lines

fair enough, but then don't create a different enum value for each imx instance if they're mostly the same. Differentiate only what's actually different.

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

just my 2?

Quoted 73 lines · Marc Kleine-Budde

Quoted 62 lines · Felipe Balbi

Hi,

Quoted 52 lines · Marc Kleine-Budde

Quoted 43 lines · Felipe Balbi

Quoted 42 lines · Marc Kleine-Budde

Quoted 40 lines · Felipe Balbi

Quoted 35 lines · Marc Kleine-Budde

Quoted 25 lines · Felipe Balbi

Hi,

Quoted 22 lines · Peter Chen

(quoted diff) +13 -2

@@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)
 
 	return fsl_udc_resume(NULL);
 }
-
 /*-------------------------------------------------------------------------
 	Register entry point for the peripheral controller driver
 --------------------------------------------------------------------------*/
-
+static const struct platform_device_id fsl_udc_devtype[] = {
+	{
+		.name = "imx-udc-mx25",
+		.driver_data = IMX25_UDC,
+	}, {
+		.name = "imx-udc-mx27",
+		.driver_data = IMX27_UDC,
+	}, {
+		.name = "imx-udc-mx31",
+		.driver_data = IMX31_UDC,
+	}, {
+		.name = "imx-udc-mx35",
+		.driver_data = IMX35_UDC,

Quoted 8 lines

Review static int fsl_udc_otg_resume(struct device *dev) · line 2776

Quoted 5 lines

(quoted diff) +5 -0

+	}, {
+		.name = "imx-udc-mx51",
+		.driver_data = IMX51_UDC,
+	}
+};

I wonder if your driver-data is actually needed since you can use string comparisson to achieve the exact same outcome.

Quoted 2 lines

Why use a string compare, if the kernel infrastructure already does this for you?

what do you mean ? What kernel infrastructure is doing waht for me ?

Quoted 7 lines

Quoted 4 lines

The kernel infrastructure is doing the string compare for you to match the device against the driver (via platform_device_id->name). You get the a pointer to the driver_data for free. So you don't need any string compare in the driver later.

but current driver data is just duplicating name with an integer, it's pretty useless driver data.

Quoted 6 lines

I don't think so - another argument:
Less code. As struct platform_device_id is a static array the space is allocated anyway. So it doesn't make any difference if driver_data is NULL or not. Later you just need to make an integer comparison instead of a call to a strcmp(), if you have a switch/case and IMX*_UDC is an enum, the compiler will warn you if you've missed an IMX variant.

Quoted 3 lines

fair enough, but then don't create a different enum value for each imx instance if they're mostly the same. Differentiate only what's actually different.

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

Quoted 1 line

just my 2?

$SUBJECT is trying to differentiate a single feature (or maybe two) to replace cpu_is_xxx(), then expose that on driver_data without creating one enum value for each release from fsl.

Signature · 2 lines

-- 
balbi

Quoted 8 lines

Quoted 7 lines

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

just my 2?

Quoted 3 lines

$SUBJECT is trying to differentiate a single feature (or maybe two) to replace cpu_is_xxx(), then expose that on driver_data without creating one enum value for each release from fsl.

Felipe, every one or two SoCs may have their special operations for integrate PHY interface, clk operation, or workaround for IC limitation.

Maybe, it will add more future or SoCs (maybe not for this driver) in the future, using enum is easier than string comparison for expanding something.

Hi,

On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:

<snip>

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

just my 2?

$SUBJECT is trying to differentiate a single feature (or maybe two) to replace cpu_is_xxx(), then expose that on driver_data without creating one enum value for each release from fsl.

Quoted 3 lines

Felipe, every one or two SoCs may have their special operations for integrate PHY interface, clk operation, or workaround for IC limitation.

the particular PHY and clk used should be hidden by phy layer and clk API respectively. Workarounds, fair enough, we need to handle them; but ideally those should be based on runtime revision detection, not some hackery using driver_data.

Quoted 3 lines

Maybe, it will add more future or SoCs (maybe not for this driver) in the future, using enum is easier than string comparison for expanding something.

a) I never told you to *not* use enum. I said that creating DEVICE_A, DEVICE_B, DEVICE_C, DEVICE_D and DEVICE_E values when DEVICE_B, DEVICE_C and DEVICE_E behave exactly the same is unnecessary.

b) you can't be expecting to add future SoCs support to fsl udc, I have already said and will repeat for the last time: move to chipidea ASAP.

New SoCs cannot be added to fsl udc, you *must* use chipidea for anything new and move the legacy to chipidea eventually. I will wait for a full year for you to do that, but after that I will have to start deleting drivers for the sake of avoid duplication of effort.

Quoted 22 lines · Felipe Balbi

Hi,

On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:

<snip>

Quoted 15 lines

Quoted 11 lines

Quoted 7 lines

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

just my 2?

$SUBJECT is trying to differentiate a single feature (or maybe two) to replace cpu_is_xxx(), then expose that on driver_data without creating one enum value for each release from fsl.

Felipe, every one or two SoCs may have their special operations for integrate PHY interface, clk operation, or workaround for IC limitation.

Quoted 4 lines

the particular PHY and clk used should be hidden by phy layer and clk API respectively. Workarounds, fair enough, we need to handle them; but ideally those should be based on runtime revision detection, not some hackery using driver_data.

If this is actually possible, I'd love to do this. But IP vendor don't include a version register in their cores. :(

Quoted 28 lines · Marc Kleine-Budde

Quoted 26 lines · Felipe Balbi

Hi,

On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:

<snip>

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Usually there isn't any Changelog between IP cores used in the different fsl processors (at least available outside of fsl), that makes it quite difficult to say if something found on one imx is really the same as on the other one. And they (usually) don't provide any versioning information in a register or the documentation.

just my 2?

Quoted 7 lines

Quoted 3 lines

$SUBJECT is trying to differentiate a single feature (or maybe two) to replace cpu_is_xxx(), then expose that on driver_data without creating one enum value for each release from fsl.

Felipe, every one or two SoCs may have their special operations for integrate PHY interface, clk operation, or workaround for IC limitation.

the particular PHY and clk used should be hidden by phy layer and clk API respectively. Workarounds, fair enough, we need to handle them; but ideally those should be based on runtime revision detection, not some hackery using driver_data.

Quoted 2 lines

If this is actually possible, I'd love to do this. But IP vendor don't include a version register in their cores. :(

then fair enough, driver_data or platform_data is the way to go, still my point (a) below is valid.

Signature · 2 lines

-- 
balbi

As mach/hardware.h is deleted, we can't visit platform code at driver. It has no phy driver to combine with this controller, so it has to use ioremap to map phy address as a workaround.

Signed-off-by Peter Chen <[email protected]>

---
 drivers/usb/gadget/fsl_mxc_udc.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

drivers/usb/gadget/fsl_mxc_udc.c +2 -1

index 6df45f7..0e858e6 100644
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
 
 /* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET	0x608
+#define MX35_USBPHYCTRL_OFFSET		0x600
+#define USBPHYCTRL_OTGBASE_OFFSET	0x8
 #define USBPHYCTRL_EVDO			(1 << 23)
 
 int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev)

Quoted 22 lines · Peter Chen

As mach/hardware.h is deleted, we can't visit platform code at driver. It has no phy driver to combine with this controller, so it has to use ioremap to map phy address as a workaround.

Signed-off-by Peter Chen <[email protected]>

---
 drivers/usb/gadget/fsl_mxc_udc.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

drivers/usb/gadget/fsl_mxc_udc.c +2 -1

index 6df45f7..0e858e6 100644
@@ -23,7 +23,8 @@ static struct clk *mxc_per_clk;
 static struct clk *mxc_ipg_clk;
 
 /* workaround ENGcm09152 for i.MX35 */
-#define USBPHYCTRL_OTGBASE_OFFSET	0x608
+#define MX35_USBPHYCTRL_OFFSET		0x600
+#define USBPHYCTRL_OTGBASE_OFFSET	0x8
 #define USBPHYCTRL_EVDO			(1 << 23)
 

drivers/usb/gadget/fsl_mxc_udc.c void fsl_udc_clk_finalize(enum fsl_udc_type devtype, · line 88

Quoted 7 lines

drivers/usb/gadget/fsl_mxc_udc.c +2 -0

 int fsl_udc_clk_init(enum fsl_udc_type devtype, struct platform_device *pdev)

@@ -83,15 +84,16 @@ void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	if (devtype == IMX35_UDC) {
 		unsigned int v;
+		void __iomem *phy_regs = ioremap((unsigned long)pdata->regs +
+						MX35_USBPHYCTRL_OFFSET, 512);

as I said before, this should be passed via struct resource, not pdata.

Signature · 2 lines

-- 
balbi

drivers/usb/gadget/fsl_mxc_udc.c void fsl_udc_clk_finalize(enum fsl_udc_type devtype, · line 88

Quoted 6 lines · Peter Chen

drivers/usb/gadget/fsl_mxc_udc.c +2 -0

@@ -83,15 +84,16 @@ void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	if (devtype == IMX35_UDC) {
 		unsigned int v;
+		void __iomem *phy_regs = ioremap((unsigned long)pdata->regs +
+						MX35_USBPHYCTRL_OFFSET, 512);

Consider that ioremap() can fail.