Some casts from pointers to uint64_t and back in lio_main.c cause base
gcc on i386 to warn "cast from pointer to integer of different size",
and vice versa. Add additional casts to uintptr_t to suppress these.
Reviewed by: sbruno
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15754
Generating the pnp info have the side effect to include all nodes even
if the status isn't "okay".
That means that loading the module will load but not attach as it checks
the status in the probe function.
On pine64 before :
root@pine64-lts:~ # devmatch -u
unattached on ofwbus pnpinfo name=memory
unattached on ofwbus pnpinfo name=chosen
unattached on ofwbus pnpinfo name=sound_spdif compat=simple-audio-card
unattached on ofwbus pnpinfo name=spdif-out compat=linux,spdif-dit
unattached on simplebus pnpinfo name=dma-controller@1c02000 compat=allwinner,sun50i-a64-dma
unattached on simplebus pnpinfo name=mmc@1c10000 compat=allwinner,sun50i-a64-mmc
unattached on simplebus pnpinfo name=usb@1c19000 compat=allwinner,sun8i-a33-musb
unattached on simplebus pnpinfo name=spdif@1c21000 compat=allwinner,sun50i-a64-spdif
unattached on simplebus pnpinfo name=i2s@1c22000 compat=allwinner,sun50i-a64-i2s
unattached on simplebus pnpinfo name=i2s@1c22400 compat=allwinner,sun50i-a64-i2s
unattached on simplebus pnpinfo name=serial@1c28400 compat=snps,dw-apb-uart
unattached on simplebus pnpinfo name=serial@1c28800 compat=snps,dw-apb-uart
unattached on simplebus pnpinfo name=serial@1c28c00 compat=snps,dw-apb-uart
unattached on simplebus pnpinfo name=serial@1c29000 compat=snps,dw-apb-uart
unattached on simplebus pnpinfo name=i2c@1c2ac00 compat=allwinner,sun6i-a31-i2c
unattached on simplebus pnpinfo name=i2c@1c2b000 compat=allwinner,sun6i-a31-i2c
unattached on simplebus pnpinfo name=i2c@1c2b400 compat=allwinner,sun6i-a31-i2c
unattached on ofwbus pnpinfo name=aliases
unattached on ofwbus pnpinfo name=symbols
All simplebus node are disabled
After :
root@pine64-lts:~ # devmatch -u
unattached on ofwbus pnpinfo name=memory
unattached on ofwbus pnpinfo name=chosen
unattached on ofwbus pnpinfo name=sound_spdif compat=simple-audio-card
unattached on ofwbus pnpinfo name=spdif-out compat=linux,spdif-dit
unattached on simplebus pnpinfo name=dma-controller@1c02000 compat=allwinner,sun50i-a64-dma
unattached on simplebus pnpinfo name=usb@1c19000 compat=allwinner,sun8i-a33-musb
unattached on ofwbus pnpinfo name=aliases
unattached on ofwbus pnpinfo name=symbols
Reviewed by: imp (with some objection)
Differential Revision: https://reviews.freebsd.org/D15770
This is in preperation for supporting newer smccc functions that also use
the same call method.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D15745
It was needed only for ia64 where it was implemented as a call to
bswapXX, which was always a real function. htobeXX with a constant
argument is calculated at compile-time everywhere else.
MFC after: 1 week
Sponsored by: Chelsio Communications
lan78xx_eeprom_read just checked for EEPROM presence then called
lan78xx_eeprom_read_raw if present, and had only one caller. Introduce
lan78xx_eeprom_present to check for EEPROM presence, and use it in the
one place it is needed.
This is used by r334964, which was accidentally committed out-of-order
from my work tree.
Reported by: markj
Sponsored by: The FreeBSD Foundation
Differences between LAN7800 and LAN7850 from the driver's perspective:
* The LAN7800 muxes EEPROM signals with LEDs, so LED mode needs to be
disabled when reading/writing EEPROM. The EEPROM is not muxed on the
LAN7850.
* The Linux driver enables automatic duplex and speed detection when
there is no EEPROM, for the LAN7800 only. With this FreeBSD driver
LAN7850-based adapters without a configuration EEPROM fail to link
(with or without the automatic duplex and speed detection code), so
I have just followed the example of the Linux driver for now.
Sponsored by: The FreeBSD Foundation
Sponsored by: Microchip (hardware)
Casting from rman_res_t to a pointer results in "cast to pointer from
integer of different size" warnings with base gcc on i386, so print
these without casting. The kva field of struct bxe_bar is of type
vm_offset_t, which can be 32 or 64 bit, so cast it to uintmax_t before
printing.
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15733
Base gcc fails to compile sys/dev/drm2/i915/intel_display.c for i386,
with the following -Werror warnings:
cc1: warnings being treated as errors
/usr/src/sys/dev/drm2/i915/intel_display.c:8884: warning:
initialization from incompatible pointer type
This is due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432, which
incorrectly interprets the [] as a flexible array member.
Because base gcc does not have a -W flag to suppress this particular
warning, it requires a rather ugly cast. To not influence any other
compiler, put it in a #if/#endif block.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15744
Add a few intermediate casts to uintptr_t to suppress "cast to pointer
from integer of different size" warnings from gcc. Also remove a few
incorrect casts.
Reviewed by: ram
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15747
These ioctls are not documented and only stubbed in a few drivers: mse(4),
psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS
implemented in psm(4)
Given the fact that they were introduced 20 years ago and implementation
has never been completed, remove any related code.
PR: 228718 (exp-run)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D15726
when parsing the phy type, however this is included in the length returned
by OF_getprop. To fix this stop ignoring the terminator.
PR: 228828
Reported by: sbruno
Sponsored by: DARPA, AFRL
If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.
Earlier chips seem to get less stuck in this condition versus AR9280/later
and AR9300/later, but whilst here just fix up the AR5212 era chips to also
return NF calibration failures.
This HAL routine would only return failure if the channel was not configured.
This is a no-op until the driver side code for doing resets and the HAL
code for being told about the reset type (and then handling it!) is
implemented.
Tested:
* AR9280, STA mode
* AR2425, STA mode
* AR9380, STA mode
pmc_process_interrupt takes 5 arguments when only 3 are needed.
cpu is always available in curcpu and inuserspace can always be
derived from the passed trapframe.
While facially a reasonable cleanup this change was motivated
by the need to workaround a compiler bug.
core2_intr(cpu, tf) ->
pmc_process_interrupt(cpu, ring, pmc, tf, inuserspace) ->
pmc_add_sample(cpu, ring, pm, tf, inuserspace)
In the process of optimizing the tail call the tf pointer was getting
clobbered:
(kgdb) up
at /storage/mmacy/devel/freebsd/sys/dev/hwpmc/hwpmc_mod.c:4709
4709 pmc_save_kernel_callchain(ps->ps_pc,
(kgdb) up
1205 error = pmc_process_interrupt(cpu, PMC_HR, pm, tf,
resulting in a crash in pmc_save_kernel_callchain.
Fix the behavior of ofw_fdt_getprop() and ofw_fdt_getprop() functions to match
the documentation as the non-fdt code.
Submitted by: Luis Pires <lffpires@ruabrasil.org>
Reviewed by: manu, jhibbits
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D15680
On PowerNV systems, the rootfs is passed through kexec, which loads the rootfs
into memory and set two fdt entries to describe where the file is located in
the memory;
I need to pass this memory region to the md device as a mfs_root, but, current
md driver does not support two things:
* Just getting a pointer from an external (bootloader) memory. If I need to
workaround it, I would need to declare a static array and memcopy from this
external memory to this static variable.
* The size of the image. The usage of mfs_root_end, which is not a pointer,
seems to be not possible for this prestaged scenario.
This patch simply adds a new way to load mfs_root from memory.
Differential Revision: https://reviews.freebsd.org/D15625
Approved by: kib, jhibbits (mentor)
- add '-j' options to filter to enable converting native pmc
log format to json lines format to enable the use of scripts
and external tooling
% pmc filter -j pmc.log pmc.jsonl
- Record the tsc value in sampling interrupts as opposed to
recording nanotime when the sample is copied to a global log
in hardclock - potentially many milliseconds later.
- At initialize record the tsc_freq and the time of day to give
us an offset for translating the tsc values in callchain records
Utility hangs when OCS_IOCTL_CMD_MGMT_GET_ALL called in parallel on port 0 and port 1.
Fix: Using static structure for results is corrupting the second ioctl request. Removed static for results structure.
Approved by: ken
MFC after: 3 days
This adds several vendors from NetBSD's copy of the same file (r1.749).
Prefer longer more "canonical" names where the names differed.
Sort while here.
By logging all threads and processes 'pmc filter'
can now filter on process or thread name, relieving
the user of the burden of determining which tid or
pid was which when the sample was taken.
% pmc filter -T if_io_tqg -P nginx pmc.log pmc-iflib.log
% pmc filter -x -T idle pmc.log pmc-noidle.log
- increase pmc cpuid field from 8 to 12 bits
- add cpuid version string to initialize entry in the log
so that filter can identify which counter index an
event name maps to
- GC unused config flags
- make fixed counter assignment more robust as well as the
changes needed to be properly identified for filter
This adds the -U options to pmcstat which will attribute in-kernel samples
back to the user stack that invoked the system call. It is not the default,
because when looking at kernel profiles it is generally more desirable to
merge all instances of a given system call together.
Although heavily revised, this change is directly derived from D7350 by
Jonathan T. Looney.
Obtained from: jtl
Sponsored by: Juniper Networks, Limelight Networks
Some of the routines were using artificially limited builtin already,
drop the explicit limit.
The use of builtins allows quite often allows the compiler to elide the call
or most zeroing to begin with. For instance, if the target object is 32 bytes
in size and gets zeroed + has 16 bytes initialized, the compiler can just
add code to zero out the rest.
Note not all the primites have asm variants and some of the existing ones
are not optimized. Maintaines are strongly encourage to take a look
(regardless of this change).
or 4 CPUs. Add a compile-time option SC_KERNEL_CONS_ATTRS to control the
defaults.
Default to color numbers in reverse order to CPU numbers (instead of
in the same order with white first and wrapping to dark grey), so that
the brightest bright colors are used first. Don't use dark grey at all;
replace it by dark green.
Syscons has too many compile-time options, but this one is needed in
in case the defaults give something like white on white, or the user
really hates this feature and can't wait to turn it off in rc.
MFC after: next release?
The per-CPU ts is not initialized early, so the global kernel ts is used
early, but it ony has 1 (normal) attribute. Switch this to the per-CPU
attribute.
The difference is most visible with EARLY_AP_STARTUP.
Change to using the curcpu macro instead of PCPU_GET(cpuid) in 2 places for
the above and in 1 other place in my old code in syscons. The function-like
spelling is perhaps better for indicating that curcpu is volatile (unlike
curthread), but for CPU attributes volatility is a feature.
The SCHEDULER_STOPPED() hack breaks locking generally, and
mtx_trylock_*() especially. When mtx_trylock_*() returns nonzero,
naive code version here trusts it to have worked. But when
SCHEDULER_STOPPED() is true, mtx_trylock_*() returns 1 without doing
anything. Then mtx_unlock_*() crashes especially badly attempting to
unlock iff the error is detected, since mutex unlocking functions don't
check SCHEDULER_STOPPED().
syscons already didn't trust mtx_trylock_spin(), but it was missing the
logic to turn on sp->kdb_locked when turning off sp->mtx_locked during
panics. It also used panicstr instead of SCHEDULER_LOCKED because I
thought that panicstr was more fragile. They only differ for a window
of lines in panic(), and in broken cases where stop_cpus_hard() in panic()
didn't work.
