On Thursday 18 June 2015 03:34 PM, Alexander Sverdlin wrote: > Hi! > > On 18/06/15 11:47, ext Sekhar Nori wrote: >>> Ah, beyond the evalboards, there are device-trees not linked into the kernel, >>>> but flashed into the boards, as originally in OF. They are part of the HW, its >>>> description. Not part or description of the Kernel. And you have no way to >>>> introduce this fix any more without updating this OF part if you go with >>>> new compatible property. >> I see. So how critical is this fix? That should be described in the >> commit description. And if its really critical, stable kernel should be >> CCed too. > > Now we got to the point, see below... > >>>>>>>>>> And from the other PoV, device-trees are for something one cannot probe. We >>>>>>>>>> can probe for Keystone revisions and can free the end-user from this headache >>>>>>>>>> completely. >>>>>> Keep in mind that this can invite driver patching whenever version >>>>>> number is tinkered with in hardware - even for otherwise >>>>>> software-invsible changes. >>>> >>>> That's true. But I do not have an overview, how many IP versions do you actually have? >>>> I've found one revision in Davinci manual, one revision in Keystone manual, even >>>> including minor revision. Checking only major revision now can survive couple of minor >>>> changes in IP. >> Yeah, sticking to major version should help. What I am worried about are >> versions coming in future, not those existing. And development on >> keystone architecture is ongoing in TI. > > This is not really critical fix. Currently bus rate is lower than expected because of these > calculation errors. The fix maximizes the bus rate. So newer SoCs will run little bit slower > until support is added to this part of the code. Not really critical. So no point in CCing > stable maintainers also. If its not a critical fix, do we really need to care about older DTBs which have been ROM'ed into production? Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
