Hi > >On 14/12/18 4:56 PM, Felipe Balbi wrote: >> Hi, >> >> Sekhar Nori <nsekhar@xxxxxx> writes: >>>>>>>> All this should be part of comments in code along with information about >>>>>>>> controller versions which suffer from the errata. >>>>>>>> >>>>>>>> Is there a version of controller available which does not have the >>>>>>>> defect? Is there a future plan to fix this? >>>>>>>> >>>>>>>> If any of that is yes, you probably want to handle this with runtime >>>>>>>> detection of version (like done with DWC3_REVISION_XXX macros). >>>>>>>> Sometimes the hardware-read versions themselves are incorrect, so its >>>>>>>> better to introduce a version specific compatible too like >>>>>>>> "cdns,usb-1.0.0" (as hinted to by Rob Herring as well). >>>>>>>> >>>>>>> >>>>>>> custom match_ep is used and works with all versions of the gen1 >>>>>>> controller. Future (gen2) releases of the controller won’t have such >>>>>>> limitation but there is no plan to change current (gen1) functionality >>>>>>> of the controller. >>>>>>> >>>>>>> I will add comment before cdns3_gadget_match_ep function. >>>>>>> Also I will change cdns,usb3 to cdns,usb3-1.0.0 and add additional >>>>>>> cdns,usb3-1.0.1 compatible. >>>>>>> >>>>>>> cdns,usb3-1.0.1 will be for current version of controller which I use. >>>>>>> cdns,usb3-1.0.0 will be for older version - Peter Chan platform. >>>>>>> I now that I have some changes in controller, and one of them require >>>>>>> some changes in DRD driver. It will be safer to add two separate >>>>>>> version in compatibles. >>>>>>> >>>>>> >>>>>> Pawel, could we have correct register to show controller version? It is >>>>>> better we could version judgement at runtime instead of static compatible. >>>>> >>>>> Agree with detecting IP version at runtime. >>>>> >>>>> But please have some indication of version in compatible string too, >>>> >>>> why? Runtime detection by revision register should be the way to go if >>>> the HW provides it. Why duplicate the information in compatible string? >>>> >>>>> especially since you already know there is going to be another revision >>>>> of hardware. It has the advantage that one can easily grep to see which >>>>> hardware is running current version of controller without having access >>>>> to the hardware itself. Becomes useful later on when its time to >>>>> clean-up unused code when boards become obsolete or for requesting >>>>> testing help. >>>> >>>> This doesn't sound like a very strong argument, actually. Specially when >>>> you consider that, since driver will do revision checking based on >>>> revision register, you already have strings to grep. Moreover, we don't >>>> usually drop support just like that. >>> >>> AFAICS, it is impossible to know just by grep'ing if there is any >>> hardware still supported in kernel and using DWC3_REVISION_194A, for >>> example. >> >> but why do you even care? > >When, for example, its coming in the way of some clean-up I am >attempting to do. > >> >>> If we are never going to drop support for any revision, this does not >>> matter much. >>> >>> Also, once you have the controller supported behind PCI, then I guess >>> you are pretty much tied to having to read hardware revision at runtime. >> >> that's another argument *for* using runtime detection, not against it. > >I know :). I should have stated that in last e-mail itself, I am okay >with just runtime detection. I agree with you. Controller has usb_cap6 register that keep device controller version. It's not a problem doing such detection at runtime. I will do it in this way. But also I will add extra compatible to dt-binding. Even if this will not be used in driver, it informs that there are several versions of controller. Thanks, Pawel
