ofw_pci_driver should be subclassed by other drivers instead of exporting its methods
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 29 2019
Changes after internal review:
- Remove structures for unsupported PAXB/PAXC V2 revisions - they won't be probed
- Derive from ofw_pci_driver instead of exporting its methods
- Make explicit apb_err_disable/enable functions
- Simplify some code
Aug 21 2019
Dec 3 2018
Nov 28 2018
May 18 2018
Clear the mapping in pmap_unmapbios as suggested.
Apr 27 2018
Add fix for race condition in pmap_unmapbios() which I forgot to add earlier.
I wrote an alternative, more complete implementation of mapbios/unmapbios functions without any of the previous caveats.
Of course the code got a little more complicated but I think it's still comprehensible.
@andrew let me know what you think.
Apr 14 2018
More context.
In D15059#317300, @andrew wrote:Can you provide more context. If you are uploading a patch via the web interface there are instructions on the wiki to ensure this is the case at https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface
Apr 13 2018
Mar 20 2018
In D14437#309219, @nwhitehorn wrote:I think there is also a subtlety for uncaught signals if the previous trap was a kernel fault, since you then end up in the wrong branch of the kernel/user if in trap() and probably crash.
In any case, I think the simplest solution is to have a replacement for trapcode that does the same things as trapcode, but additionally moves hsrr0/hsrr1 into srr0/srr1. Until we try to support bhyve, which is a larger project, they are safe to clobber in this context. trapcode is currently using 7 of a possible 32 instructions, so adding a variant with four more (mfhsrr0 %r1; mtsrr0 %r1; mfhsrr1 %r1; mtsrr1 %r1) in the middle should be fine. That also avoids the need for hrfid and related things when returning. We would then just install the variant for traps like HEA that are known to set HSRR* instead of SRR* and keep the rest of the trap-handling code as-is.
Mar 16 2018
I have no access to HW currently so cannot check this, but it seems you're right. I did not think of the case where userspace catches the signal.
In D14703#309190, @imp wrote:Having looked closely, though, it appears that it relies on it only for single byte quantities
In D14437#309033, @nwhitehorn wrote:I'm looking at this again. Does this actually work? HEA interrupts set HSRR0/HSSR1, which we don't save, so I think this will jump back to some random other memory location (whatever happened to be in SRR0).
Feb 28 2018
Feb 26 2018
As wma said, we'll make a follow-up commit fixing BE.
Feb 23 2018
Unfortunately I'm not able to test this today and provide a patch but I think what needs to be done is:
- include <sys/endian.h>
- add htole32() for in.nsid and also for every cdwXX field
- call nvme_completion_swapbytes() before reading cdw0
Doesn't work on big-endian, I'll work on a fix.
Feb 20 2018
Feb 19 2018
Feb 16 2018
As suggested, I have reworked the patch to perform endianess conversions all at once and as early as possible. The changes concern data which is read from device. I've also implemented other suggestions from the review.
Jan 16 2018
It's done that way because I needed to maintain a strict convention of where byte-swapping was performed to minimize the chance of mistakes (such as forgetting to swap or double-swapping a field by mistake as it's passed through various callbacks). Otherwise it was hard to make sense of the code, as there are a lot of fields which need swapping and they are often transferred throughout components.
Jan 15 2018
Oct 20 2016
Rebase to latest HEAD
Rebase to latest HEAD
Oct 19 2016
Change MSI-X number allocation scheme to make use of vmem_alloc() instead of local bitmap.
Sep 8 2016
Move the code to a separate function gic_map_msi() similarly to D7698.
In D7568#162015, @wma wrote:My only concern is if we can move this part of code to another file, like gicv3_fdt, where we have xref stuff already. In the present shape it fails to compile when FDT support is disabled.
Move xref registration to gic_v3_fdt.c
Sep 7 2016
Add missing Serdes DTS node and include the driver in files.arm and files.arm64.
Sep 5 2016
Return error when MSI could not be registered.
Add $FreeBSD$, cleanup mutex locks in detach(), check if mtx is initialized before calling lock/unlock.
Sep 2 2016
Sep 1 2016
Move MSIX file entry from sys/conf/files to files.arm and files.arm64. Add fdt dependency.
Move al_pci device entry from sys/conf/files to files.arm and files.arm64. Add fdt dependency.
Aug 31 2016
Move the code to a new function gic_map_msi() and call it in gic_map_intr() switch case for MSI. No functional changes.
obsolete.
obsolete.
obsolete.
obsolete.
obsolete.
obsolete.
obsolete.
Add comments describing added devices in kernel conf.
Fix style issues raised in review.
Aug 29 2016
Aug 26 2016
Rework MSI-X allocation to suit post-D7493 INTRNG.
I also removed some oddities leftover from old versions of the driver and simplified the code.
Remove implementation of bus_extend_resource() which is no longer in tree. Alpine MSI-X interrupts work fine without it after D7493 and a small change in GICv3.
In D7568#157092, @andrew wrote:Why do you need to retrieve this? It's normally done through INTRNG.
Updated base file version - no change in added code.
Aug 22 2016
Use device entry instead of SOC option.
Use device entries instead of SOC option.
Use device entries instead of SOC option.
Use device entries al_ccu and al_nb_service instead of SOC option.
In D7562#157063, @emaste wrote:I'm curious why these are options, and not just device entries?
Aug 19 2016
In D7567#157144, @nwhitehorn wrote:How does this interact with D7493? That change removes this method entirely.
I'm also dubious about using this kind of method with MSI for the reasons mentioned earlier: the bus API deal with IRQ numbers, rather than struct resource *, and so bus_extend_resource() has some nasty corner cases. I have some comments on this in the driver revision (D7571).
Remove all no-INTRNG parts of PCI driver.
Remove non-INTRNG parts of the driver as they are no longer necessary.
In D7579#157268, @andrew wrote:However, I can remove it if INTRNG is to stay.
There is no way to disable INTRNG and get a working arm64 kernel.