From: Marc Kleine-Budde <mkl@pengutronix.de>
To: balbi@ti.com
Cc: r58472@freescale.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, Peter Chen <peter.chen@freescale.com>,
kernel@pengutronix.de, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
Date: Mon, 14 Jan 2013 12:03:04 +0100 [thread overview]
Message-ID: <50F3E5E8.2000905@pengutronix.de> (raw)
In-Reply-To: <20130114105357.GH10874@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
On 01/14/2013 11:53 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 11:50:41AM +0100, Marc Kleine-Budde wrote:
>> On 01/14/2013 11:39 AM, Felipe Balbi wrote:
>>> On Mon, Jan 14, 2013 at 11:34:05AM +0100, Marc Kleine-Budde wrote:
>>>> On 01/14/2013 11:24 AM, Felipe Balbi wrote:
>>>>> On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wrote:
>>>>>> On 01/14/2013 11:16 AM, Felipe Balbi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:
>>>>>>>> @@ -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,
>>>>>>>> + }, {
>>>>>>>> + .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?
>>>>>
>>>>> 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.
>>>
>>> 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.
>
> 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¢
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-01-14 11:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 10:12 [PATCH v3 0/3] Fix the Build error for fsl_mxc_udc.c Peter Chen
2013-01-14 10:12 ` [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id Peter Chen
2013-01-14 10:16 ` Felipe Balbi
2013-01-14 10:18 ` Marc Kleine-Budde
2013-01-14 10:24 ` Felipe Balbi
2013-01-14 10:34 ` Marc Kleine-Budde
2013-01-14 10:39 ` Felipe Balbi
2013-01-14 10:50 ` Marc Kleine-Budde
2013-01-14 10:53 ` Felipe Balbi
2013-01-14 11:03 ` Marc Kleine-Budde [this message]
2013-01-14 11:06 ` Felipe Balbi
2013-01-14 12:56 ` Peter Chen
2013-01-14 17:40 ` Felipe Balbi
2013-01-14 17:54 ` Marc Kleine-Budde
2013-01-14 17:57 ` Felipe Balbi
2013-01-15 1:31 ` Peter Chen
2013-01-14 10:12 ` [PATCH v3 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap Peter Chen
2013-01-14 10:17 ` Felipe Balbi
2013-01-14 12:58 ` Peter Chen
2013-01-14 13:10 ` Russell King - ARM Linux
2013-01-14 13:16 ` Peter Chen
2013-01-14 10:12 ` [PATCH v3 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc Peter Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50F3E5E8.2000905@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=peter.chen@freescale.com \
--cc=r58472@freescale.com \
--cc=shawn.guo@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).