In D22367#504144, @gordon wrote:

I don't think secteam is the right reviewer for this change. Has this been reviewed by folks on the freebsd-net mailing list?

@secteam Do you have any objections to this patch?

@secteam Do you have any objections to this patch?

Added checking if pointer to reply structure is not NULL

It is considered as an algorithm to avoid ESN implementation in every driver (I have implemented ESN in cryptosoft and aesni only).
It would be perfect if OCF was prepared for ESN support or at least was organized in way that makes ESN implementation simpler than in current OCF.

First of all, @cem, @jhb, @mw thanks for your comments.

Removed unnecessary changes

Do you have still objections to this patch?

Do you have still objections to this patch?

Remove redundant ecam quirk.

Added obtaining ecam and bus number from ACPI. This allows us to remove ThunderX2 quirk connected with ecam.

Remove unused declarations.

Move quirks form acpi part to common part.

Links to patches emerged
Macros: https://reviews.freebsd.org/D15928
Quirks: https://reviews.freebsd.org/D15929

No functional changes. This is the previous patch with quirks and macros moved, as andrew suggested

Restore previous statement about Foundation sponsorship

Remove unused functions and declarations.

Do you have any objections to this patch?

Fixed all issues pointed by manu

Changed approach we add resources to rman. Clean unnecessary changes.

This is not final version!

It is good idea to provide support using quirks, however pci_host_generic_acpi still needs some resource allocation changes. I have limited ability to check if it doesn't break another devices, so from my point of view it is safe to provide separate driver.
Of course I will follow your advices, but I'm depending on you to perform review very carefully.

In D14538#305338, @nwhitehorn wrote:

In D14538#305284, @pdk_semihalf.com wrote:

I have a question about your 1st worry. Is this a scenario in which we are doing memcpy in eg. interrupt filter code? If not, could you explain what are you worry about?

Suppose we have an altivec- (or VSX-)using userland program. Vector registers on PPC, like all other architectures, are not saved and restored by interrupt handler code. Instead, they are only saved/restored by cpu_switch() and only if PCB_VEC is set. If a userland thread makes a syscall or otherwise ends up in the kernel, I do not see how this avoids clobbering the vector register state of the userland process. Is there something I am missing?

I have a question about your 1st worry. Is this a scenario in which we are doing memcpy in eg. interrupt filter code? If not, could you explain what are you worry about?

Added some checks, which detects situation when SRR1 is set to inappropriate value (eg. QEMU)

I wanted this file to be cpu.c equivalent but in assembler, that's why it was named cpu.S
I'd rather keep it cpu_subr64.S because in the near future I want to put highly optimized memcpy into it.

Updated diff. I think it will be the last one

Changed type of ps_per_tick to uint64_t

In D14330#302615, @nwhitehorn wrote:

In D14330#302546, @pdk_semihalf.com wrote:

Could you tell me more about scenario in which we branch to rstcode from software? I was looking for it but I found nothing.

Line 99 of locore64.S.

Could you tell me more about scenario in which we branch to rstcode from software? I was looking for it but I found nothing.

Thanks for your response.

Do you have any objections to this patch?

Completely changed patch. It uses hint provided by andrew.

My first approach was simply avoid fallback when 64 bit and 32 bit ioctl are equal. But it was terrible idea.
If you thought more about this issue, you would realize that problem is in calculating ioctl number and recognizing 32 bit ioctl using sizeof.
Sooner or later breaking ioctl ABI will be necessary.

Almost all 32 bit ioctl work. In BPF there is BIOCSRTIMEOUT (takes timeval as argument) and BIOCSRTIMEOUT32 (takes timeval32 as argument) which are equal on non intel arch.
That ioctl works only on amd64 because timeval32 has size of 8 bytes. But on other arch, timeval32 has size of 12 bytes (16 bytes with padding)