Hi, On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote: <snip> > > > 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¢ > > > > $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. > > Felipe, every one or two SoCs may have their special operations for > integrate PHY interface, clk operation, or workaround for IC > limitation. the particular PHY and clk used should be hidden by phy layer and clk API respectively. Workarounds, fair enough, we need to handle them; but ideally those should be based on runtime revision detection, not some hackery using driver_data. > 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. a) I never told you to *not* use enum. I said that creating DEVICE_A, DEVICE_B, DEVICE_C, DEVICE_D and DEVICE_E values when DEVICE_B, DEVICE_C and DEVICE_E behave exactly the same is unnecessary. b) you can't be expecting to add future SoCs support to fsl udc, I have already said and will repeat for the last time: move to chipidea ASAP. New SoCs cannot be added to fsl udc, you *must* use chipidea for anything new and move the legacy to chipidea eventually. I will wait for a full year for you to do that, but after that I will have to start deleting drivers for the sake of avoid duplication of effort. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
