We can commit this once we get more testing done.

In D9759#204260, @rozhuk.im-gmail.com wrote:

I have some AMD: E350, 5350, APU 6800, Phenom II X4 955 - test OK.

How can we test this on all hardware versions? I don't have AMD hardware. You could ask on the mailing list.

This needs a lot of style fixes. Please read the style man page and check other drivers for examples.

In D8250#172348, @br wrote:

here is another one possible solution

In D8250#172346, @br wrote:

In D8250#172304, @rpaulo wrote:

In D8250#172233, @br wrote:

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

Then how is it reading the original instruction correctly?

it reads the correct value, e.g. 0x67bdfff000000000. Casting it to uint32_t gives us 0x67bdfff0.

In D8250#172233, @br wrote:

What does this have to do with big endianess? You're basically moving 8 bytes forward and then 4 bytes backwards. What system is this on?

it is MIPS64EB. Unsigned long is 8 bytes, instruction is 4 bytes, so it copies wrong data (it copies zeroes)

In D8250#172166, @br wrote:

In D8250#171624, @rpaulo wrote:

I don't think this is right. Not all big endian systems are LP64.

why? I bet it should work with any sizeof(unsigned long), e.g. 4 or 8

I don't think this is right. Not all big endian systems are LP64.

You need to import this to the vendor area first and then merge it from there.

Looks good.

Please ping me by email directly next time.

Did you make sure src.opts.mk was included early in every file you changed? If yes, it looks ok.

In D4550#95983, @imp wrote:

A couple of questions:

Are you planning on importing sys/contrib/lua into vendor somewhere and then copying to sys/contrib/lua and then applying local changes (if any)?