diff for duplicates of <20130114125632.GA30157@nchen-desktop> diff --git a/a/1.txt b/N1/1.txt index 1f8c9b4..9165d9e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,101 +2,79 @@ On Mon, Jan 14, 2013 at 01:06:00PM +0200, Felipe Balbi wrote: > On Mon, Jan 14, 2013 at 12:03:04PM +0100, Marc Kleine-Budde wrote: > > On 01/14/2013 11:53 AM, Felipe Balbi wrote: > > > Hi, -> > >=20 +> > > > > > 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 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 wro= -te: +> > >>>>> 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) -> > >>>>>>>> =20 +> > >>>>>>>> @@ -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[] =3D= - { +> > >>>>>>>> +static const struct platform_device_id fsl_udc_devtype[] = { > > >>>>>>>> + { -> > >>>>>>>> + .name =3D "imx-udc-mx25", -> > >>>>>>>> + .driver_data =3D IMX25_UDC, +> > >>>>>>>> + .name = "imx-udc-mx25", +> > >>>>>>>> + .driver_data = IMX25_UDC, > > >>>>>>>> + }, { -> > >>>>>>>> + .name =3D "imx-udc-mx27", -> > >>>>>>>> + .driver_data =3D IMX27_UDC, +> > >>>>>>>> + .name = "imx-udc-mx27", +> > >>>>>>>> + .driver_data = IMX27_UDC, > > >>>>>>>> + }, { -> > >>>>>>>> + .name =3D "imx-udc-mx31", -> > >>>>>>>> + .driver_data =3D IMX31_UDC, +> > >>>>>>>> + .name = "imx-udc-mx31", +> > >>>>>>>> + .driver_data = IMX31_UDC, > > >>>>>>>> + }, { -> > >>>>>>>> + .name =3D "imx-udc-mx35", -> > >>>>>>>> + .driver_data =3D IMX35_UDC, +> > >>>>>>>> + .name = "imx-udc-mx35", +> > >>>>>>>> + .driver_data = IMX35_UDC, > > >>>>>>>> + }, { -> > >>>>>>>> + .name =3D "imx-udc-mx51", -> > >>>>>>>> + .driver_data =3D IMX51_UDC, +> > >>>>>>>> + .name = "imx-udc-mx51", +> > >>>>>>>> + .driver_data = IMX51_UDC, > > >>>>>>>> + } > > >>>>>>>> +}; > > >>>>>>> -> > >>>>>>> I wonder if your driver-data is actually needed since you can= - use string +> > >>>>>>> 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 +> > >>>>>> 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 ? +> > >>>>> 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). Yo= -u get -> > >>>> the a pointer to the driver_data for free. So you don't need any= - string +> > >>>> 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 +> > >>> 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 spac= -e 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 ins= -tead -> > >> of a call to a strcmp(), if you have a switch/case and IMX*_UDC is= - an +> > >> 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. -> > >=20 -> > > 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 actu= -ally +> > > +> > > 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. -> >=20 -> > Usually there isn't any Changelog between IP cores used in the differ= -ent -> > fsl processors (at least available outside of fsl), that makes it qui= -te -> > difficult to say if something found on one imx is really the same as = -on +> > +> > 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. -> >=20 -> > just my 2=A2 ->=20 +> > +> > 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. @@ -105,15 +83,14 @@ 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. ->=20 -> --=20 +in the future, using enum is easier than string comparison for expanding something. +> +> -- > balbi ---=20 +-- Best Regards, Peter Chen diff --git a/a/content_digest b/N1/content_digest index ffd84df..af685ca 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,119 +8,89 @@ "ref\020130114105357.GH10874@arwen.pp.htv.fi\0" "ref\050F3E5E8.2000905@pengutronix.de\0" "ref\020130114110600.GI10874@arwen.pp.htv.fi\0" - "From\0Peter Chen <peter.chen@freescale.com>\0" - "Subject\0Re: [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id\0" + "From\0peter.chen@freescale.com (Peter Chen)\0" + "Subject\0[PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id\0" "Date\0Mon, 14 Jan 2013 20:56:33 +0800\0" - "To\0Felipe Balbi <balbi@ti.com>\0" - "Cc\0r58472@freescale.com" - gregkh@linuxfoundation.org - linux-usb@vger.kernel.org - Marc Kleine-Budde <mkl@pengutronix.de> - kernel@pengutronix.de - shawn.guo@linaro.org - linuxppc-dev@lists.ozlabs.org - " linux-arm-kernel@lists.infradead.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Mon, Jan 14, 2013 at 01:06:00PM +0200, Felipe Balbi wrote:\n" "> On Mon, Jan 14, 2013 at 12:03:04PM +0100, Marc Kleine-Budde wrote:\n" "> > On 01/14/2013 11:53 AM, Felipe Balbi wrote:\n" "> > > Hi,\n" - "> > >=20\n" + "> > > \n" "> > > On Mon, Jan 14, 2013 at 11:50:41AM +0100, Marc Kleine-Budde wrote:\n" "> > >> On 01/14/2013 11:39 AM, Felipe Balbi wrote:\n" - "> > >>> On Mon, Jan 14, 2013 at 11:34:05AM +0100, Marc Kleine-Budde wrote=\n" - ":\n" + "> > >>> On Mon, Jan 14, 2013 at 11:34:05AM +0100, Marc Kleine-Budde wrote:\n" "> > >>>> On 01/14/2013 11:24 AM, Felipe Balbi wrote:\n" - "> > >>>>> On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wro=\n" - "te:\n" + "> > >>>>> On Mon, Jan 14, 2013 at 11:18:53AM +0100, Marc Kleine-Budde wrote:\n" "> > >>>>>> On 01/14/2013 11:16 AM, Felipe Balbi wrote:\n" "> > >>>>>>> Hi,\n" "> > >>>>>>>\n" "> > >>>>>>> On Mon, Jan 14, 2013 at 06:12:39PM +0800, Peter Chen wrote:\n" - "> > >>>>>>>> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct=\n" - " device *dev)\n" - "> > >>>>>>>> =20\n" + "> > >>>>>>>> @@ -2756,22 +2753,41 @@ static int fsl_udc_otg_resume(struct device *dev)\n" + "> > >>>>>>>> \n" "> > >>>>>>>> \treturn fsl_udc_resume(NULL);\n" "> > >>>>>>>> }\n" "> > >>>>>>>> -\n" - "> > >>>>>>>> /*---------------------------------------------------------=\n" - "----------------\n" + "> > >>>>>>>> /*-------------------------------------------------------------------------\n" "> > >>>>>>>> \tRegister entry point for the peripheral controller driver\n" - "> > >>>>>>>> -----------------------------------------------------------=\n" - "---------------*/\n" + "> > >>>>>>>> --------------------------------------------------------------------------*/\n" "> > >>>>>>>> -\n" - "> > >>>>>>>> +static const struct platform_device_id fsl_udc_devtype[] =3D=\n" - " {\n" + "> > >>>>>>>> +static const struct platform_device_id fsl_udc_devtype[] = {\n" "> > >>>>>>>> +\t{\n" - "> > >>>>>>>> +\t\t.name =3D \"imx-udc-mx25\",\n" - "> > >>>>>>>> +\t\t.driver_data =3D IMX25_UDC,\n" + "> > >>>>>>>> +\t\t.name = \"imx-udc-mx25\",\n" + "> > >>>>>>>> +\t\t.driver_data = IMX25_UDC,\n" "> > >>>>>>>> +\t}, {\n" - "> > >>>>>>>> +\t\t.name =3D \"imx-udc-mx27\",\n" - "> > >>>>>>>> +\t\t.driver_data =3D IMX27_UDC,\n" + "> > >>>>>>>> +\t\t.name = \"imx-udc-mx27\",\n" + "> > >>>>>>>> +\t\t.driver_data = IMX27_UDC,\n" "> > >>>>>>>> +\t}, {\n" - "> > >>>>>>>> +\t\t.name =3D \"imx-udc-mx31\",\n" - "> > >>>>>>>> +\t\t.driver_data =3D IMX31_UDC,\n" + "> > >>>>>>>> +\t\t.name = \"imx-udc-mx31\",\n" + "> > >>>>>>>> +\t\t.driver_data = IMX31_UDC,\n" "> > >>>>>>>> +\t}, {\n" - "> > >>>>>>>> +\t\t.name =3D \"imx-udc-mx35\",\n" - "> > >>>>>>>> +\t\t.driver_data =3D IMX35_UDC,\n" + "> > >>>>>>>> +\t\t.name = \"imx-udc-mx35\",\n" + "> > >>>>>>>> +\t\t.driver_data = IMX35_UDC,\n" "> > >>>>>>>> +\t}, {\n" - "> > >>>>>>>> +\t\t.name =3D \"imx-udc-mx51\",\n" - "> > >>>>>>>> +\t\t.driver_data =3D IMX51_UDC,\n" + "> > >>>>>>>> +\t\t.name = \"imx-udc-mx51\",\n" + "> > >>>>>>>> +\t\t.driver_data = IMX51_UDC,\n" "> > >>>>>>>> +\t}\n" "> > >>>>>>>> +};\n" "> > >>>>>>>\n" - "> > >>>>>>> I wonder if your driver-data is actually needed since you can=\n" - " use string\n" + "> > >>>>>>> I wonder if your driver-data is actually needed since you can use string\n" "> > >>>>>>> comparisson to achieve the exact same outcome.\n" "> > >>>>>>\n" - "> > >>>>>> Why use a string compare, if the kernel infrastructure already=\n" - " does this\n" + "> > >>>>>> Why use a string compare, if the kernel infrastructure already does this\n" "> > >>>>>> for you?\n" "> > >>>>>\n" - "> > >>>>> what do you mean ? What kernel infrastructure is doing waht for=\n" - " me ?\n" + "> > >>>>> what do you mean ? What kernel infrastructure is doing waht for me ?\n" "> > >>>>\n" - "> > >>>> The kernel infrastructure is doing the string compare for you to=\n" - " match\n" - "> > >>>> the device against the driver (via platform_device_id->name). Yo=\n" - "u get\n" - "> > >>>> the a pointer to the driver_data for free. So you don't need any=\n" - " string\n" + "> > >>>> The kernel infrastructure is doing the string compare for you to match\n" + "> > >>>> the device against the driver (via platform_device_id->name). You get\n" + "> > >>>> the a pointer to the driver_data for free. So you don't need any string\n" "> > >>>> compare in the driver later.\n" "> > >>>\n" - "> > >>> but current driver data is just duplicating name with an integer,=\n" - " it's\n" + "> > >>> but current driver data is just duplicating name with an integer, it's\n" "> > >>> pretty useless driver data.\n" "> > >>\n" "> > >> I don't think so - another argument:\n" - "> > >> Less code. As struct platform_device_id is a static array the spac=\n" - "e is\n" - "> > >> allocated anyway. So it doesn't make any difference if driver_data=\n" - " is\n" - "> > >> NULL or not. Later you just need to make an integer comparison ins=\n" - "tead\n" - "> > >> of a call to a strcmp(), if you have a switch/case and IMX*_UDC is=\n" - " an\n" + "> > >> Less code. As struct platform_device_id is a static array the space is\n" + "> > >> allocated anyway. So it doesn't make any difference if driver_data is\n" + "> > >> NULL or not. Later you just need to make an integer comparison instead\n" + "> > >> of a call to a strcmp(), if you have a switch/case and IMX*_UDC is an\n" "> > >> enum, the compiler will warn you if you've missed an IMX variant.\n" - "> > >=20\n" - "> > > fair enough, but then don't create a different enum value for each =\n" - "imx\n" - "> > > instance if they're mostly the same. Differentiate only what's actu=\n" - "ally\n" + "> > > \n" + "> > > fair enough, but then don't create a different enum value for each imx\n" + "> > > instance if they're mostly the same. Differentiate only what's actually\n" "> > > different.\n" - "> >=20\n" - "> > Usually there isn't any Changelog between IP cores used in the differ=\n" - "ent\n" - "> > fsl processors (at least available outside of fsl), that makes it qui=\n" - "te\n" - "> > difficult to say if something found on one imx is really the same as =\n" - "on\n" + "> > \n" + "> > Usually there isn't any Changelog between IP cores used in the different\n" + "> > fsl processors (at least available outside of fsl), that makes it quite\n" + "> > difficult to say if something found on one imx is really the same as on\n" "> > the other one. And they (usually) don't provide any versioning\n" "> > information in a register or the documentation.\n" - "> >=20\n" - "> > just my 2=A2\n" - ">=20\n" + "> > \n" + "> > just my 2?\n" + "> \n" "> $SUBJECT is trying to differentiate a single feature (or maybe two) to\n" "> replace cpu_is_xxx(), then expose that on driver_data without creating\n" "> one enum value for each release from fsl.\n" @@ -129,17 +99,16 @@ "integrate PHY interface, clk operation, or workaround for IC limitation.\n" "\n" "Maybe, it will add more future or SoCs (maybe not for this driver)\n" - "in the future, using enum is easier than string comparison for expanding =\n" - "something.\n" - ">=20\n" - "> --=20\n" + "in the future, using enum is easier than string comparison for expanding something.\n" + "> \n" + "> -- \n" "> balbi\n" "\n" "\n" "\n" - "--=20\n" + "-- \n" "\n" "Best Regards,\n" Peter Chen -ed899cdc4736ee79bbe60777e51cd9c98889a487d61d6589f1a80a7b14d3959e +5accc5e1c76628dd71aefba6349de809a3f0b79cadb0188d0444829fcad65c0c
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.