I haven't looked much on aliases, but this looks good to me.

In D25168#566279, @delphij wrote:

On an unrelated note -- @mav I noticed that you have added the prefer non-withered providers logic in rS280685 but it's not obvious to me why we want to return an withered provider in g_provider_by_name(). Do you still remember the scenario that this would be useful for the caller?

I would be happy if we had some good abstraction for standalone DMA engines. Right now we are using IOAT engine in our products, but I'd be happy if there would be decent option from AMD side also. While this code is a good start, it is nowhere near something we could already use.

Makes sense to me, but I am not very familiar with the PNP_INFO code.

If its indeed known to be broken -- OK.

I am not very close to ciss, only fixed couple issues there, but it looks OK to me, except the initiator_id comment and somewhat weird way to detect max target number.

Make sure you test both MSI and legacy interrupts, because they may work very different. I don't have objections for the patch if it helps some broken hardware, but comparing to AHCI, the last generates another interrupt when interrupt status register is cleared while there is some more work left, avoiding another expensive register read. Second read should not be a huge deal for sound, but still it is not free.

It makes sense to me on a brief look, but please request review from the driver maintainers.

While its a good catch to find the overflow, your solution will not work on architectures with strict alignment. The problem is that struct tmpfs_fid_data require 64-bit alignment due to its fields, while fid_data offset within struct fid is 32 bits. So either you need some alignment-agnostic access to the fid_data, such as bcopy(), or split field(s) to 32-bit parts to fit into the struct fid alignment, or struct fid needs some padding to align fid_data to 64bits.

It should be OK if desided, but I don't think there is a leak, since the whole old configuration is freed after application complete.

Makes sense to me.

I've made only a very brief look, but here are some comments. Also it would be nice to reviewers if you would not mix formatting and real code changes.

In D24645#542647, @gallatin wrote:

Don't we already have some of this via kern.sched.trysteal_limit ? I guess you are proposing adjusting trysteal_limit, and looking frequently at cores that share L2, and less frequently the farther out you go? I like that idea in general. But I'm not confident in my ability to implement or tune it.

I was thinking about something like this many times. It would be nice to skip this often useless work. But each time I am stopped by worry that it may cause CPU under-utilization on a systems with load average about 1 per SMT thread. 10ms interval you mentioned sounds quite large to me, but honestly I can imagine some synchronous irregular load patterns where any chosen interval will cause a pessimization, dramatically increasing execution latency.

I think it is correct, except the same should be added also 48 lines lower.

In D24480#538896, @imp wrote:

I'm thinking, though, that these should all just be normal timeouts that are short so we have the same issues everywhere and at least try to cancel the transaction before returning.

I worry this is at least incomplete implementation or even wrong approach. The problem I see in what happen if/when the command still complete after the polling gave up, or when the timeout handler expire. I think at very least it will be a stack corruption.

This seems to be a very old piece of code. :)