On 2017/1/16 19:29, Marc Zyngier wrote: > On 16/01/17 10:37, Ding Tianhong wrote: >> >> >> On 2017/1/12 21:24, Ding Tianhong wrote: >>> >>> On 2017/1/12 17:11, Marc Zyngier wrote: >>>> On 12/01/17 04:23, Ding Tianhong wrote: >>>>> Hi Marc: >>>>> >>>>> How about this v7, if any suggestions very grateful. >>>> >>>> It's been less than 5 days since you posted this. I'll get to it once I >>>> finish reviewing all the other patches that are sitting in the queue >>>> right before yours. >>>> >>> >>> Ok and sorry for the noisy. >>> >> >> Hi Marc： >> >> After discussion with the chip developer, we decide to update the erratum id for this bug, so I will resend a new version >> about this, if you has start to review this v7 patch set, I think I could wait until you have finished yet. :) > > This has to be a stable erratum ID, and it won't be changed once the > workaround is merged (all you'll be able to do is to add new IDs where > the same fix is applicable). So please post the revised series, and make > sure that this is the *final* ID update. > Yes，the *final* ID will be the stable ID and could be record in CPU erratum doc which could be get from Hisilicon webpage. The final format for erratum ID is just like: <Errata-Prefix><SeriesFlag><ModuleID><SerialNum> Errata-Prefix=1610, SeriesFlag=1, ModuleID=0x, SerialNum=01. Thanks Ding > Thanks, > > M. > -- 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
