Looks good to me.
Thanks!

Looks good to me. Thanks.

Thanks, Hiroki san!

Handle PCI_RES_BUS special way.

While working on a separate change (GitHub/bsdjhb/freebsd/tree/bus_map_resource_more) I remembered more of why PCI_RES_BUS is special. It's presence indicates to MI code (e.g. sys/dev/pci/pci_pci.c) that the MD host-PCI bridge drivers support managing bus numbers and so bus ranges should be allocated via bus_alloc_resource(). After the bus_map_resource_more branch lands, it will be possible to rework the one gross hack in pci_pci.c (where it calls bus_activate_resource to "map" child resources but asking the parent to do so) and then NEW_PCIB will be able to be turned on by default for all archs. However, the PCI_RES_BUS bits still need to be conditional to platforms that support PCI_RES_BUS. This is generally managed in the host-PCI bridge drivers rather than in the nexus. So in practice the '#ifdef NEW_PCIB' in the new header is in fact wrong. The real test is something more complex like this:

#if ((defined(i386) || defined(amd64)) && defined(NEW_PCIB)
#define PCI_RES_BUS 5
#endif

Except you need more convoluted expressions to handle other architectures. For x86 the rules is that bus numbers are only supported in host-PCI bridge drivers if NEW_PCIB is defined. It seems that only riscv, powerpc, and sparc64 don't already define PCI_RES_BUS, so perhaps a negative architecture list is shorter than a positive one.

Rename base to baseoff. Fix comment.

In D21827#476548, @markj wrote:

Can you show the readelf -S output for the input file where this change matters? The change looks ok to me, but I do not understand why it is useful.

In D21703#476461, @jhb wrote:

Some places use whether or not PCI_RES_BUS is defined to decide if they should handle PCI bus numbers. BTW, I called it PCI_RES_BUS instead of SYS_RES_* because it isn't a bus-independent "system" resource (like memory or I/O ports or DMA channels), but instead is specific to a PCI bus (and in a multi-segment/domain system you would have duplicates even).

In D21703#475791, @kib wrote:

In D21703#475705, @ray wrote:

Return back #ifdef NEW_PCIB, @jhb not sure it is safe to omit.

Can you explain why ?

Return back #ifdef NEW_PCIB, @jhb not sure it is safe to omit.

Nice, that it works.

It is wrong way to fix elfcopy bug.
Thanks to @strejda for pointing that.

In D21703#473617, @kib wrote:

This looks fine to me, but I have no idea why John put PCI_RES_BUS under #ifdef NEW_PCIB instead of defining it always.

I will wait for @jhb input about that. But everything I found PCI_RES_BUS were checked together w/ NEW_PCIB. And I didn't found any place where defined PCI_RES_BUS can break anything.

o Do not copyright "empty files"
o Give old owner (i386) old number (PCI_RES_BUS to 5)

Looks good. Thanks.

In D21478#469653, @nwhitehorn wrote:

I have pretty mixed feelings about this approach. It only works for ofwbus children, not simplebus children, and canonicalizes a bunch of behaviors that I don't believe are standards (I'm in an airport departure lounge and don't have the spec handy). I'm also not really sure how it interacts with multipass etc. Could you elaborate a little more on the mechanism?

Like it. Thanks!

s/Firware/Firmware/

Nice to have feature, to allow to wait for required drivers to attach.

Check paddr for overflow.

Check paddr for overflow.

In D21272#462874, @kib wrote:

In D21272#462601, @markj wrote:

Can't we simply test paddr < rounddown2(seg->end, VM_LEVEL_0_SIZE)?

Is seg->end 0xffffffff or 0 for the problematic case ?

No, it is 0xfff00000. But problem with paddr, which is 32bits and paddr + 0x100000 will be 0x00000000.
It satisfy check:
0xffe00000 <= 0xfff00000 - true
0xfff00000 <= 0xfff00000 - true
0x00000000 <= 0xfff00000 - true

Or even (intmax_t), for this code not to make problems 10-20 years later :)

What about that version? :)

Simplify patch.

In D21272#462554, @markj wrote:

In D21272#462545, @ray wrote:

In D21272#462526, @markj wrote:

Don't we then have the same problem if seg->end < VM_LEVEL_0_SIZE?

only if you want to add some really small seg at 0x00000000 :)

Why does it have to be at 0x00000000? With the segment below we will test 0x100000 <= 0x9d000 - 0x100000, and the variables are unsigned.

SEGMENT 0:  
                                   
start:     0x10000                 
end:       0x9d000
domain:    0                       
free list: 0xffffffff81233cb0

In D21272#462526, @markj wrote:

Don't we then have the same problem if seg->end < VM_LEVEL_0_SIZE?

Remove extra parentheses.

Add Michal, to have one more test.

Thanks!

In D19266#412263, @kib wrote:

In D19266#412252, @ray wrote:

Looks fine!
Cosmetic: why not to name it just "xz" instead of "xz_embedded"?

Both module, module build directory, and linker file are named xz. What part name don't you like ?

Looks fine!
Cosmetic: why not to name it just "xz" instead of "xz_embedded"?

Looks good.
Thank you!

Looks cute :)

Correct. Thank you!

Sorry, I don't feel myself enough knowledgeable to give sane answer here :)

Looks good. Thanks.

style(9) issues still here (but in different functions), but there is a lot from very first vt project release.

Looks good. Thank you, Jonathan!

Thanks a lot, guys!

In D8749#181338, @yamori813_yahoo.co.jp wrote:

gpiobus_pin_setflags() in gpibus.c have check gpio_check_flags(). This code check pin capabirity. If low driver not support GPIO_PIN_PULLUP/GPIO_PIN_PULLDOWN return EINVAL.

Cool! Thank you Oleksandr!

Now, looks fine.

Now, looks fine.

I'm afraid JEDEC CFI standard do not allow simple omit of upper byte(s), you have to try bus and chip data width and get temporary configuration, til required data read from chip.

Only one comment left.

Looks good to me too. Thanks Stanislav.

I like it

In D1291#20, @royger wrote:

I'm not sure I'm following, AFAICT nexus doesn't know anything about the FB, how is it supposed to claim the memory regions?

In D1291#18, @emaste wrote:

In D1291#15, @ray wrote:

Possible, resource can be busy (by parent who setup FB), so if resource busy we have not to panic.

I think we can require the parent setting up the FB to alloc the resource, no?

I like it.
Good idea Roger. Thank you for that!

At least vt(4) currently less problematic than syscons(4) :-D

There is several ways:

1. You can change ABI, but not merge that changes to older releases.
2. Or keep ABI, and merge whatever you need

:-D

Looks fine.
But I did not able to test it :) (at least now)