On Mon, Sep 5, 2022, at 9:30 PM, Linus Walleij wrote:
> On Thu, Aug 18, 2022 at 12:28 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Thu, Aug 18, 2022 at 11:20 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
>> > I'd like this applied to the alpha tree if there is such a
>> > thing otherwise maybe Arnd can apply it to the arch generic
>> > tree?
>>
>> Sure, I can do that.
>
> Could you apply this to the arch tree? I see no signs of life from
> the alpha maintainers.
Sure, I can do that. I also realized that we can actually fold
all of asm-generic/io.h into linux/io.h directly once this is
complete for all architectures. Probably better to leave that for
6.1 though.
I wonder if I should also add send a patch to mark Alpha as
'Orphaned' like we did for arch/ia64 a while ago.
It's already marked as 'Odd fixes', but the last pull request
from Matt was over a year ago now.
>> > +/*
>> > + * These defines are necessary to use the generic io.h for filling in
>> > + * the missing parts of the API contract. This is because the platform
>> > + * uses (inline) functions rather than defines and the generic helper
>> > + * fills in the undefined.
>> > + */
>> > +#define virt_to_phys virt_to_phys
>> > +#define phys_to_virt phys_to_virt
>> > +#define memset_io memset_io
>> > +#define memcpy_fromio memcpy_fromio
>>
>> We tend to have these next to the function definition rather than
>> in a single place. Again, I'm not too worried here, just if you end
>> up reworking the patch in some form, or doing the same for the
>> other architectures that would be the way to do it.
>
> I looked into this, for parisc it was pretty straight forward. alpha has
> a bunch of competing static inlines and externs and what not, I don't
> see it helping to inline this, IMO it's actually better like this: "those
> were defined somewhere in the birdnest of ifdefs above".
>
> If it is a big issue I can start to pry into it.
I would move the #defines specifically because the header is such a
mess, that way it should become clearer to anyone looking at the
file where the declaration is.
The header uses an unusual trick of declaring an extern
function first and then optionally overriding it with an
inline. I think it uses 'extern inline' in place of
'static inline' because older gcc versions would otherwise
reject this, not because it actually depends on the 'extern
inline' semantics.
It's probably not too hard to move the macros next to the
'extern' declaration for those functions that have both an
'extern' and an 'inline' version. Don't spend too much
time on getting it right if it doens't work right away though,
I don't think it matters all that much.
Arnd
