Replace calls to bus_generic_attach with bus_attach_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47675

Replace calls to bus_generic_probe with bus_identify_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47674

new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE

The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.

new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE

The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44131

show more ...

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

ofw: remove redundant calls in ofwbus_attach()

Since commit ecaecbc7d8bc212d8e854088106b3b21e631bb52, calling
ofw_bus_gen_setup_devinfo() is redundant, as the call to
device_set_ivars() now happens

ofw: remove redundant calls in ofwbus_attach()

Since commit ecaecbc7d8bc212d8e854088106b3b21e631bb52, calling
ofw_bus_gen_setup_devinfo() is redundant, as the call to
device_set_ivars() now happens inside simplebus_add_device().

Reviewed by: markj
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D40271

show more ...

ofw: fix memory leak in ofwbus_attach()

PR: 269509
Reported by: Jaroslaw Pelczar <jarek@jpelczar.com>
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38903

ofwbus: only allow unit number zero

ofwbus has always been the root of attachment for OFW/FDT platforms. It
may have simplebus children, but we expect only one instance of the
ofwbus driver, added d

ofwbus: only allow unit number zero

ofwbus has always been the root of attachment for OFW/FDT platforms. It
may have simplebus children, but we expect only one instance of the
ofwbus driver, added directly by nexus. We may as well ensure this
remains the case.

Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38493

show more ...

ofwbus: remove arm64 ifdefs

Rather than using the DEVICE_IDENTIFY method, let's have other
ofwbus-using platforms add ofwbus0 explicitly in nexus, like arm64. This
gives them the same flexibility, e

ofwbus: remove arm64 ifdefs

Rather than using the DEVICE_IDENTIFY method, let's have other
ofwbus-using platforms add ofwbus0 explicitly in nexus, like arm64. This
gives them the same flexibility, e.g. if riscv starts supporting ACPI,
and cleans up the #ifdefs.

We were doing this already on riscv, but adjust the 'order' parameters.

Reviewed by: andrew, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38492

show more ...

ofwbus: trim includes

Nothing in the file today relies on these.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D38491

ofwbus: remove handling of resources from ofwbus

The architecture nexus should handle allocation and release of memory and
interrupts. This is to ensure that system-wide resources such as these
are

ofwbus: remove handling of resources from ofwbus

The architecture nexus should handle allocation and release of memory and
interrupts. This is to ensure that system-wide resources such as these
are available to all devices, not just children of ofwbus0.

On powerpc this moves the ownership of these resources up one level,
from ofwbus0 to nexus0. Other architectures already have the required
logic in their nexus implementation, so this eliminates the duplication
of resources. An implementation of nexus_adjust_resource() is added for
arm, arm64, and riscv.

As noted by ian@ in the review, resource handling was the main bit of
logic distinguishing ofwbus from simplebus. With some attention to
detail, it should be possible to merge the two in the future.

Co-authored by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D30554

show more ...

ofw drivers: Remove unused devclass arguments to DRIVER_MODULE.

MFhead @ r304815

Merge ^/head r304236 through r304536.

INTRNG: Rework handling with resources. Partially revert r301453.
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, g

INTRNG: Rework handling with resources. Partially revert r301453.
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.

Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493

show more ...

INTRNG - change the way how an interrupt mapping data are provided
to the framework in OFW (FDT) case.

This is a follow-up to r301451.

Differential Revision: https://reviews.freebsd.org/D6634

MFH

Sponsored by: The FreeBSD Foundation

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physic

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544

show more ...

MFH

Sponsored by: The FreeBSD Foundation

Merge ^/head r295601 through r295844.

Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.

This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.

This is part of, and related to, the m

Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.

This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.

This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.

Discussed with: jhb
Suggested by: marcel

show more ...

Fix bug in ofwbus_release_resource() for non-ofwbus descendants

Resource list for devices that are not ofwbus descendants, but
got to ofwbus method via bus_generic_release_resource() call chain,
can

Fix bug in ofwbus_release_resource() for non-ofwbus descendants

Resource list for devices that are not ofwbus descendants, but
got to ofwbus method via bus_generic_release_resource() call chain,
cannot be found using BUS_GET_RESOURCE_LIST() used by ofwbus.
In that case, changing device's resource list should be avoided
(will not contain resource list prepared by ofw or simplebus).

Pointy-hat to: zbb
Reviewed by: wma
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D5304

show more ...

MfH @r295202

Expect to see panics in routing code at least now.

Merge ^/head r294777 through r294960.

MFH

Sponsored by: The FreeBSD Foundation