On Tue, Jan 28, 2025, at 16:34, Christophe Leroy wrote:
> Le 28/01/2025 à 16:24, Christophe Leroy a écrit :
>> Le 28/01/2025 à 16:07, Julian Vetter a écrit :
>>> With 'ppc' I was refering to 'include/asm-ppc/io.h'. But you're right,
>>> when going back a bit, in the 'include/asm-powerpc/io.h' there are two
>>> cases, one (eeh_memcpy_fromio) which does the the 'eieio', and a second,
>>> i.e., 'iSeries_memcpy_fromio' which does a byte-wise copy. But in the
>>> ppc code ('include/asm-ppc/io.h') there is a simple memcpy. I was
>>> referring to this one. But my description is not very clear. Sorry for
>>> that.
>>
>> But then is your change still valid ? Isn't there some corner case that
>> still need it ? Is it a valid argument that because memcpy_toio()
>> doesn't need it memcpy_fromio() doesn't need it either ?
>
> I see that _insb(), _insw_ns() and _insl_ns() also have eieio() while
> _outsb(), _outsw_ns() and _outsl_ns() don't. Why not change those as
> well if you think eieio() is not needed ?
I think that makes sense, even if it's beyond the scope of Julian's
work to unify the memcpy/memset I/O helpers across architectures.
I looked into the pre-2.6.12 history of arch/powerpc64 to see how
the eieio got in there originally and found that at the time the
string functions got added, this is what the readl() etc functions
did. readl() itself went through a longer set of changes to end
up with the current sync/twi/isync version, but the string functions
were never updated again during any of the later changes.
The bit that needs to be captured in the changelog here is that
on all other architectures, strcpy_fromio/strcpy_toio are written
to allow prefetching/combining/reordering, while the powerpc
version prevents this in strcpy_fromio for apparently only history
reasons.
Arnd
