Re: [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id

[Peter Chen <peter.chen@freescale.com>]

On Mon, Jan 14, 2013 at 07:57:24PM +0200, Felipe Balbi wrote:
> On Mon, Jan 14, 2013 at 06:54:22PM +0100, Marc Kleine-Budde wrote:
> > On 01/14/2013 06:40 PM, Felipe Balbi wrote:
> > > Hi,
> > >=20
> > > On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
> > >=20
> > > <snip>
> > >=20
> > >>>> Usually there isn't any Changelog between IP cores used in the d=
ifferent
> > >>>> fsl processors (at least available outside of fsl), that makes i=
t quite
> > >>>> difficult to say if something found on one imx is really the sam=
e as on
> > >>>> the other one. And they (usually) don't provide any versioning
> > >>>> information in a register or the documentation.
> > >>>>
> > >>>> just my 2=A2
> > >>>
> > >>> $SUBJECT is trying to differentiate a single feature (or maybe tw=
o) to
> > >>> replace cpu_is_xxx(), then expose that on driver_data without cre=
ating
> > >>> one enum value for each release from fsl.
> > >>
> > >> Felipe, every one or two SoCs may have their special operations fo=
r
> > >> integrate PHY interface, clk operation, or workaround for IC
> > >> limitation.
> > >=20
> > > the particular PHY and clk used should be hidden by phy layer and c=
lk
> > > API respectively. Workarounds, fair enough, we need to handle them;=
 but
> > > ideally those should be based on runtime revision detection, not so=
me
> > > hackery using driver_data.
> >=20
> > If this is actually possible, I'd love to do this. But IP vendor don'=
t
> > include a version register in their cores. :(
>=20
> then fair enough, driver_data or platform_data is the way to go, still
> my point (a) below is valid.
I will send v5 patch with your suggestion.

>=20
> --=20
> balbi



--=20

Best Regards,
Peter Chen