Looks good to me.
Thanks!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 7 2020
Dec 25 2019
Dec 1 2019
Looks good to me. Thanks.
Nov 13 2019
Oct 1 2019
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
#endifExcept 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.
Sep 29 2019
Rename base to baseoff. Fix comment.
Sep 28 2019
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.
Sep 27 2019
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).
Sep 26 2019
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 ?
Sep 25 2019
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.
Sep 21 2019
Sep 19 2019
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)
Sep 18 2019
Looks good. Thanks.
Sep 17 2019
Sep 11 2019
Sep 7 2019
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?
Sep 4 2019
Like it. Thanks!
Aug 31 2019
Aug 30 2019
s/Firware/Firmware/
Aug 21 2019
Nice to have feature, to allow to wait for required drivers to attach.
Aug 16 2019
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
Aug 15 2019
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.
Mar 20 2019
Feb 23 2019
Feb 21 2019
Feb 20 2019
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"?
Aug 17 2018
Jun 21 2018
Dec 27 2017
Dec 5 2017
Correct. Thank you!
Aug 4 2017
Sorry, I don't feel myself enough knowledgeable to give sane answer here :)
Aug 2 2017
Looks good. Thanks.
Jul 28 2017
style(9) issues still here (but in different functions), but there is a lot from very first vt project release.
Feb 22 2017
Looks good. Thank you, Jonathan!
Feb 10 2017
Dec 13 2016
Thanks a lot, guys!
Dec 11 2016
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.
Sep 29 2016
Cool! Thank you Oleksandr!
Sep 4 2016
Jun 23 2016
Now, looks fine.
Jun 10 2016
May 27 2016
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.
May 23 2016
Only one comment left.
Apr 6 2016
Looks good to me too. Thanks Stanislav.
Sep 14 2015
Apr 23 2015
Dec 19 2014
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?
I like it.
Good idea Roger. Thank you for that!
Oct 24 2014
At least vt(4) currently less problematic than syscons(4) :-D
Oct 21 2014
There is several ways:
- You can change ABI, but not merge that changes to older releases.
- Or keep ABI, and merge whatever you need
:-D
Looks fine.
But I did not able to test it :) (at least now)