On Mon, May 18, 2020 at 04:48:20PM +0300, Serge Semin wrote: > On Fri, May 15, 2020 at 11:06:47PM +0200, Thomas Bogendoerfer wrote: > > On Fri, May 15, 2020 at 10:48:27AM +0300, Serge Semin wrote: > > > Thomas, > > > Could you take a look at my comment below so I could proceed with the > > > patchset v3 development? > > > > I can't help, but using r4k clocksource with changing frequency is > > probaly only usefull as a random generator. So IMHO the only two > > options are disabling it or implement what arch/x86/kernel/tsc.c does. > > > > Thomas. > > Thomas, could you proceed with the rest of the patches review? > ├─>[PATCH v2 16/20] bus: cdmm: Add MIPS R5 arch support > ├─>[PATCH v2 15/20] mips: cdmm: Add mti,mips-cdmm dtb node support both are not my call, but look ok to me. > ├─>[PATCH v2 13/20] mips: early_printk_8250: Use offset-sized IO-mem accessors that's broken. A reg shift of 2 doesn't mean we could use 32bit access to the registers on other platforms. As I don't think adding some ifdefery makes things nicer, just implement the your prom_putchar in board code. > ├─>[PATCH v2 12/20] mips: MAAR: Add XPA mode support looks ok so far. > ├─>[PATCH v2 10/20] mips: Add CONFIG/CONFIG6/Cause reg fields macro that is fine > └─>[PATCH v2 09/20] mips: Add CP0 Write Merge config support this is IMHO a dangerous change. Enabling write merging for any CPU supporting it might triggers bugs. Do it in your board bringup code and at the moment I don't see a reason for the rest of that patch. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
