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. -- Best regards, Alexander Sverdlin. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
