Hi, On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote: > * Faiz Abbas <faiz_abbas@xxxxxx> [180703 07:31]: >> Hi, >> >> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote: >>> * Tony Lindgren <tony@xxxxxxxxxxx> [180611 07:06]: >>>> * Faiz Abbas <faiz_abbas@xxxxxx> [180611 06:48]: >>>>> Hi, >>>>> >>>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote: >>>>>> * Faiz Abbas <faiz_abbas@xxxxxx> [180611 06:28]: >>>>>>> Great. I thought I completely misunderstood you. But I don't see what >>>>>>> adding another function will accomplish. A QUIRK flag used in the same >>>>>>> function would work well enough> >>>>>> Fine with me as long as the function stays simple for both >>>>>> syss and sysc reset. >>>>>> >>>>> >>>>> >>>>> In general a reset status bit being in sysstatus is the norm and it >>>>> being in sysconfig should be the "quirk" for which a flag needs to be >>>>> added. What do you think? >>>> >>>> Sure makes sense to me. >>>> >>>>> As an aside, naming bitshifts by the name of the platform they were >>>>> originally added in seems weird. There should be some generic mask >>>>> saying "soft reset is the 0th bit". Currently I am using >>>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many >>>>> different sysconfig types we have. >>>> >>>> Sure we could have a macro for that. >>> >>> So what's the conclusion on this one? Are you going to do one >>> more version of the ti-sysc driver patch? >>> >> >> Yes. I have just now been able to get back to this. Will post a v4 by >> tomorrow. > > OK thanks! > After taking a second look at this thread, I don't see anything big to be modified. We both agree that "reset status bit in sysconfig register" is the quirk case which can be added once such an IP is discovered in ti-sysc. All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0 for better readability and rebase it to the latest mainline. Do reply if you differ on the above. Thanks, Faiz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
