From: Arnd Bergmann > Sent: 08 September 2021 10:50 ... > > > I don't know the hardware, so I can not answer the ioremap() question. > > > > Yes it should. But this driver dates back to 2.1.110, when only > > half of the architectures already had ioremap(). > > How does mvme16x even create the mapping? Is this a virtual address > that is hardwired to the bus or do you have a static mapping somewhere? > I see two other drivers accessing the nvram here > > arch/m68k/mvme16x/config.c:static MK48T08ptr_t volatile rtc = (MK48T08ptr_t)MVME_RTC_BASE; > arch/m68k/mvme16x/rtc.c: volatile MK48T08ptr_t rtc = (MK48T08ptr_t)MVME_RTC_BASE; > > The same trick should work here, just create a local variable with a > volatile pointer and read from that. Or define a C 'extern' for the actual data and get the linker script to assign a fixed value to the symbol. (Although that does pollute the global namespace.) An alternative is to use an asm statement so the compiler cannot track the actual value. Something like: #define launder(x) asm volatile( "" : "+r" (x)) MK48T08ptr_t rtc = (void *)MVME_RTC_BASE; launder(rtc); That also works a bit like READ_ONCE() except that is works on a value that is (hopefully) already in a register rather that during the read from memory. Useful when the compiler's 'value tracking' pessimises code. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
