Partially revert the previous change; we need to keep this method as a
specific override for pci_driver subclasses which should not use
pci_rescan_method() -- cardbus and ofw_pcibus. However, change the return
value to ENODEV for the same reasoning given in the original commit, and
use this as the default rescan method in bus_if.m.
Reported by: jhb
Fixes: 36a8572ee8f5 ("bus_if: provide a default null rescan method")
MFC with: 36a8572ee8f5
The third argument to this function indicates whether the supplied
ticker is fixed or variable, i.e. requiring calibration. Give this
argument a type and name that better conveys this purpose.
Reviewed by: kib, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35459
There is an existing helper method in subr_bus.c, but almost no drivers
know to use it. It also returns the same error as an empty method,
making it not very useful. Move this to bus_if.m and return a more
sensible error code.
This gives a slightly more meaningful error message when attempting
'devctl rescan' on buses and devices alike:
"Device not configured" --> "Operation not supported by device"
Reviewed by: imp
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35501
It is unused, especially now that the underlying d_dumper methods do not
accept the argument.
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35174
Keep the global variable for its uses in ata-pci.c and
chipsets/ata-fsl.c but initialize it in the existing
ata_module_event_handler. Move the module event handler a bit earlier
to ensure the variable is set before any devices are attached.
Deduplicate code to iterate over the bpages list in a bus_dmamap_t
freeing bounce pages during bus_dmamap_unload.
Reviewed by: imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34967
All consumers already do it and it was required on amd64 and i386
until recently (1c1bf5bd7c1e479a7889839b941f53e689aa2569).
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34932
The probe routine was setting a value in the softc, but since the
probe routine was not returning zero, this value was lost since the
softc was reallocated (and re-zeroed) when the device was attached.
This is similar in nature to the fixes from
965205eb66cae3fd5de75a70a3aef2f014f98020.
To fix, move the code to set the 'shasta' flag to the start of attach
along with related code to set an IRQ resource on some non-shasta
devices. The IRQ resource still "worked" being in the probe routine
as the IRQ resource persisted after probe returned, but it is cleaner
to go ahead and move it to attach after setting the 'shasta' flag.
I have no way to test this, but noticed this while reading the code.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D34888
In theory the errors during llan_attach should be handled, but other
errors in llan_attach (e.g. bus_setup_intr) are already ignored, so
just remove the unused variable to preserve the status quo.
