Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, May 28, 2018 at 11:49:13AM +0200, Esben Haabendal wrote: >> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: >> >> > On Mon, May 28, 2018 at 08:20:15AM +0200, Esben Haabendal wrote: >> >> Hi >> >> >> >> The arm-dts-ls1021a-specify-tbipa-register-address.patch which have just >> >> been added to 4.4-stable, 4.9-stable, 4.14-stable and 4.16-stable trees, >> >> relies on the 2d23129b00d2a67e58a7b17205f5ba7ec4523fd0 in order to make >> >> sense. >> >> >> >> Could 2d23129b00d2a67e58a7b17205f5ba7ec4523fd0 be added to those trees >> >> as well? >> > >> > ~/linux/stable/linux-stable $ git show >> > 2d23129b00d2a67e58a7b17205f5ba7ec4523fd0 >> > fatal: bad object 2d23129b00d2a67e58a7b17205f5ba7ec4523fd0 >> > >> > Are you sure that is the correct git id? >> >> Obviously not. >> >> The correct id is 21481189e8ffa4016e398d46ac6d66fb0f23acc3 >> >> Sorry about that. > > In looking at this patch, it just seems to be changing the way the > information is retrieved from the hardware/dts file, and as such, does > not seem like a viable stable kernel patch at this point in time. > > So I've removed the original > arm-dts-ls1021a-specify-tbipa-register-address.patch patch from all of > the specific kernel patch queues now. Yes, 21481189e8ffa4016e398d46ac6d66fb0f23acc3 changes the way the TBIPA register is accessed. But only if DTS has two register blocks, which is not the case without 5571196135abb6d51e01592812997403c136067c. So I think it is fair to say that it is backwards compatible, but whether it together with 5571196135abb6d51e01592812997403c136067c is viable for stable right now is another question. They do change how hardware is accessed, but they changes it so that it fixes a bug on LS1021A. /Esben
