Arnd Bergmann
unread,May 24, 2019, 3:41:05 AM5/24/19Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Nick Desaulniers, Nathan Chancellor, Cliff Whickman, Robin Holt, Greg Kroah-Hartman, LKML, clang-built-linux, Stephen Hines, Tony Luck, r...@sgi.com, Fenghua Yu
I also had to take a look, and I think I understand what's going on,
and interestingly, the code is correct, both before and after your patch.
It's described in this comment:
/*
* Returns the physical address of the partition's reserved page through
* an iterative number of calls.
*
* On first call, 'cookie' and 'len' should be set to 0, and 'addr'
* set to the nasid of the partition whose reserved page's address is
* being sought.
* On subsequent calls, pass the values, that were passed back on the
* previous call.
*
* While the return status equals SALRET_MORE_PASSES, keep calling
* this function after first copying 'len' bytes starting at 'addr'
* into 'buf'. Once the return status equals SALRET_OK, 'addr' will
* be the physical address of the partition's reserved page. If the
* return status equals neither of these, an error as occurred.
*/
static inline s64
sn_partition_reserved_page_pa(u64 buf, u64 *cookie, u64 *addr, u64 *len)
so *len is set to zero on the first call and tells the bios how many bytes
are accessible at 'buf', and it does get updated by the BIOS to tell
us how many bytes it needs, and then we allocate that and try again.
With that explanation added,
Reviewed-by: Arnd Bergmann <
ar...@arndb.de>