By using DWC TRM terminology, normal descriptor format should be named
extended and alternate descriptor format should be named normal.
Should not been functional change.
MFC after: 4 weeks
All MMCBR bridges have to implement all the MMCBR variables. This
implements them for everybody that currently doesn't.
A common routine for this should be written.
This was enumerated with exhaustive search for sys/eventhandler.h includes,
cross-referenced against EVENTHANDLER_* usage with the comm(1) utility. Manual
checking was performed to avoid redundant includes in some drivers where a
common os_bsd.h (for example) included sys/eventhandler.h indirectly, but it is
possible some of these are redundant with driver-specific headers in ways I
didn't notice.
(These CUs did not show up as missing eventhandler.h in tinderbox.)
X-MFC-With: r347984
given in random(4).
This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.
Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.
PR: 230870
Reviewed by: cem
Approved by: so(delphij,gtetlow)
Approved by: re(marius)
Differential Revision: https://reviews.freebsd.org/D16898
Change OF_getencprop_alloc semantics to be combination of malloc and
OF_getencprop and return size of the property, not number of elements
allocated.
For the use cases where number of elements is preferred introduce
OF_getencprop_alloc_multi helper function that copies semantics
of OF_getencprop_alloc prior to this change.
This is to make OF_getencprop_alloc and OF_getencprop_alloc_multi
function signatures consistent with OF_getencprop_alloc and
OF_getencprop_alloc_multi.
Functionality-wise this patch is mostly rename of OF_getencprop_alloc
to OF_getencprop_alloc_multi except two calls in ofw_bus_setup_iinfo
where 1 was used as a block size.
OF_getprop_alloc takes element size argument and returns number of
elements in the property. There are valid use cases for such behavior
but mostly API consumers pass 1 as element size to get string
properties. What API users would expect from OF_getprop_alloc is to be
a combination of malloc + OF_getprop with the same semantic of return
value. This patch modifies API signature to match these expectations.
For the valid use cases with element size != 1 and to reduce
modification scope new OF_getprop_alloc_multi function has been
introduced that behaves the same way OF_getprop_alloc behaved prior to
this patch.
Reviewed by: ian, manu
Differential Revision: https://reviews.freebsd.org/D14850
OF_finddevices returns ((phandle_t)-1) in case of failure. Some code
in existing drivers checked return value to be equal to 0 or
less/equal to 0 which is also wrong because phandle_t is unsigned
type. Most of these checks were for negative cases that were never
triggered so trhere was no impact on functionality.
Reviewed by: nwhitehorn
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14645
Transition all boards that support arm cortex CPUs to armv7. This
leaves two armv6 kernels in the tree. RPI-B, which uses the BCM2835
which has a ARM1176 core, and VERSATILEPB, which is a qemu board setup
around the time RPI-B went in. Copy std.armv6 to std.armv7, even
though that duplicates a lot of stuff. More work needs to be done to
sort out the duplication.
Differential Revision: https://reviews.freebsd.org/D12027
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omission
of these bridge declarations for mmccam(4) in a single place, i. e.
in dev/mmc/bridge.h.
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method (I've whipped these out of the tree as part of r227843
once, but they keep coming back ...),
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.
o Trim/adjust includes.
- Use new option SMP_ON_UP instead of (mis)using specific CPU type.
By this, any SMP kernel can be compiled with SMP_ON_UP support.
- Enable runtime detection of CPU multiprocessor extensions only
if SMP_ON_UP option is used. In other cases (pure SMP or UP),
statically compile only required variant.
- Don't leak multiprocessor instructions to UP kernel.
- Correctly handle data cache write back to point of unification.
DCCMVAU is supported on all armv7 cpus.
- For SMP_ON_UP kernels, detect proper TTB flags on runtime.
Differential Revision: https://reviews.freebsd.org/D9133
for later Cortex-A CPUs that support the Multiprocessor Extensions. This
will be needed to support both in a single GENERIC kernel while still
being able to only build for a single SoC.
Reviewed by: mmel
Relnotes: yes
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8138
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).
(Thanks to jilles@ for providing the vital clue about the kernel linker.)
intr_pic_init_secondary. Replace them with a direct call. On BCM2836
and ARMADA XP we need to add this function, but it can be empty.
Reviewed by: ian, imp
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5460
slightly wrong on the others. We should just check if mp_ncpus is set to
more than one CPU as we may wish to run on a single core even when SMP is
available.
Reviewed by: ian
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5458
Only L2 PIPT cache is supported for __ARM_ARCH >= 6.
In fact, this is just a pure proclamation as this option is used
only in armv4 specific files now.
The ci20 port (by kan@) is going to reuse almost all of the intrng code
since the SoC in question looks suspiciously like someone took an ARM
SoC design and replaced the ARM core with a MIPS core.
* migrate out the code;
* rename ARM_ -> INTR_;
* rename arm_ -> intr_;
* move the interrupt flush routine from intr.c / intrng.c into
arm/machdep_intr.c - removing the code duplication and removing
the ARM specific bits from here.
Thanks to the Star Wars: The Force Awakens premiere line for allowing
me a couple hours of quiet time to finish the universe builds.
Tested:
* make universe
TODO:
* The structure definitions in subr_intr.c still includes machine/intr.h
which requires one duplicates all of the intrng definitions in
the platform code (which kan has done, and I think we don't have to.)
Instead I should break out the generic things (function declarations,
common intr structures, etc) into a separate header.
* Kan has requested I make the PIC based IPI stuff optional.
the name the function will have when the new ARM_INTRNG code is integrated,
and doing this rename first will make it easier to toggle the new interrupt
handling code on/off with a config option for debugging.
This also adds a newbus interface that allows a SoC to override the
following settings:
- if_dwc specific SoC initialization;
- if_dwc descriptor type;
- if_dwc MII clock.
This seems to be an old version of the hardware descriptors but it is
still in use in a few SoCs (namely Allwinner A20 and Amlogic at least).
Tested on Cubieboard2 and Banana pi.
Tested for regressions on Altera Cyclone by br@ (old version).
Obtained from: NetBSD
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks
determined at runtime so there's no need to set the values in
each DTS.
Tested on YYHD18 (aml8726-m3), VSATV102 (aml8726-m6), and
ODROIDC1 (aml8726-m8b).
Differential Revision: https://reviews.freebsd.org/D2588
Submitted by: John Wehle
