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:

quoted

On 01/14/2013 06:40 PM, Felipe Balbi wrote:

quoted

Hi,
=20
On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
=20
<snip>
=20

quoted

quoted

quoted

Usually there isn't any Changelog between IP cores used in the d=

ifferent

quoted

quoted

quoted

quoted

quoted

fsl processors (at least available outside of fsl), that makes i=

t quite

quoted

quoted

quoted

quoted

quoted

difficult to say if something found on one imx is really the sam=

e as on

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

replace cpu_is_xxx(), then expose that on driver_data without cre=

ating

quoted

quoted

quoted

quoted

one enum value for each release from fsl.

Felipe, every one or two SoCs may have their special operations fo=

r

quoted

quoted

quoted

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

quoted

quoted

API respectively. Workarounds, fair enough, we need to handle them;=

 but

quoted

quoted

ideally those should be based on runtime revision detection, not so=

me

quoted

quoted

hackery using driver_data.

=20
If this is actually possible, I'd love to do this. But IP vendor don'=

t

quoted

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