User Details
- User Since
- Jul 4 2018, 7:23 PM (308 w, 2 d)
Yesterday
I don't think any of these need to be __extension__({ ... }), you're not using them as an expression, you're using them as a statement, so do { ... } while (0) is perfectly fine.
Tue, May 28
Sun, May 26
Fri, May 24
I don’t understand how this diff relates to the commit message. Whether PASS contains a space or not, using its expansion and deleting its first line are two quite different things.
Though please mention that it's needed for musl in the commit message, otherwise it's not clear why we've been fine without this diff for years
Thu, May 23
Tue, May 21
Oh and MFC after?
Though please change your Fixes to be 3bfbb521fef5 ("ls: Improve POSIX compatibility for -g and -n.")
Mon, May 20
This seems to match what GCC does, though I'm not sure why either need it. Both drivers pass both of -lgcc and -lgcc_s, whether building an executable or shared library. Can you elaborate on the exact issue you're seeing without this?
It surprises me that GNU ld doesn't want to create canonical PLTs, but avoiding them is reasonable; they are to functions what copy relocations are to data.
Wed, May 15
Sat, May 11
It's hard to tell if this was a deliberate design choice or just not thought to be needed when the current UART_FDT_CLASS(_AND_DEVICE) framework was added, but I don't see a good alternative to this. Note that snps and tegra_uart are the only in-tree UART_FDT_CLASS users, and both wrap ns8250.
Thu, May 9
Fri, May 3
Thu, May 2
May 1 2024
I believe it's also legal to go and map two BARs to overlap so long as you don't try to access the overlapping range when that's the case? QEMU just maintains a list of PCI BARs and goes for the first one in the list that matches. Allocating the big chunk of MMIO memory statically at the start and just maintaining the list layered on top in PCI code as you mess with BARs seems like it would be a simple, more general fix, and should perform just fine? (Though passthrough may well be "fun" as you mention)
Apr 25 2024
My opinion is that, whilst they are by no means completely unambiguous and fully descriptive, picking a value that's close to right so the user has some idea what the error was even in the absence of error messages is better than just using a hard-coded wholly-meaningless 1 everywhere, as will inevitably happen (and already does when not using sysexits) as a result of this.
Apr 24 2024
Apr 19 2024
Apr 8 2024
Apr 7 2024
Why do we need a copy of this code rather than just tweaking bsdconfig to support this?
Mar 27 2024
Mar 22 2024
Mar 18 2024
Mar 16 2024
Mar 13 2024
(The problem this fixes was introduced by me adding profiling to the linker in link_elf_ireloc.)
Mar 12 2024
By ABI break you mean for riscv64sf getting the old symbol versions? That architecture is dead, we should just delete the dead code in the header.
Oh I had it as an in-progress patch to make these *not* inline-only. I don't think it's a bug that they're only inline, but every other architecture exposes them as actual symbols too and GCC at least relies on that. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272759 (comment 5 in particular) and https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a.
Mar 7 2024
I considered extending the existing riscv_syscon for this purpose, but
it seems better to keep the StarFive/JH7110-specific drivers properly
separated.
Mar 6 2024
Mar 5 2024
s/POSIX files/POSIX text files/
What about all the other PCI controller drivers though? Various use ofw_pcib, for example.
Feb 27 2024
Feb 24 2024
Feb 23 2024
Feb 22 2024
To confirm I understand this:
Initial review comments. Not exhaustive, hard to be for large diffs like this where there are quite a few comments to make, but hopefully I didn't miss anything too fundamental.
Feb 16 2024
Ok, I went and found a copy of the PCI-PCI bridge spec (v1.1), which has this to say:
Feb 15 2024
diff --git a/sys/riscv/sifive/fu740_pci_dw.c b/sys/riscv/sifive/fu740_pci_dw.c index 13937e283042..d0490d6548f2 100644 --- a/sys/riscv/sifive/fu740_pci_dw.c +++ b/sys/riscv/sifive/fu740_pci_dw.c @@ -215,12 +215,6 @@ fupci_phy_init(struct fupci_softc *sc) return (error); }
Well, I isolated it down to a single bootverbose that makes it work, but this just tells me it's almost certainly just because of the delay:
Perhaps worth mentioning HiFive Unmatched somewhere in the description so there's a breadcrumb to follow for where this came from in the first place?
s/VAR/BAR/ in the message.
Feb 13 2024
Feb 12 2024
Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations. I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).