On 03/20/13 16:40, Fabio Estevam wrote:
> Hi Igor,
>
> On Wed, Mar 20, 2013 at 11:14 AM, Igor Grinberg <grinberg@xxxxxxxxxxxxxx> wrote:
>> On 03/20/13 15:35, Fabio Estevam wrote:
>>> From: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx>
>>>
>>> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled, results
>>> in the following error:
>>>
>>> arch/arm/mach-imx/built-in.o: In function 'pca100_init':
>>> platform-mx2-emma.c:(.init.text+0x6788): undefined reference to 'otg_ulpi_create'
>>> platform-mx2-emma.c:(.init.text+0x682c): undefined reference to 'mxc_ulpi_access_ops'
>>
>> Is this patch fixes both undefined references?
>
> Yes, it fixes both.
>
>> It does not look so..
>> If it fixes only the first one, I would suggest adjusting the commit message.
>
> Currently 'mxc_ulpi_access_ops' is defined in
> arch/arm/mach-imx/ulpi.c, so if CONFIG_USB_ULPI is unselected the
> unreference to 'mxc_ulpi_access_ops' will happen as reported in the
> commit log.
>
> If it makes sense I can move 'mxc_ulpi_access_ops' into
> arch/arm/mach-imx/ulpi.h or even try to get rid of it and use the
> generic otg_ulpi_create instead.
>
> Either way, this should be handled by a different patch.
>
>>> +#if IS_ENABLED(CONFIG_USB_ULPI)
>>> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>>> unsigned int flags);
>>> +#else
>>> +static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>>> + unsigned int flags)
>>> +{
>>> + return NULL;
>>
>> Would ERR_PTR(-ENXIO) do better here?
>
> The real *otg_ulpi_create function returns NULL on errors. Better to
> keep the real and no-op version with the same return type, right?
I see...
So that is the real function that should have the error handling improved...
BTW, you don't change the type while using the ERR_PTR(-ENXIO), but
return an error which has a meaning.
Anyway, fare enough.
Acked-by: Igor Grinberg <grinberg@xxxxxxxxxxxxxx>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
